[Tinyos-alliance] FW: Source licenses document draft

[dculler]

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