Incorporated alliance commments on TEP 120.
<td>Philip Levis</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">18-Oct-2004</td>
</tr>
-<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.5</td>
+<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.6</td>
</tr>
-<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-12-12</td>
+<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-05-29</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
</tr>
<p>The last numbered section of a TEP (but before citations, if there are any),
entitled "Author's Address" or "Author's Addresses" MUST contain
detailed author contact information.</p>
-<p>A TEP MAY have appendices after its Author section. Unlike regular sections,
-appendices are lettered. Please refer to Appendix A for details.</p>
+<p>A TEP MAY have appendices after its numbered sections. Unlike
+numbered sections, appendices are lettered. Please refer to Appendix
+A for details.</p>
</div>
</div>
<div class="section">
<li>OSGI - Service layer</li>
<li>FSF - Foundational software</li>
</ol>
-<p>We (the Alliance) draw most strongly upon the IETF, even though that
-organization was
+<p>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
running code placed issues akin to those we face near the fore. We
important) at arms length from the technical process. We share the
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
+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 IP that they are aware of, rather than force a strict
+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
proprietary IP. In the IETF, this is addressed by the requirement of
other members of the alliance. It also does not constrain non-members
from obtaining blocking IP. It does discourage contributions that
might pull IP into the pool. We prefer a process of declaration and
-multiple implementation.</p>
+multiple implementation. Section 7 goes deeper into how the Alliance
+manages the issues and complexities of IP in an open organization.</p>
</div>
<div class="section">
<h1><a id="mission" name="mission">3. Mission</a></h1>
process, managing WG creation/extinction, arbitrating between WGs, and
supervising activities to resolve conflicting directions and moving
the process towards overall architectural coherence.</p>
-<p>The SC is also responsible for reviewing and approving all TEPs. WGs
+<p>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
to review the TEP. This reviewer, who may or may not be a member of
alliance in facilitating a healthy academic and industrial, research
and production ecosystem around embedded network technology.</p>
<p>The organization will be able to accept direct financial and
-intellectual property contributions. The IP policy should encourage
+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
that recognizess the contributions of the individuals, whether they
marketing goals, as well as technical goals.</p>
<p>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
implementations of each. We seek to have these standards be
<p>In general we want to promote the development, adoption and use of
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
+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
strategic analysis before joining. In particular, IP pooling or broad
be available on reasonable and non-discriminatory (RAND) terms for the
Steering Committee to be able to approve the action.</p>
<p>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
+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
potentially viral licensing terms must be carefully compartmentalized,
gained substantial benefit from the work of others while presenting it
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 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 losely affiliated
+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
have many contributors to a cohesive whole and many of these
as possible. Fortunately, we are seeing convergence in licenses,
after several years of proliferation.</p>
<p>To address these matters, the Alliance has a preferred source license
-based on the BSD framework and a small set of accepted licenses, some
+based on the BSD framework, (the "new" BSD license approved by the
+Open Source Initiative <a class="citation-reference" href="#bsd" id="id2" name="id2">[BSD]</a> ) 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,
with the member organization name changed appropriately.
Organizations can submit additional proposed licenses to the Steering
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
+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 OSL first.</p>
+the OSI first.</p>
<p>We will not require that the Alliance hold copyright of submitted
source code, but that it conform to Alliance guidelines. These
include guidelines for adding copyrights to existing sources.</p>
technology.</p>
</div>
<div class="section">
-<h1><a id="author-s-address" name="author-s-address">12. Author's Address</a></h1>
+<h1><a id="authors-address" name="authors-address">12. Authors' Address</a></h1>
<div class="line-block">
-<div class="line">Philippe Bonnet <<a class="reference" href="mailto:bonnet.p@gmail.com">bonnet.p@gmail.com</a>></div>
+<div class="line">Philippe Bonnet <bonnet.p at gmail.com></div>
<div class="line">David Culler <dculler at archrock.com></div>
-<div class="line">Deborah Estrin <<a class="reference" href="mailto:destrin@cs.ucla.edu">destrin@cs.ucla.edu</a>></div>
-<div class="line">Ramesh Govindan <<a class="reference" href="mailto:ramesh@usc.edu">ramesh@usc.edu</a>></div>
-<div class="line">Mike Horton <<a class="reference" href="mailto:mhorton@xbow.com">mhorton@xbow.com</a>></div>
-<div class="line">Jeonghoon Kang <<a class="reference" href="mailto:budge@keti.re.kr">budge@keti.re.kr</a>></div>
-<div class="line">Philip Levis <<a class="reference" href="mailto:pal@cs.stanford.edu">pal@cs.stanford.edu</a>></div>
-<div class="line">Lama Nachman <<a class="reference" href="mailto:lama.nachman@intel.com">lama.nachman@intel.com</a>></div>
-<div class="line">Jack Stankovic <<a class="reference" href="mailto:stankovic@cs.virginia.edu">stankovic@cs.virginia.edu</a>></div>
-<div class="line">Rob Szewczyk <<a class="reference" href="mailto:rob@moteiv.com">rob@moteiv.com</a>></div>
-<div class="line">Matt Welsh <<a class="reference" href="mailto:mdw@cs.harvard.edu">mdw@cs.harvard.edu</a>></div>
-<div class="line">Adam Wolisz <<a class="reference" href="mailto:awo@ieee.org">awo@ieee.org</a>></div>
+<div class="line">Deborah Estrin <destrin at cs.ucla.edu></div>
+<div class="line">Ramesh Govindan <ramesh at usc.edu></div>
+<div class="line">Mike Horton <mhorton at xbow.com></div>
+<div class="line">Jeonghoon Kang <budge at keti.re.kr></div>
+<div class="line">Philip Levis <pal at cs.stanford.edu></div>
+<div class="line">Lama Nachman <lama.nachman at intel.com></div>
+<div class="line">Jack Stankovic <stankovic at cs.virginia.edu></div>
+<div class="line">Rob Szewczyk <rob at moteiv.com></div>
+<div class="line">Matt Welsh <mdw at cs.harvard.edu></div>
+<div class="line">Adam Wolisz <awo at ieee.org></div>
</div>
</div>
+<div class="section">
+<h1><a id="citations" name="citations">13. Citations</a></h1>
+<table class="docutils citation" frame="void" id="bsd" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="bsd">[BSD]</a></td><td><a class="reference" href="http://www.opensource.org/licenses/bsd-license.php">http://www.opensource.org/licenses/bsd-license.php</a></td></tr>
+</tbody>
+</table>
+</div>
</div>
</body>
</html>
entitled "Author's Address" or "Author's Addresses" MUST contain
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.
+A TEP MAY have appendices after its numbered sections. Unlike
+numbered sections, appendices are lettered. Please refer to Appendix
+A for details.
4. Reference
====================================================================
5) OSGI - Service layer
6) FSF - Foundational software
-We (the Alliance) draw most strongly upon the IETF, even though that
-organization was
+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
running code placed issues akin to those we face near the fore. We
important) at arms length from the technical process. We share the
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
+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 IP that they are aware of, rather than force a strict
+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
proprietary IP. In the IETF, this is addressed by the requirement of
other members of the alliance. It also does not constrain non-members
from obtaining blocking IP. It does discourage contributions that
might pull IP into the pool. We prefer a process of declaration and
-multiple implementation.
+multiple implementation. Section 7 goes deeper into how the Alliance
+manages the issues and complexities of IP in an open organization.
3. Mission
====================================================================
supervising activities to resolve conflicting directions and moving
the process towards overall architectural coherence.
-The SC is also responsible for reviewing and approving all TEPs. WGs
+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
to review the TEP. This reviewer, who may or may not be a member of
and production ecosystem around embedded network technology.
The organization will be able to accept direct financial and
-intellectual property contributions. The IP policy should encourage
+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
that recognizess the contributions of the individuals, whether they
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
implementations of each. We seek to have these standards be
In general we want to promote the development, adoption and use of
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
+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
strategic analysis before joining. In particular, IP pooling or broad
Steering Committee to be able to approve the action.
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
+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
potentially viral licensing terms must be carefully compartmentalized,
gained substantial benefit from the work of others while presenting it
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 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 losely affiliated
+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
have many contributors to a cohesive whole and many of these
after several years of proliferation.
To address these matters, the Alliance has a preferred source license
-based on the BSD framework and a small set of accepted licenses, some
+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,
with the member organization name changed appropriately.
Organizations can submit additional proposed licenses to the Steering
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
+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 OSL first.
+the OSI first.
We will not require that the Alliance hold copyright of submitted
source code, but that it conform to Alliance guidelines. These
technology.
-12. Author's Address
+12. Authors' Address
====================================================================
-| Philippe Bonnet <bonnet.p@gmail.com>
+| Philippe Bonnet <bonnet.p at gmail.com>
| David Culler <dculler at archrock.com>
-| Deborah Estrin <destrin@cs.ucla.edu>
-| Ramesh Govindan <ramesh@usc.edu>
-| Mike Horton <mhorton@xbow.com>
-| Jeonghoon Kang <budge@keti.re.kr>
-| Philip Levis <pal@cs.stanford.edu>
-| Lama Nachman <lama.nachman@intel.com>
-| Jack Stankovic <stankovic@cs.virginia.edu>
-| Rob Szewczyk <rob@moteiv.com>
-| Matt Welsh <mdw@cs.harvard.edu>
-| Adam Wolisz <awo@ieee.org>
+| 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
+
projects / tinyos-2.x.git / commitdiff