tep120.txt

tinyos-2.x.rar

contributors are at leading research institutions where copyright must
rest with the host institution.  Moreover, much of the work is at the
leading edge of technology.

We recognize that the TinyOS "brand" is of value and will be
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.

We have the additional wrinkle that we are dealing primarily with
embedded technology, which may have no visible user interface.  And,
we have limited resources so carrying additional footprint for legal
conformance is unattractive.

Furthermore, many of our contributors are from organizations that have
very precisely defined sets of acceptable source licensing terms.  As
much as having a common license throughout the Alliance would make it
easy for everyone to know the specific terms, getting diverse
institutions to agree to common language is impractical.  We do,
however, want to have as few distinct licenses with a little variation
as possible.  Fortunately, we are seeing convergence in licenses,
after several years of proliferation.

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,
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
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
source code, but that it conform to Alliance guidelines.  These
include guidelines for adding copyrights to existing sources.

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
contributors, copyrights, and applicable source licenses on line, for
ease of reference.

Alliance rules will set guidelines for giving credit to contributors
in documentation, source, tools, web sites and so on.  We want to
recognize the individuals and their host institutions, as well as the
Alliance.  But we do not want to create a bureacratic nightmare that
deters adoption, nor do we want to turn the Alliance into a policing
organization.  Harsh and threatening legal terms that have no credible
means of enforcement create a adversarial culture with little
practical advantage.  Instead, the Alliance will utilize cultural
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.

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.

9. Funding
====================================================================

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
fees, web site costs, and insurance. If the Alliance eventually
requires full time support personnel, the funding structure will have
to be re-visited.

As with the IETF, individuals are responsible for their own costs,
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.

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.

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.

10. Work Products
====================================================================

The broad mission of the Alliance calls for a broad range of 
work products. 

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.

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.

To make these technological resources more accessible and useful
to a broad embedded networks community, the Alliance will be
dedicated to providing a set of educational materials. This
includes introductory tutorials, documentation of core systems,
simple and complex example applications, and user guides.

In addition to educational sample applications, whose purpose
is to teach new developers about the internals and workings of
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
good documentation for users who are not expert programmers, as well
as tools and graphical environments. 


11. Conclusions
====================================================================

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.

Over the past five years, low-power embedded sensor networks have
grown from research prototypes to working systems that are being
actively deployed. Furthermore, there is a vibrant research community
that actively works to deploy these systems and collaborate with
industry, making advances quickly accessible and usable. A great
catalyst to this growth has been the presence of a large community
around a shared, free code base.

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
demographic of users, and bringing them all together will speed
progress and improve the potential benefit these systems can bring
to society. This focus on bringing disparate groups together lies
at the heart of the Alliance. Rather than depend on strong requirements,
it depends on broad collaboration and participation, placing a minimalist
set of expectations that will encourage the exchange of ideas and
technology.


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