[Tinyos-alliance] ata for bridge today?

Tue Apr 25 10:50:42 PDT 2006

Sorry
i have been travlieng - and cannot find the data.
Can somebody forward this to me,  please?
best
adam

Philippe Bonnet wrote:

>I agree with Phil and David. For our group and the companies I am working with,
>a BSD license plus social pressure is very much satisfactory.
>
>Best regards,
>Philippe.
>
>On 4/25/06, dculler <dculler at archrock.com> wrote:
>  
>
>>I'd like to pick up this thread and the SC role for tomorrows call.  Also,
>>we had some people working on some action items.
>>
>>I've come to agree with Phil's position on the license.  The more I looked
>>into introducing a new license in between BSD and Apache, the more I found
>>that I did not want to be innovating in this area as a prerequisite for the
>>alliance.  The BSD has held us well.  I'd like to stick with it and provide
>>the tools and the social pressure to credit contributors.
>>
>>
>>
>>-----Original Message-----
>>From: Philip Levis [mailto:pal at cs.stanford.edu]
>>Sent: Monday, April 24, 2006 11:28 AM
>>To: David Culler; dculler
>>Subject: Source licenses document draft
>>
>>Summary: The approach we've been discussing for source licenses has a
>>serious problem, which I describe. There are two feasible solutions:
>>all Alliance code is owned by the Alliance, or the Alliance follows a
>>BSD model. There is a third but unattractive solution, that the
>>Alliance greatly limit who can contribute code. I argue that the BSD
>>license is the best solution.
>>
>>-----
>>
>>The major distinction between the Apache and BSD licenses is this
>>simple line:
>>
>>"The end-user documentation included with the redistribution, if
>>any, must include the following acknowledgment:
>>
>>   'This product includes software developed by X'"
>>
>>The Apache Software Foundation owns the copyright to all software
>>under the Apache umbrella, and requires that the attribution be to
>>the Apache Software Foundation. There are a few other distinctions
>>(e.g., the Apache license says that you can't use Apache in their
>>name without prior permission), but the attribution requirement is
>>the major one we've been discussing. Both the BSD and Apache licenses
>>require that you distribute the copyright notice with the software.
>>
>>The proposal currently on the table for the TinyOS Alliance is to use
>>an Apache license, but with individuals holding the copyright and
>>requiring individual attribution. There are a few minor issues with
>>changing licenses, such as transitioning code over (everything now is
>>BSD), but for the most part I think they could be overcome with
>>enough effort. TinyOS has historically been BSD (very few strings
>>attached), and it might take some time to inform everyone of the
>>change, but it's definitely possible.
>>
>>The much more significant problem and the source of my reservations,
>>however, is the fact that the Apache requirements are controlled by
>>individuals. If someone uses code from the Alliance, it is not the
>>Alliance that enforces the license requirements, but rather the
>>copyright holders. The Alliance would like its codes to be used as
>>widely as possible, and seeks to achieve this through a community
>>process and technical excellence. The issue that individual copyright
>>holders raise is that a lawsuit -- or even threatening a lawsuit --
>>could have a chilling effect on the use of TinyOS Alliance codes.
>>With the BSD license, this is a very minimal issue, as it pertains
>>only to liability, while with the Apache license it could be a
>>significant issue, as it pertains to attribution.
>>
>>The situation I foresee is one where the best interests of an
>>individual contributor are not aligned with those of the Alliance as
>>a whole. For example, group A checks in some code, which group B
>>sells but (innocently or intentionally) does not properly attribute.
>>It could be in group A's best interest to sue group B for violating
>>the license, or at least threaten a suit to gain concessions.
>>However, it is very unlikely to be in the Alliance's best interest
>>that suits be threatened, due to the chilling effect it might have on
>>adoption and use. This situation becomes even more dangerous if a
>>group that has contributed code decides that selling its proprietary
>>versions of the reference services would be well served by throwing a
>>wrench into the Alliance reference implementations.
>>
>>In short, the more requirements we place on users, the greater the
>>chance that they'll make a mistake. This could make the Alliance
>>vulnerable to harm caused by the actions of contributors who are
>>acting in their best interest when it is not the same as the Alliance's.
>>
>>One simple solution to this is to require all code to be owned by the
>>Alliance. But that goes against the original motivation of the
>>attribution clause, which is giving credit to individuals.
>>Furthermore, this requires companies and individuals to surrender
>>their work. I had originally said that this might be problematic for
>>people at universities (myself included); I believe that if we must
>>go down this path, we can do it (I'd be willing to make the case to
>>Stanford), but I don't know how companies (e.g., Intel, Crossbow,
>>Motorola, etc.) might feel on the matter.
>>
>>If we use an Apache license, then I believe that we will just be
>>pushing the problem to the next level: controlling who can check in
>>code. For example, if a company who is competing with TinyOS (there
>>aren't any today, but there might be in the future) tried to check
>>code into the repository, I can imagine personally resisting the
>>effort. Suddenly the Alliance will need to control who can check in
>>code in order to protect itself from harm by lawsuits or threats of
>>lawsuits issues by its contributors.
>>
>>Furthermore, once there are individual attributions, we'll need to
>>establish exact rules for when files can be replaced. As a particular
>>example, consider the CC2420 stack in 2.x. I originally took Joe's
>>stack from 1.x and improved on it in several ways. Borrowing a few
>>ideas from my work and adding many of his own, Jonathan Hui did a
>>clean and complete rewrite of the entire stack and (with my
>>permission and thanks) replaced mine with his own. I have enough code
>>in 2.x that there's little danger such a change would remove me from
>>the attribution list, but I can imagine that if the only thing I had
>>written was the CC2420 stack I might have objected. Who gets to
>>determine when files are replaced, renamed, or appended? This seems
>>like a tremendous Pandora's box, and therefore not a good solution.
>>
>>I believe that these concerns mean we should use a BSD source license
>>policy. Requiring the stronger of the two BSD-derived licenses (the
>>Intel/Arched Rock/etc. one) would simplify matters, and I suspect
>>that few using the weaker of the two (myself included) would have a
>>major concern in switching. Of course, polling the contributors on
>>this change would be an important step to make sure that limiting the
>>set of licenses is possible. Following this approach would minimize
>>the onus on users of the code, would make the Alliance safer from
>>harm by conflicts between its contributors and users. Most
>>importantly, however, I believe this would lower the bar for
>>contribution, as the Alliance would not have to institute a policy of
>>controlling contribution, replacement, etc.
>>
>>Removing the legal requirement of attribution does not prevent
>>attribution. Instead, we can clearly state in TEP 120 that the
>>Alliance expects its members to acknowledge each other's
>>contributions, and asks users to do the same. In practice, I believe
>>this will have the same effect, in that almost everyone will provide
>>the appreciated acknowledgments. However, it means that a mistake by
>>a user does not open them to litigation, and therefore does not open
>>the Alliance to the harm caused by such litigation. Making this
>>attribution as simple as possible -- several technical approaches
>>have already been proposed -- would further help in this regard.
>>
>>I understand that this is a reversal of my original position, in
>>which I believed that Apache would be a reasonable solution. After
>>thinking about it more deeply, however, and considering the long-term
>>complications it might cause, I believe that a BSD license is the
>>best solution.
>>
>>Phil
>>
>>
>>
>>
>>_______________________________________________
>>Tinyos-alliance mailing list
>>Tinyos-alliance at millennium.berkeley.edu
>>https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-alliance
>>
>>
>>    
>>
>
>_______________________________________________
>Tinyos-alliance mailing list
>Tinyos-alliance at millennium.berkeley.edu
>https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-alliance
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-alliance/attachments/20060425/f5a144a8/attachment.htm