[Tinyos-alliance] FW: Source licenses document draft

Tue Apr 25 06:06:12 PDT 2006

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