[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep1.txt, 1.6, 1.7 tep120.txt, 1.6, 1.7

Thu Jun 21 12:38:44 PDT 2007

Update of /cvsroot/tinyos/tinyos-2.x/doc/txt
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv28880/txt

Modified Files:
	tep1.txt tep120.txt 
Log Message:
Nits on TEP 1.
Incorporated alliance commments on TEP 120.

Index: tep1.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep1.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep1.txt	29 May 2007 22:23:55 -0000	1.6
--- tep1.txt	21 Jun 2007 19:38:42 -0000	1.7
***************
*** 234,239 ****
  detailed author contact information.

! A TEP MAY have appendices after its Author section. Unlike regular sections,
! appendices are lettered. Please refer to Appendix A for details.

  4. Reference
--- 234,240 ----
  detailed author contact information.

! A TEP MAY have appendices after its numbered sections. Unlike 
! numbered sections, appendices are lettered. Please refer to Appendix 
! A for details.

  4. Reference

Index: tep120.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep120.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep120.txt	15 May 2007 23:29:48 -0000	1.6
--- tep120.txt	21 Jun 2007 19:38:42 -0000	1.7
***************
*** 72,77 ****
  6) FSF - Foundational software

! We (the Alliance) draw most strongly upon the IETF, even though that 
! organization was
  focused around creating and standardizing protocols, rather than
  developing a code base.  Its emphasis on rough consensus AND
--- 72,79 ----
  6) FSF - Foundational software

! Examining the structure and policies of these organizations helps
! determine what the Alliance can borrow from them, what it must
! do differently, and why.  We (the Alliance) draw most strongly upon the 
! IETF, even though that organization was
  focused around creating and standardizing protocols, rather than
  developing a code base.  Its emphasis on rough consensus AND
***************
*** 90,97 ****
  concept that proper behavior of participants and member companies is
  most strongly shaped by code of ethics, captured in organization rules
! and social norms, rather than threats of legal reprocusions.  The
  broader marketplace is a more effective enforcement body than any
  technical organization.  Thus, we ask that participants declare
! relevant IP that they are aware of, rather than force a strict
  accounting of potentially relevant IP.  We encourage the development
  of open solutions that are implemented without the need for particular
--- 92,100 ----
  concept that proper behavior of participants and member companies is
  most strongly shaped by code of ethics, captured in organization rules
! and social norms, rather than threats of legal repercussions.  The
  broader marketplace is a more effective enforcement body than any
  technical organization.  Thus, we ask that participants declare
! relevant intellectual proprt (IP) that they are aware of, rather than 
! force a strict
  accounting of potentially relevant IP.  We encourage the development
  of open solutions that are implemented without the need for particular
***************
*** 135,139 ****
  from obtaining blocking IP.  It does discourage contributions that
  might pull IP into the pool.  We prefer a process of declaration and
! multiple implementation.

  3. Mission
--- 138,143 ----
  from obtaining blocking IP.  It does discourage contributions that
  might pull IP into the pool.  We prefer a process of declaration and
! multiple implementation. Section 7 goes deeper into how the Alliance
! manages the issues and complexities of IP in an open organization.

  3. Mission
***************
*** 205,209 ****
  the process towards overall architectural coherence.

! The SC is also responsible for reviewing and approving all TEPs. WGs
  submit TEPs to the SC for review. The SC should appoint one
  contributing Alliance member not affiliated with the corresponding WG
--- 209,214 ----
  the process towards overall architectural coherence.

! The SC is also responsible for reviewing and approving all TinyOS 
! Enhancement Proposals (TEPs) that working groups generate. WGs
  submit TEPs to the SC for review. The SC should appoint one
  contributing Alliance member not affiliated with the corresponding WG
***************
*** 285,289 ****

  The organization will be able to accept direct financial and
! intellectual property contributions.  The IP policy should encourage
  corporate participation while preserving focus on soundness, merit,
  and consensus building.  Ultimately, we seek to promote a meritocracy
--- 290,295 ----

  The organization will be able to accept direct financial and
! intellectual property contributions.  The IP policy, described 
! in Section 7, should encourage
  corporate participation while preserving focus on soundness, merit,
  and consensus building.  Ultimately, we seek to promote a meritocracy
***************
*** 315,318 ****
--- 321,326 ----
  The typical output of a working group is technical documentation AND
  working code, including interface definitions and standard proposals.
+ While this is the typical output, working groups are not constrained
+ to this model, and can have a variety of purposes and work products.
  We seek to promote the development of standardized interfaces,
  protocols, services, and tools with high quality, open reference
***************
*** 332,336 ****
  open technology.  We want to avoid having the advancement of embedded
  networks getting trapped into proprietary IP.  Accordingly, our IP
! policy builds heavily on the IETF mode.  We also want to avoid a high
  barrier to participation.  Thus, we want to avoid demanding membership
  requirements that require extensive legal analysis and assessing deep
--- 340,344 ----
  open technology.  We want to avoid having the advancement of embedded
  networks getting trapped into proprietary IP.  Accordingly, our IP
! policy builds heavily on the IETF model.  We also want to avoid a high
  barrier to participation.  Thus, we want to avoid demanding membership
  requirements that require extensive legal analysis and assessing deep
***************
*** 377,382 ****

  Of course, Intellectual Property in the TinyOS alliance is closely
! tied to source licensing terms, as dicussed in greater detail in that
! section. As part of Alliance rules, members agree to only check in
  code that conforms to Alliance source license policy.  As part of
  keeping barriers to participation low, GPL and code based on
--- 385,390 ----

  Of course, Intellectual Property in the TinyOS alliance is closely
! tied to source licensing terms, as dicussed in greater detail in Section 8.
! As part of Alliance rules, members agree to only contribute 
  code that conforms to Alliance source license policy.  As part of
  keeping barriers to participation low, GPL and code based on
***************
*** 404,413 ****
  as their own.  This concern is partially addressed by GPL, where if
  you build upon the work of others you are obliged to put it back in
! the open.  Apache addresses this issue by requiring acreditation of
  the Apache foundation.  However, this is connected with a stiff
  membership requirement of signing the copyright to Apache.
  Participants make that sacrifice when they view the brand appeal
  associated with the Apache meritocracy as of sufficient value to
! warrant the arrangement.  Apache is also a losely affiliated
  consortium of relatively localized projects, typically in very well
  established technical areas.  Our situation is different because we
--- 412,421 ----
  as their own.  This concern is partially addressed by GPL, where if
  you build upon the work of others you are obliged to put it back in
! the open.  Apache addresses this issue by requiring accreditation of
  the Apache foundation.  However, this is connected with a stiff
  membership requirement of signing the copyright to Apache.
  Participants make that sacrifice when they view the brand appeal
  associated with the Apache meritocracy as of sufficient value to
! warrant the arrangement.  Apache is also a loosely affiliated
  consortium of relatively localized projects, typically in very well
  established technical areas.  Our situation is different because we
***************
*** 438,442 ****

  To address these matters, the Alliance has a preferred source license
! based on the BSD framework and a small set of accepted licenses, some
  of which have been gradfathered in with the existing code
  base. Contributions can be made using one of those accepted licenses,
--- 446,451 ----

  To address these matters, the Alliance has a preferred source license
! based on the BSD framework, (the "new" BSD license approved by the
! Open Source Initiative [BSD]_ ) and a small set of accepted licenses, some
  of which have been gradfathered in with the existing code
  base. Contributions can be made using one of those accepted licenses,
***************
*** 445,451 ****
  Committee.  In order to avoid the debate of what constitutes "open
  source," the Steering Committee will generally only consider
! OSL-approved licenses for inclusion in the core. If a contributor
  wishes to use a completely new license, it can submit the license to
! the OSL first.

  We will not require that the Alliance hold copyright of submitted
--- 454,463 ----
  Committee.  In order to avoid the debate of what constitutes "open
  source," the Steering Committee will generally only consider
! licenses approved by the Open Source Initiative (OSI) for inclusion in 
! the core.  However, being an 
! OSI-approved license is not a sufficient condition for approval
! within the Alliance. If a contributor
  wishes to use a completely new license, it can submit the license to
! the OSI first.

  We will not require that the Alliance hold copyright of submitted
***************
*** 596,613 ****

! 12. Author's Address
  ====================================================================

--- 608,631 ----

! 12. Authors' Address
  ====================================================================

! | Philippe Bonnet <bonnet.p at gmail.com> 
  | David Culler <dculler at archrock.com>
! | Deborah Estrin 	<destrin at cs.ucla.edu> 
! | Ramesh Govindan <ramesh at usc.edu> 
! | Mike Horton 	<mhorton at xbow.com> 
! | Jeonghoon Kang 	<budge at keti.re.kr> 
! | Philip Levis    <pal at cs.stanford.edu>
! | Lama Nachman 	<lama.nachman at intel.com>
! | Jack Stankovic 	<stankovic at cs.virginia.edu>
! | Rob Szewczyk 	<rob at moteiv.com> 
! | Matt Welsh 	<mdw at cs.harvard.edu> 
! | Adam Wolisz 	<awo at ieee.org> 
! 
! 13. Citations
! ====================================================================
! 
! .. [BSD] http://www.opensource.org/licenses/bsd-license.php
! 