[Tinyos-alliance] TO DO and meeting notes

[Matt Welsh]

Phil,

Here are my comments on TEP120.

Matt

------

The intro of the document does not make it immediately clear what
the *concrete* goals of the Alliance are - standardization? Code
development? Protocol specifications? It becomes clearer later in
the document but I think something concrete should be said up front.

Overall I find the document is a mixture of specific policy
statements intermingled with various explanatory notes. In other
documents of this type it is common to separate the two so the
specific policies can be read separately from the rationale and
background for those policies. For example, the lengthy discussion of
issues with various source licensing issues and what other
organizations do could be separated from the crisp policy statement
that code contributed to TinyOS should use a BSD-style license.

I find the whole comparison of the Alliance to the various other
organizations to be a little confusing; unless one is very familiar
with those other groups. Also it focuses too much on what the
Alliance *is not* rather than what it *is*. Perhaps this section
could be moved later in the document after it's clear what we're
trying to accomplish.

 > most strongly shaped by code of ethics, captured in organization  
rules
 > and social norms, rather than threats of legal reprocusions.

"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
 > accounting of potentially relevant IP.  We encourage the development
 > of open solutions that are implemented without the need for  
particular
 > proprietary IP.

I suggest spelling out "intellectual property" on first use.

 > The mission of the TinyOS Alliance is to provide a forum to  
facilitate:
 > ...

This should be moved up above the IETF, Apache, etc. comparisons.

 > In the steady state the Steering Committee will consist of the chairs
 > of working groups

Does it make sense to define what a working group is (roughly)
earlier?

 > Initially the steering committee would be formed from working group
 > chairs plus some subset of the Alliance working group members.  This
 > initial committee will be responsible for putting in place the
 > membership and elections processes, which will then be utilized to
 > form the regular Steering Committee.

 > The primary role of the Steering Committee (SC) is to oversee the  
Working
 > groups (WGs). This means establishing WG policy, providing appeals
 > process, managing WG creation/extinction, arbitrating between WGs,  
and
 > supervising activities to resolve conflicting directions and moving
 > the process towards overall architectural coherence.

These two paragraphs are somewhat redundant, and if they are not
redundant it is not clear what the distinction is supposed to be.

 > The SC is also responsible for reviewing and approving all TEPs.

We should define TEP as well (in case the document is circulated to
people otherwise unfamiliar with the term and concept).

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

This is a pretty confusing definition; how does someone join as a
"Member" and what does it mean (just being on a mailing list)?
Do we need this category of Member at all?

 > The typical output of a working group is technical documentation AND
 > working code, including interface definitions and standard proposals.

Something shold be said about what other work products a WG might
produce apart from technical documentation and working code.

Is "technical documentation" in the above equivalent to one or more  
TEPs?

What is the definition of "working code"? Should this code be made
available to the community under some license? Is it expected that
the code will be managed by a master source code tree maintained by
the Alliance? What is the relationship of this code to the
"official" TinyOS codebase? (Though it should be clear to current
members what the expectations are, somewhere they need to be spelled  
out.)
Alternately if these code maintenance policies are defined
elsewhere, say another TEP, reference should be made here.

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

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

This whole section should be reviewed carefully by a lawyer as it is
not clear what legal definitions are intended here - what is meant
by "operating with eyes open" for example?

 > Of course, Intellectual Property in the TinyOS alliance is closely
 > tied to source licensing terms, as dicussed in greater detail in that
 > section.

Perhaps refer to this section by name or number.

 > As part of Alliance rules, members agree to only check in code

Suggest changing "check in" to "contribute"

 > To address these matters, the Alliance has a preferred source license
 > based on the BSD framework ...

It may be worth referring to the New BSD License as approved by the
Open Source Definition:

http://www.opensource.org/licenses/category
http://www.opensource.org/licenses/bsd-license.php

Just to be concrete about what is meant here.

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

Define OSL here. Also, OSL-approved licenses span a wide range of
licenses (including GPL and Apache) which it was made clear earlier
were either not approved or not desirable. We should explain this
more carefully.