[Tinyos-alliance] ata for bridge today?

Tue Apr 25 10:55:51 PDT 2006

I just setup a bridge, here is the info:

Tuesday, April 25, 2006 11:00 AM US Pacific Time 

Where: 8-356-2663, 916-356-2663, Bridge: 2, Passcode: 9290873 

Lama

________________________________

From: tinyos-alliance-bounces at millennium.berkeley.edu
[mailto:tinyos-alliance-bounces at millennium.berkeley.edu] On Behalf Of
Adam Wolisz
Sent: Tuesday, April 25, 2006 10:51 AM
To: Philippe Bonnet
Cc: tinyos-alliance at millennium.berkeley.edu; dculler at archrock.com
Subject: [Tinyos-alliance] ata for bridge today?

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> <mailto: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-all
iance

_______________________________________________
Tinyos-alliance mailing list
Tinyos-alliance at millennium.berkeley.edu
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-all
iance

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-alliance/attachments/20060425/e19bb2cb/attachment-0001.html