[Tinyos-alliance] 2006/02/07 Telecon Notes

[Kristin Wright]

-------------- next part --------------

2006/02/07 TinyOS Alliance Working Group Notes

Present
---------
David Culler
Mike Horton
Joerg Bertholdt
Ramesh Govindan
Kristin Wright
Lama Nachman
Philip Bonnet
Phil Levis
Rob Szewczyk
Deborah Estrin 

Agenda
----------
- Take stock of what we have thus far.
- Discuss what we have ready for report-out at ttx.

Discussion Notes
----------------------------------------------------------------------------
David sent a draft of a set of slides. 
http://mail.millennium.berkeley.edu/pipermail/tinyos-alliance/attachments/20060207/5de2c9d8/alliance-wg-0001.ppt
Most of the meeting we went over each slide pausing for discussion.

Slide 2:
david: Would like for people to look at Charter in slides and think about
revisions. Useful to be able to establish baseline of bg organizations. 

Slide 5: 
david: took a cut at distilling various inputs from 1st meeting
georg: broaden community; alliance as an ecosystem around tinyos;
doesn't define it per se 

?: how does tinyos interrelate with other standards in the broader embedded 
network space. would be good for people to want to see why they'd want to
join the alliance.

david: charter on slides is charter of this working group; 
those questions might need to exist in some sort of FAQ; charter
of wg to formulate a framework.

mike: charter okay for internal purposes, but for actual alliance
should include reasoning for why one would want to join 

culler: key issue: scope of alliance and how that is defined; how that message
is communicated outside the scope of this wg; perhaps there's a marketing 
wg in the future; this wg scope things the alliance should worry about and 
what not to worry about.

slide 5: 
david: kristin put forward quite strongly that we're about the 
community itself; discussion in first there was a lot of how that source
is maintained, developed, etc.; to what extent does that happen within
the alliance or ; tried to capture key elements in slide 5

david: ramesh and kristin had a nice set of notes; most of the way on
that one. may want to refine to some degree to capture the notion of a
scope.

slide 6:
david: carried some of ramesh's words forward; keep structure light;
expect that wgs can expand to include non-technical; what we don't see
is the additional level tht in the IETF is the architectural board;
also have a BoD, but the notion is that a lean, mostly volunteer

deborah: ietf started with an archit before a steering comm. ; agree that
lighter earlier makes sense

david: there may be a question of terminology

slide 7:
general sense-->membership broad; keep barriers low; encourage organization 
that is a meritocracy (vs quid pro quo) ; in email list, there was a sense
of not getting hung up on developers because we care a lot about how
technology gets adopted; like ietf and apache, focus first on individuals
and individuals that write code; individuals make decisions; proposal is
an Alliance Member: anyone willing to sign up; Contributing Member: joins
working group, speaks up; fees minimal ; Corporate Member: do we have tiers,
dollar amounts, all kinds of things to maximize alliance. Contributing 
Corporate Member: they contribute enough for steering committee to recognize.

mike: from our perspective this looks great

david: do we need to have lots of benefits advertised up front? discussion: no
rewards you get are success of organization; if we're able to create a 
success we're better off thinking we're milking dollars

mike: benefit is reference implementation; fact that it's not a
pay-to-play system has a level of appeal; would stick with it as is

david: not sure if I captured this entirely; steering committee is the 
heart of the alliance 

slide 8:
philip: workload on a wg chair is high; should modify steering comm. to
reflect this issue
david: probably important to have steering comm members that 
weren't wg chair; role of steering committee pretty clear (had little debate)

slide 9:
david: ramesh proposal: 2 classes of wgs: long-standing and short-term; 
grassroots or chartered

slide 10: ip
david: as soon as we talk about elected members the question comes up: who
gets to vote? every member? every participating member? or soem 
weighted function? 

philip: giving a contributing member a right to vote ; mean both
individual and corporate

ramesh: ietf worked like this: membership in arch board and steering
group, members are nominated by nominations committee chosen randomly
annually; they get to solicit communtiy input on who shold be
nominated for open positions and they vote on ; submit nominations to
ISOC;

david: voting can be a pain to manage

ramesh: voting memebers chosen my nominations; attended at least 2 IETFs 
in last 2 years; mark of being active

lama: one question: have the details been worked out regarding 
contributing vs non-contributing members? 

david: we have not worked out the details; might not be extremely important
at this point to police that line; should kind of take care of itself

lama: if we link that to the vote thing, it becomes more important 
to define it.

david: right. could have some mechanism where someone forwards some 
trivial documentation; would certainly err in the direction of being 
inclusive; attending meetings would be sufficient; in ietf, there are
many more people who attend meetings than are in wgs

deborah: ramesh, is that true?

ramesh: number of active particpants (those who enter the discussion
but are not part of active set; within a wg thre's a small set of
active members)

david: is there an organizational vote? philip suggested that concept.

ramesh: here again we could est a prin wherein bofD governed by 
constituents; comp of steering group coverned by individual 
contributions; that is model of IETF 

david: corporations ; OSDL: coporations vote; voting clout connected with
how many dollars 

philip: can imagine companies joining all with some form of contribution
which may not be technical but they might be interested in having some
form of influence 

david: other than technical contributions, what gets influence? in 
discussion so far: hell no money won't buy us. but perhaps in promoting

philip: dollars shouldn't buy decisions 

lama: what become sticky is how do we measure contribution

david: not necessarily weighting your contribution; if everyone is
using your code, you don't get another vote but you likely get more
day-to-day influence

david: does anyone feel strongly about having corporate vote? about not 
having corporate vote? <silence>

philip: what is being decided?

david: steering committee composition

david: other places where voting plays out significantly?

david: boils down to who's in what seat

deborah: important point in terms of architectural oversight.

ramesh: steering group function would oversee

deborah: by default, where final decision gets made; when something is
going wrong, have to take some action to step in

ramesh: if we make as part of process that steering group must approve
output, adds level of oversight

deborah: bigger steps like things going on to standardization; don't
get in the way of progress because things ; part of success for things
to move to being standardized there's an explicit review

david: steering committee role on slide 8 ; concept gets captured

deborah: curious is ramesh thinks its a good thing and still working?

ramesh: seemed to be working reasonably enough 4 years ago

david: contributing members vote primarily for committee positions; 
steering committee has decision making role 

deborah: each member of steering committee keeps eye on working groups
so you don't have things fall through the cracks

slides 10 & 12:
david: promote tech, avoid getting trapped in IP holes, 
taken position that may be a little beyond our discusison;
believe you should be able to join alliance without signing over IP
ietf discussions, presentations, etc. non-confidential; day-to-day 
things stay in the open; all the organizations have mechanism for 
declaring relevant IP but if you don't declare, really a cultural
phenomenon; all have some mech for contributing IP; very problematic
as soon as you try to create an IP pool. people complain IETF 
naive 

lama: what do you mean by contributing IP to the alliance? 

david: if your code is BSD you may have filed a patent; 

lama: once you do that what does it imply about your piece of IP? is
it saying that any member can use it; are you giving up your rights?

david: could you partially contribute? apply ietf mechanism: have
a way of giving a royalty free license to use and it is not limited
to ietf; ietf provides a mech for doing that; personnaly: think it
thorny if you say "i'm going to give this buy only to people who are
part of this alliance". if you've developed something and you happen
to have patented it and you want to contribute it, you have to have
some mechanism for moving forward. Very different from saying "you 
must". 

lama: why would you envision one wanting to do that?

david: if you're a wg chair and you're leading your wg down garden path to 
your own patented solution, ; allows working group to understand where you're
coming from; people are less likely to listen to your advice later.

david: make it very clean that that is the expectation 

deborah: truthfully I don't know; nervous because it's hard for me to
play at all the possibilities 

lama: think it makes everyone nervous; should we add
'declaration of relevant IP'?

phil: quoted ietf policy on IP declaration

mike: could expand upon that mechanism for declaring existence of
relevant IP; like the 'relevance' of it. like the way it's written in 
IETF

deborah: but could get sued for patent infringement; 

mike: people come around and sue each other for business factors; if 
someboday has any ip at all that's relevant ; trying to use the alliance
to protect member companies seems like a tall order; zigbee model: sort
of work getting into the IP, but does make stuff unattractive; generally
am supportive of this position

phil: anything you submit you grant a non-exclusive license unless you
state that you have IP connected to it

mike: that's a very clear statement; either you grant it or you declare
it; corner case: grant something accidentally 

lama: exactly: there's quite a bit of stuff that happens here that
you don't know about it

david: does intel not participate in the ietf?

lama: no they do. i sent question to one of the lawyers. in the past there
has been an issue of doing the IP search. 

david: fair to say that on friday this issue will not be completely 
resolved. facilitate development and not become a police force and 
not become an inhibitor to innovation

mike: ietf policy sounded very clear and crisp and makes a tremendous amount of
sense; would like that

david: terms of source license; phil added some input via email; it's
trickly once you get outside of BSD license; if your view is that the al.
is producing reference implementations maybe that's good enough. will
probably remain gray on friday but could make some progress email.

mike: bsd: benefit is that what it's done

david: let me try a particular one: rob went into variants and
discussion pushed in dir that there should be a single uniform 
license; my view: impractical. people can use their small variants
of BSD and someone could be responsible for "yeah, this is clsoe enough'.

mike: would agree on that

phil: when issue raised originally thre was another concern: nice if
authors could have some recognition; 

david: universal or not? 5 of 7 said universal and personally thought it was 
impractical. also, said that they sign code over to alliance.

david: idea: establish what are acceptable licenses

phil: there are variants of the apache that require that you put
an annotation in the documentation. 

philip: argument from rob was pretty convinciing; for  a set of companies
to have their contrib recognized is reasonable

david: people like to be recognized; comes back to a question of enforcement

david: are these slides okay in general? <yes> between here and friday
try to do by email.