tep120.txt

tinyos-2.x.rar

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
the SC, may solicit comments from the community at large, but must
also thoroughly review the submitted TEP. WGs must address any
issues/questions brought up either by the reviewer or by other
community members. Once the reviewer approves the revisions, he/she
presents the TEP to the SC for approval by rough consensus. Finally,
TEPs that affect the organizational structure of the Alliance must
also be approved by the Board.

Finally, the Steering Commitee will be responsible for determining the
procedural elements of the Alliance. This includes election
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.

4.2 Working Groups
-------------------------------------------------------

The working groups form the core of the alliance. Each working
group will have a chair who will be responsible for WG processes,
reporting, meetings, and membership. Working groups and their
functions are discussed in more detail in a later section.

4.3 Board of Directors
------------------------------------------------------- 

The non-profit will require a Board of Directors responsible for
corporate matters. 

5. Membership and Participation
====================================================================

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.

The fundamental membership is individual, as individuals create work products,
serve on working groups and committees, and vote.  We have two forms:

  * Member: Individual who joins the Alliance and participates at a
     basic level, typically as consumer of technology.

  * 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
    have voting rights.

There is no individual membership fee, but members will be responsible for
nominal registration fees at Alliance meetings.

Corporations and organizations have institutional membership, which
reflects their degree of effort.

  * 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.
    (Min. Annual $500 for small companies and non-profits, $1000 for larger)

  * Contributing Institutional Member: Corporation or institutional
    organization that additionally provides financial support, resources,
    facilities, technical contributions, intellectual property,
    marketing support, or other meaningful contributions to the
    Alliance. Such institutions are featured prominently in the Alliance and
    have the opportunity to appoint individuals as contributing members.
    (Min. Annual $2000 for small companies and non-profits, $5000 for larger)

Rather than focusing on maximizing the financial contributions into
the alliance, we are interested in maximizing the impact of the
alliance in facilitating a healthy academic and industrial, research
and production ecosystem around embedded network technology.

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
that recognizess the contributions of the individuals, whether they
be members of corporations, academic institutions, govermental
institutions, or unaffiliated.

6. Working Groups
====================================================================

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.

There will be two means of Working Group formation: grass roots and
charter. Grass roots groups are formed by individuals or groups
who have a preliminary version of something important and want to make
it part of TinyOS.  They assemble and make a request to the SC with a
proposed charter statement and chair.  Chartered groups are
formed by SC or Board of Directors to address a recognized need for an
important area of development.  The SC solicits members and chair with
a particular charter in mind.  WGs may be formed for organizational or
marketing goals, as well as technical goals.

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
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.

7. Intellectual Property
====================================================================

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 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
IP assignment requirements are seen to too large a barrier and
discourage the active participation of members.  At the same time, we
recognize that without such measures only, members cannot expect
guarantees of IP rights.  We also want to avoid sponging IP from
others or worse, having members or non-members running ahead of the
Alliance and creating blocking IP.  In essence, all participants must
operate with eyes open.  The Alliance encourage an open process, open
standards, and open source with a clear code of ethics, but leaves
broader issues of enforcement to the outside market.  Like IETF, we
rely on disclosure of known IP of relevance, an open process, and a
code of conduct.  Working groups are encourage to create work products
that do not rely on proprietary IP for implementation.

We also want to avoid requiring a member institution from having to
conduct a complete inventory of IP holdings for potential relevance.
This is impractical for Universities and large corporations.  It is
the responsibility of the members to disclose IP or relvance, whether
it is their property or not, so that they Alliance members can make
informed decisions and trade-offs.

Following the IETF, to establish a culture of openness, meeting
discussions, presentations, and technical documents are
non-confidential.  This simple measure is a signficant step towards
establishing the culture of openness and it avoids large legal and
organizational hassles, as evident in OSDL.

As with the IETF, there will be a mechanism for contributing IP to the
Alliance.  This will be treated along with other forms of contribution
in establishing member status.

Working Groups will be tasked to avoid forming standards and creating
work products that fundamentally depend on proprietary IP, i.e., where
the proposal can only reasonably be implemented using such IP.
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.

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
potentially viral licensing terms must be carefully compartmentalized,
explicit, and not present in core software.  It will typically involve
development tools, such as the compilers and peripheral Linux-based
devices. 

8. Source Licensing
====================================================================

In general, we want to provide a mechanism where individuals and
companies can easily contribute source, can utilize what is available,
and can gain recognition for their efforts.  Following the TinyOS
tradition, our source licensing policy will be most strongly aligned
with BSD and its more modern variants.  We recognize several inherent
tensions and trade-offs in formulating the source license.

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 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
have many contributors to a cohesive whole and many of these