[Tinyos-2-commits] CVS: tinyos-2.x/doc/html tep120.html,1.7,1.8
Phil Levis
scipio at users.sourceforge.net
Tue May 15 16:31:24 PDT 2007
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv2538/html
Modified Files:
tep120.html
Log Message:
Incorporate Jack's comments.
Index: tep120.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep120.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** tep120.html 21 Apr 2007 07:04:39 -0000 1.7
--- tep120.html 15 May 2007 23:31:21 -0000 1.8
***************
*** 4,21 ****
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>TinyOS Alliance Structure</title>
! <meta name="author" content="Philippe Bonnet" />
! <meta name="author" content="David Culler" />
! <meta name="author" content="Deborah Estrin" />
! <meta name="author" content="Ramesh Govindan" />
! <meta name="author" content="Mike Horton" />
! <meta name="author" content="Jeonghoon Kang" />
! <meta name="author" content="Philip Levis" />
! <meta name="author" content="Lama Nachman" />
! <meta name="author" content="Jack Stankovic" />
! <meta name="author" content="Rob Szewczyk" />
! <meta name="author" content="Matt Welsh" />
! <meta name="author" content="Adam Wolisz" />
<style type="text/css">
--- 4,10 ----
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
! <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>TinyOS Alliance Structure</title>
! <meta name="authors" content="Philippe Bonnet David Culler Deborah Estrin Ramesh Govindan Mike Horton Jeonghoon Kang Philip Levis Lama Nachman Jack Stankovic Rob Szewczyk Matt Welsh Adam Wolisz" />
<style type="text/css">
***************
*** 295,298 ****
--- 284,288 ----
</head>
<body>
+ <div class="document" id="tinyos-alliance-structure">
<h1 class="title">TinyOS Alliance Structure</h1>
<table class="docinfo" frame="void" rules="none">
***************
*** 310,342 ****
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">All</td>
</tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Philippe Bonnet</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>David Culler</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Deborah Estrin</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Ramesh Govindan</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Mike Horton</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Jeonghoon Kang</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Philip Levis</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Lama Nachman</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Jack Stankovic</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Rob Szewczyk</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Matt Welsh</td></tr>
! <tr><th class="docinfo-name">Author:</th>
! <td>Adam Wolisz</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">17-April-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.5</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-12-12</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Alliance <tinyos-alliance at mail.millennium.berkeley.edu></td>
--- 300,321 ----
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">All</td>
</tr>
! <tr><th class="docinfo-name">Authors:</th>
! <td>Philippe Bonnet
! <br />David Culler
! <br />Deborah Estrin
! <br />Ramesh Govindan
! <br />Mike Horton
! <br />Jeonghoon Kang
! <br />Philip Levis
! <br />Lama Nachman
! <br />Jack Stankovic
! <br />Rob Szewczyk
! <br />Matt Welsh
! <br />Adam Wolisz</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">17-April-2006</td>
</tr>
! <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">2007-05-15</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Alliance <tinyos-alliance at mail.millennium.berkeley.edu></td>
***************
*** 344,348 ****
</tbody>
</table>
- <div class="document" id="tinyos-alliance-structure">
<div class="note">
<p class="first admonition-title">Note</p>
--- 323,326 ----
***************
*** 353,364 ****
TEP 1.</p>
</div>
! <div class="section" id="abstract">
! <h1><a name="abstract">Abstract</a></h1>
<p>This memo describes the goals and organization structure of the TinyOS Alliance.
It covers membership, the working group forums for contribution, intellectual
property, source licensing, and the TinyOS Steering Committee (TSC).</p>
</div>
! <div class="section" id="charter">
! <h1><a name="charter">1. Charter</a></h1>
<!-- TinyOS Alliance Charter:: -->
<p>Formulate a legal and organizational framework for an alliance that
--- 331,342 ----
TEP 1.</p>
</div>
! <div class="section">
! <h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This memo describes the goals and organization structure of the TinyOS Alliance.
It covers membership, the working group forums for contribution, intellectual
property, source licensing, and the TinyOS Steering Committee (TSC).</p>
</div>
! <div class="section">
! <h1><a id="charter" name="charter">1. Charter</a></h1>
<!-- TinyOS Alliance Charter:: -->
<p>Formulate a legal and organizational framework for an alliance that
***************
*** 367,375 ****
development of the worldwide academic and industrial TinyOS community.</p>
</div>
! <div class="section" id="overview">
! <h1><a name="overview">2. Overview</a></h1>
! <p>This memo defines a blueprint and conceptual foundation for an open
! alliance that fulfills the above charter.
! It defines the following ten aspects of the alliance:</p>
<blockquote>
<ul class="simple">
--- 345,353 ----
development of the worldwide academic and industrial TinyOS community.</p>
</div>
! <div class="section">
! <h1><a id="overview" name="overview">2. Overview</a></h1>
! <p>This memo defines a blueprint and conceptual foundation for an open
! alliance that fulfills the above charter. It defines the following ten
! aspects of the alliance:</p>
<blockquote>
<ul class="simple">
***************
*** 386,392 ****
</ul>
</blockquote>
! <p>We (the Alliance) recognize that each of these aspects contributes to the
! whole, is inter-related and needs to be consistent overall. This document
! attempts to address them sequentially, recognizing that each depends on the
others. It draws on lessons from several related
organizations, although each of these also has significantly
--- 364,370 ----
</ul>
</blockquote>
! <p>We (the Alliance) recognize that each of these aspects contributes to the
! whole, is inter-related and needs to be consistent overall. This document
! attempts to address them sequentially, recognizing that each depends on the
others. It draws on lessons from several related
organizations, although each of these also has significantly
***************
*** 400,404 ****
<li>FSF - Foundational software</li>
</ol>
! <p>We (the Alliance) draw most strongly upon the IETF, even though that
organization was
focused around creating and standardizing protocols, rather than
--- 378,382 ----
<li>FSF - Foundational software</li>
</ol>
! <p>We (the Alliance) draw most strongly upon the IETF, even though that
organization was
focused around creating and standardizing protocols, rather than
***************
*** 412,435 ****
centered on the contributions of individual members.</p>
<p>We encourage industrial involvement, industrial development, and
! industrial support. The organization is welcoming to
! companies, but it keeps financial support and marketing
! activities (while both 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 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 implemented without need
! particular proprietary IP. In the IETF, this is addressed by the
! requirement of multiple interoperable implementations before
! standardization. If such implementations can be developed without
! legal issues, it is likely that other non-infringing implementations
! are possible. Like IETF, we seek a lean bureacracy adn mostly
! volunteer organization.</p>
<p>From OSDL, we share the goal of developing a stable, high quality
version of an open source system. This suggests that the alliance
! have strong role in developing test suites and broadly accessible
testbeds, as well as structures for sharing development resources.
However, we avoid the OSDL structure of the scale of monetary
--- 390,412 ----
centered on the contributions of individual members.</p>
<p>We encourage industrial involvement, industrial development, and
! industrial support. The organization is welcoming to companies, but
! it keeps financial support and marketing activities (while both
! 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
! 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
! proprietary IP. In the IETF, this is addressed by the requirement of
! multiple interoperable implementations before standardization. If
! such implementations can be developed without legal issues, it is
! likely that other non-infringing implementations are possible. Like
! IETF, we seek a lean bureacracy and mostly volunteer organization.</p>
<p>From OSDL, we share the goal of developing a stable, high quality
version of an open source system. This suggests that the alliance
! have a strong role in developing test suites and broadly accessible
testbeds, as well as structures for sharing development resources.
However, we avoid the OSDL structure of the scale of monetary
***************
*** 441,456 ****
especially in areas of tools, devices, and new platforms. We also
seek to retain the notion that credit should be given to authors. In
! Apache the technical merit associated with the brand is exchanged to
! giving the copyright to the Apache organization. For a broad alliance
representing many universities and large companies, such a copyright
! scheme is likely to be an untennable barrier. Instead, we seek to
provide a simple source license regime with technical tools for giving
credit and strong social pressure to comply.</p>
<p>From Zigbee, we share the goal of providing marketing support for the
! accomplishments of the alliance and that we should see to define
standardized services, not just protocols. We recognize that the
! alliance and serve a useful function in being a point of allocation
! for various namespaces, but that this important function should not be
! a tool for extracting financial contributions. We see the value of an
IP pool to give confidence that the standard can be adopted without
becoming entrapped later by IP terms, however, we also see that such a
--- 418,433 ----
especially in areas of tools, devices, and new platforms. We also
seek to retain the notion that credit should be given to authors. In
! Apache, giving the copyright to the Apache organization exchanges the
! value of the brand for technical contributions. For a broad alliance
representing many universities and large companies, such a copyright
! scheme is likely to be an untenable barrier. Instead, we seek to
provide a simple source license regime with technical tools for giving
credit and strong social pressure to comply.</p>
<p>From Zigbee, we share the goal of providing marketing support for the
! accomplishments of the alliance and that we should seek to define
standardized services, not just protocols. We recognize that the
! alliance serves a useful function in being a point of allocation for
! various namespaces, but that this important function should not be a
! tool for extracting financial contributions. We see the value of an
IP pool to give confidence that the standard can be adopted without
becoming entrapped later by IP terms, however, we also see that such a
***************
*** 462,467 ****
multiple implementation.</p>
</div>
! <div class="section" id="mission">
! <h1><a name="mission">3. Mission</a></h1>
<p>The mission of the TinyOS Alliance is to provide a forum to facilitate:</p>
<blockquote>
--- 439,444 ----
multiple implementation.</p>
</div>
! <div class="section">
! <h1><a id="mission" name="mission">3. Mission</a></h1>
<p>The mission of the TinyOS Alliance is to provide a forum to facilitate:</p>
<blockquote>
***************
*** 474,494 ****
implementations, technical documents, testing and verification suites,
and educational materials,</li>
! <li>the contribution of innovative technology from a world-wide research
community and the maturation and dissemination of these
contributions, and</li>
! <li>the promotion of the technology, the community, and the impact of networked
embedded systems.</li>
</ul>
</blockquote>
</div>
! <div class="section" id="organizational-structure">
! <h1><a name="organizational-structure">4. Organizational Structure</a></h1>
<p>The Alliance has a technical advisory function: guide the evolution of
the TinyOS architecture, formulate and track progress of working
groups, and provide an open and impartial process for technical
! documentation. It also has an organizational advisory function: manage
! industry
! interaction, legal and IP issues, evolution of the organization
! itself, membership issues and so on.</p>
<p>We follow an approach that starts small and grows the structure as
needed. The focus should be on the working groups. Working groups are
--- 451,470 ----
implementations, technical documents, testing and verification suites,
and educational materials,</li>
! <li>the contribution of innovative technology from a world-wide research
community and the maturation and dissemination of these
contributions, and</li>
! <li>the promotion of the technology, the community, and the impact of networked
embedded systems.</li>
</ul>
</blockquote>
</div>
! <div class="section">
! <h1><a id="organizational-structure" name="organizational-structure">4. Organizational Structure</a></h1>
<p>The Alliance has a technical advisory function: guide the evolution of
the TinyOS architecture, formulate and track progress of working
groups, and provide an open and impartial process for technical
! documentation. It also has an organizational advisory function:
! manage industry interaction, legal and IP issues, evolution of the
! organization itself, membership issues and so on.</p>
<p>We follow an approach that starts small and grows the structure as
needed. The focus should be on the working groups. Working groups are
***************
*** 505,510 ****
and a Steering Committee. The Steering Committee oversees a collection
of Working Groups, each with a Chair and Members.</p>
! <div class="section" id="steering-committee">
! <h2><a name="steering-committee">4.1 Steering Committee</a></h2>
<p>In the steady state the Steering Committee will consist of the chairs
of working groups plus a handful of elected members at large. Tenure
--- 481,486 ----
and a Steering Committee. The Steering Committee oversees a collection
of Working Groups, each with a Chair and Members.</p>
! <div class="section">
! <h2><a id="steering-committee" name="steering-committee">4.1 Steering Committee</a></h2>
<p>In the steady state the Steering Committee will consist of the chairs
of working groups plus a handful of elected members at large. Tenure
***************
*** 538,545 ****
procedures, membership criteria, selection of venues, oversight of
access to code repositories and Alliance web sites, and regular
! Alliance meetings.</p>
</div>
! <div class="section" id="working-groups">
! <h2><a name="working-groups">4.2 Working Groups</a></h2>
<p>The working groups form the core of the alliance. Each working
group will have a chair who will be responsible for WG processes,
--- 514,521 ----
procedures, membership criteria, selection of venues, oversight of
access to code repositories and Alliance web sites, and regular
! Alliance meetings that occur at least once a year.</p>
</div>
! <div class="section">
! <h2><a id="working-groups" name="working-groups">4.2 Working Groups</a></h2>
<p>The working groups form the core of the alliance. Each working
group will have a chair who will be responsible for WG processes,
***************
*** 547,564 ****
functions are discussed in more detail in a later section.</p>
</div>
! <div class="section" id="board-of-directors">
! <h2><a name="board-of-directors">4.3 Board of Directors</a></h2>
<p>The non-profit will require a Board of Directors responsible for
corporate matters.</p>
</div>
</div>
! <div class="section" id="membership-and-participation">
! <h1><a name="membership-and-participation">5. Membership and Participation</a></h1>
<p>We desire to continue the TinyOS tradition of promoting broad
membership. This means that we want to keep barriers to entry low in
all respects: legal, financial, and organizational. As with IETF and
Apache, we want to shape the organization as a meritocracy that
! encourages, promotes, and credits the contributions of its members.
! Companies have essential role, but merit, not finances should
dictate direction. Membership and influence should recognize the
importance of adopters, not just developers.</p>
--- 523,540 ----
functions are discussed in more detail in a later section.</p>
</div>
! <div class="section">
! <h2><a id="board-of-directors" name="board-of-directors">4.3 Board of Directors</a></h2>
<p>The non-profit will require a Board of Directors responsible for
corporate matters.</p>
</div>
</div>
! <div class="section">
! <h1><a id="membership-and-participation" name="membership-and-participation">5. Membership and Participation</a></h1>
<p>We desire to continue the TinyOS tradition of promoting broad
membership. This means that we want to keep barriers to entry low in
all respects: legal, financial, and organizational. As with IETF and
Apache, we want to shape the organization as a meritocracy that
! encourages, promotes, and credits the contributions of its members.
! Companies have an essential role, but merit, not finances should
dictate direction. Membership and influence should recognize the
importance of adopters, not just developers.</p>
***************
*** 573,577 ****
</dl>
</li>
! <li><p class="first">Contributing Member: Individual who aditionally joins working groups,
attends meetings, or contributes code or other assets to the
Alliance. Contributing members are elected to various posts and
--- 549,553 ----
</dl>
</li>
! <li><p class="first">Contributing Member: Individual who additionally joins working groups,
attends meetings, or contributes code or other assets to the
Alliance. Contributing members are elected to various posts and
***************
*** 582,590 ****
<p>There is no individual membership fee, but members will be responsible for
nominal registration fees at Alliance meetings.</p>
! <p>Corporations and organizational have institutional membership, which reflects
! their degree of effort.</p>
<blockquote>
<ul class="simple">
! <li>Institutional Member: Corporation or institutional organization
that joins the Alliance, agrees to appear on the Alliance
web site and documents, and pays a nominal administrative fee.
--- 558,566 ----
<p>There is no individual membership fee, but members will be responsible for
nominal registration fees at Alliance meetings.</p>
! <p>Corporations and organizations have institutional membership, which
! reflects their degree of effort.</p>
<blockquote>
<ul class="simple">
! <li>Institutional Member: A corporation or organization
that joins the Alliance, agrees to appear on the Alliance
web site and documents, and pays a nominal administrative fee.
***************
*** 609,625 ****
that recognizess the contributions of the individuals, whether they
be members of corporations, academic institutions, govermental
! institutions, or unaffiliated. We will provide a fee structure that encourages
! the participation of small companies and start-ups.</p>
</div>
! <div class="section" id="id1">
! <h1><a name="id1">6. Working Groups</a></h1>
! <p>There will be two forms of working groups. LONG-STANDING
! groups are chartered to develop important areas or subsystems. For
! example, we expect longstanding groups on
! routing, management, platforms, testing, programming tools, and
! education. SHORT-TERM groups have a fixed mandate to tackle a
! particular topic. For example, there may be groups to develop a
! particular protocol, establish a policy or licensing format, or
! address a particular application capability.</p>
<p>There will be two means of Working Group formation: grass roots and
charter. Grass roots groups are formed by individuals or groups
--- 585,599 ----
that recognizess the contributions of the individuals, whether they
be members of corporations, academic institutions, govermental
! institutions, or unaffiliated.</p>
</div>
! <div class="section">
! <h1><a id="id1" name="id1">6. Working Groups</a></h1>
! <p>There will be two forms of working groups. LONG-STANDING groups are
! chartered to develop important areas or subsystems. For example, we
! expect longstanding groups on routing, management, platforms, testing,
! programming tools, and education. SHORT-TERM groups have a fixed
! mandate to tackle a particular topic. For example, there may be
! groups to develop a particular protocol, establish a policy or
! licensing format, or address a particular application capability.</p>
<p>There will be two means of Working Group formation: grass roots and
charter. Grass roots groups are formed by individuals or groups
***************
*** 638,648 ****
implementable without relying on particular proprietary intellectual
property. We are not interested in discouraging development of
! implementations that have excel in various ways through proprietary
IP, but standards should not require the use of such IP and should
! allow for multiple, interoperable implementations.
! The Steering committee will be engaged in ratification of standards.</p>
</div>
! <div class="section" id="intellectual-property">
! <h1><a name="intellectual-property">7. Intellectual Property</a></h1>
<p>In general we want to promote the development, adoption and use of
open technology. We want to avoid having the advancement of embedded
--- 612,623 ----
implementable without relying on particular proprietary intellectual
property. We are not interested in discouraging development of
! implementations that have excelled in various ways through proprietary
IP, but standards should not require the use of such IP and should
! allow for multiple, interoperable implementations. The Steering
! committee will be engaged in ratification of standards by actively
! participating in the community review process and document evolution.</p>
</div>
! <div class="section">
! <h1><a id="intellectual-property" name="intellectual-property">7. Intellectual Property</a></h1>
<p>In general we want to promote the development, adoption and use of
open technology. We want to avoid having the advancement of embedded
***************
*** 683,689 ****
Members recognize that in making proposals, they are required by
Alliance rules to disclose what IP they know to be relevant. In the
! rare cases where working group determine that IP dependent proposals
! are sufficiently critical that they be pursued, such IP must 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
--- 658,664 ----
Members recognize that in making proposals, they are required by
Alliance rules to disclose what IP they know to be relevant. In the
! rare cases where a working group determines that IP dependent
! proposals are sufficiently critical that they be pursued, such IP must
! 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
***************
*** 697,702 ****
devices.</p>
</div>
! <div class="section" id="source-licensing">
! <h1><a name="source-licensing">8. Source Licensing</a></h1>
<p>In general, we want to provide a mechanism where individuals and
companies can easily contribute source, can utilize what is available,
--- 672,677 ----
devices.</p>
</div>
! <div class="section">
! <h1><a id="source-licensing" name="source-licensing">8. Source Licensing</a></h1>
<p>In general, we want to provide a mechanism where individuals and
companies can easily contribute source, can utilize what is available,
***************
*** 707,723 ****
<p>We want to give credit where credit is due. Fundamentally, the
community moves forward by contributing valuable technology and
! standing open each other's shoulders, not on their feet. Credit and
respect drive a virtuous cycle of technical advance. We do have
several examples where companies, or even resarch institutions, have
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 oblicated 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 sacrafice 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 realtively 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
--- 682,698 ----
<p>We want to give credit where credit is due. Fundamentally, the
community moves forward by contributing valuable technology and
! standing upon each other's shoulders, not on their feet. Credit and
respect drive a virtuous cycle of technical advance. We do have
several examples where companies, or even resarch institutions, have
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 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
have many contributors to a cohesive whole and many of these
***************
*** 728,732 ****
increasingly so as the Alliance becomes more formal. We do not want
it tainted with its use as a marketing tool on inferior technology.
! Thus, we want to connect the use of the term with membership,
contribution, and conformance to Alliance rules and guidelines.</p>
<p>We have the additional wrinkle that we are dealing primarily with
--- 703,707 ----
increasingly so as the Alliance becomes more formal. We do not want
it tainted with its use as a marketing tool on inferior technology.
! Thus, we want to connect the use of the TinyOS term with membership,
contribution, and conformance to Alliance rules and guidelines.</p>
<p>We have the additional wrinkle that we are dealing primarily with
***************
*** 742,757 ****
as possible. Fortunately, we are seeing convergence in licenses,
after several years of proliferation.</p>
! <p>To address these matters, the Alliance will have 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, with
! the member organization name changed appropriately. Organizations can
! submit additional proposed licenses to the Steering Committee.</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>
<p>We will utilize the available development tools to facilitate the
! generation of list of contributors associated with any particular
instantiation of TinyOS components into an overall system,
application, or distribution. We will provide tools for registering
--- 717,736 ----
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
! 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
! wishes to use a completely new license, it can submit the license to
! the OSL 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>
<p>We will utilize the available development tools to facilitate the
! generation of a list of contributors associated with any particular
instantiation of TinyOS components into an overall system,
application, or distribution. We will provide tools for registering
***************
*** 768,784 ****
norms and reputation as mechanisms for enforcing proper creditation.
We will develop tools that make compliance relatively easy, reward
! those that do so, and provide a complaint mechanism to identify misuse.</p>
! <p>In taking this approach, we focus on needs of reference implementation
! of standardized interfaces and protocols. Alliance is not the only
! vehicle for producing a hardened, tested, certified code base.
To do so would require the Alliance host a large technical staff, as
! OSDL does.
! Comapanies may do so, or produce implementations with enhanced
! performance, reliability, or efficiency using their own proprietary
! technology. The Alliance encourages such innovation while promoting
! standardized interfaces that allows such technology to interoperate.</p>
</div>
! <div class="section" id="funding">
! <h1><a name="funding">9. Funding</a></h1>
<p>Initially, we expect that there are no full time employees in the
Alliance and that funding needs are limited to such items as lawyer's
--- 747,764 ----
norms and reputation as mechanisms for enforcing proper creditation.
We will develop tools that make compliance relatively easy, reward
! those that do so, and provide a complaint mechanism to identify
! misuse.</p>
! <p>In taking this approach, we focus on needs of reference mplementations
! of standardized interfaces and protocols. The Alliance is not the
! only vehicle for producing a hardened, tested, certified code base.
To do so would require the Alliance host a large technical staff, as
! OSDL does. Comapanies may do so, or produce implementations with
! enhanced performance, reliability, or efficiency using their own
! proprietary technology. The Alliance encourages such innovation while
! promoting standardized interfaces that allow such technology to
! interoperate.</p>
</div>
! <div class="section">
! <h1><a id="funding" name="funding">9. Funding</a></h1>
<p>Initially, we expect that there are no full time employees in the
Alliance and that funding needs are limited to such items as lawyer's
***************
*** 789,843 ****
which primarily involve meetings, travel, and generation of work
products. The Alliance is predominantly a volunteer organization.
! Membership participation will involve attendance at
! Alliance meetings. Registration fees will be charged to cover costs
! associated with adminstration of the meetings.</p>
<p>To maintain the focus on technical excellence and meritocracy, we want
to avoid the heavy-handed quid-pro-quo seen in many industrial
consortiums where funding determines influence. The best use of funds
and the best form of influence is direct contribution to the work
! products of the Alliance.
! To keep the structure of the Alliance and its operations minimalist
! and lean, membership focuses on desired impact and recognition, rather
! than control. We want the best way to influence the direction of the Alliance
! to be to contribute technical work and demonstrate leadership, rather than
! try to control what individuals can or cannot contribute.</p>
<p>Companies and institutions are encouraged to contribute financial and
in-kind support. It will be essential that companies provide initial
funding to create the legal structure and to establish basic IT
! capabilities to host the web site and working groups.
! Institutional members
! will pay an annual membership fee. In some cases, a
! contributing corporate member may provide in-kind services
! such as lawyers' time used to
! draw up or comment on by-laws.
! Targeted contributions will be
! solicited and encouraged. In this case the donator need not
! become a contributing corporate member, e.g., in those cases
! where such a membership may be prohibited or unwanted.
! The costs of meetings, such as the TinyOS
! technology exchange, will be covered through registration fees and
! not by institutional membership fees.</p>
</div>
! <div class="section" id="work-products">
! <h1><a name="work-products">10. Work Products</a></h1>
! <p>The broad mission of the Alliance calls for a broad range of
work products.</p>
! <p>Foremost among these are a set of TEPs documenting
! systems and protocols as well as TEPs that provide guidance
! and knowledge to the community. Technical documentation will have
! robust and open reference implementations for the community to
! use, refine, improve, and discuss. These reference implementations
! will not preclude alternative, compatibile implementations which may
! have additional features or optimizations. The Alliance Working Groups
! will periodically produce periodic releases of these reference
implementations for the community to use and improve.</p>
! <p>The Alliance will support community contributions
! of innovative extensions and systems by providing a CVS repository
! to store them.
! In order to keep these contributions organized for users, the
! Steering Committee may nominate one or more people to caretake
! the repository by setting minimal guidelines for the use of
! the directory structure and migrating code as it joins the core
! or falls into disuse.</p>
<p>To make these technological resources more accessible and useful
to a broad embedded networks community, the Alliance will be
--- 769,818 ----
which primarily involve meetings, travel, and generation of work
products. The Alliance is predominantly a volunteer organization.
! Membership participation will involve attendance at Alliance meetings.
! Registration fees will be charged to cover costs associated with
! adminstration of the meetings.</p>
<p>To maintain the focus on technical excellence and meritocracy, we want
to avoid the heavy-handed quid-pro-quo seen in many industrial
consortiums where funding determines influence. The best use of funds
and the best form of influence is direct contribution to the work
! products of the Alliance. To keep the structure of the Alliance and
! its operations minimalist and lean, membership focuses on desired
! impact and recognition, rather than control. We want the best way to
! influence the direction of the Alliance to be to contribute technical
! work and demonstrate leadership, rather than try to control what
! individuals can or cannot contribute.</p>
<p>Companies and institutions are encouraged to contribute financial and
in-kind support. It will be essential that companies provide initial
funding to create the legal structure and to establish basic IT
! capabilities to host the web site and working groups. Institutional
! members will pay an annual membership fee. In some cases, a
! contributing corporate member may provide in-kind services such as
! lawyers' time used to draw up or comment on by-laws. Targeted
! contributions will be solicited and encouraged. In this case the
! donator need not become a contributing corporate member, e.g., in
! those cases where such a membership may be prohibited or unwanted.
! The costs of meetings, such as the TinyOS technology exchange, will be
! covered through registration fees and not by institutional membership
! fees.</p>
</div>
! <div class="section">
! <h1><a id="work-products" name="work-products">10. Work Products</a></h1>
! <p>The broad mission of the Alliance calls for a broad range of
work products.</p>
! <p>Foremost among these are a set of TEPs documenting systems and
! protocols as well as TEPs that provide guidance and knowledge to the
! community. Technical documentation will have robust and open reference
! implementations for the community to use, refine, improve, and
! discuss. These reference implementations will not preclude
! alternative, compatibile implementations which may have additional
! features or optimizations. The Alliance Working Groups will
! periodically produce periodic releases of these reference
implementations for the community to use and improve.</p>
! <p>The Alliance will support community contributions of innovative
! extensions and systems by providing a CVS repository to store them.
! In order to keep these contributions organized for users, the Steering
! Committee may nominate one or more people to caretake the repository
! by setting minimal guidelines for the use of the directory structure
! and migrating code as it joins the core or falls into disuse.</p>
<p>To make these technological resources more accessible and useful
to a broad embedded networks community, the Alliance will be
***************
*** 849,853 ****
the technology, the Alliance will develop and make available
several end-user applications and tools. The goal is to improve
! the accessibility of the technology to end-users while
demonstrating its effectiveness. Historical examples of such applications
include Surge and TinyDB. An important part of this effort is
--- 824,828 ----
the technology, the Alliance will develop and make available
several end-user applications and tools. The goal is to improve
! the accessibility of the technology to end-users while
demonstrating its effectiveness. Historical examples of such applications
include Surge and TinyDB. An important part of this effort is
***************
*** 855,869 ****
as tools and graphical environments.</p>
</div>
! <div class="section" id="conclusions">
! <h1><a name="conclusions">11. Conclusions</a></h1>
! <p>By focusing on consensus building and technical excellence, the
Alliance seeks to avoid being a forum for political and economic
! positioning. It will achieve this by focusing on working groups
! and the contributions of individuals, while not taking strong
! positions on the benefits or drawbacks of different approaches.
! The variety of application domains sensornets are used in and
! the huge differences in requirements mean that having a suite
! of solutions, rather than a single one, is often not only
! desirable but essential.</p>
<p>Over the past five years, low-power embedded sensor networks have
grown from research prototypes to working systems that are being
--- 830,843 ----
as tools and graphical environments.</p>
</div>
! <div class="section">
! <h1><a id="conclusions" name="conclusions">11. Conclusions</a></h1>
! <p>By focusing on consensus building and technical excellence, the
Alliance seeks to avoid being a forum for political and economic
! positioning. It will achieve this by focusing on working groups and
! the contributions of individuals, while not taking strong positions on
! the benefits or drawbacks of different approaches. The diverse
! requiremements of sensornet applications mean that having a suite of
! solutions, rather than a single one, is often not only desirable but
! essential.</p>
<p>Over the past five years, low-power embedded sensor networks have
grown from research prototypes to working systems that are being
***************
*** 873,877 ****
catalyst to this growth has been the presence of a large community
around a shared, free code base.</p>
! <p>The time has come to create an organizational structure to
allow the effort to grow further. As sensornets become more widespread,
contributions and advancements will be from an increasingly broad
--- 847,851 ----
catalyst to this growth has been the presence of a large community
around a shared, free code base.</p>
! <p>The time has come to create an organizational structure to
allow the effort to grow further. As sensornets become more widespread,
contributions and advancements will be from an increasingly broad
***************
*** 884,903 ****
technology.</p>
</div>
! <div class="section" id="author-s-address">
! <h1><a name="author-s-address">12. Author's 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">David Culler <<a class="reference" href="mailto:culler@cs.berkeley.edu">culler@cs.berkeley.edu</a>> </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>
</div>
--- 858,876 ----
technology.</p>
</div>
! <div class="section">
! <h1><a id="author-s-address" name="author-s-address">12. Author's 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">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>
</div>
More information about the Tinyos-2-commits
mailing list