[Tinyos-alliance] Further thoughts on licenses

[Matt Welsh]

Rob,

Your comments are very helpful and it's good to get a sense of where you
are coming from.

I am hesitant to enter into this debate but would like to offer some
perspective. In the early days of Linux there was a lot of hand-wringing
about what would happen if a company were to take the code and basically
rebrand it without giving credit to the original developers. Likewise in
the Linux Documentation Project we had a lot of worries about the
documentation and books being modified or redistributed without
attribution. More than a few USENET posts and mailing list threads were
spent debating these issues and trying to resolve this tension between
the desire to make things easy to adopt and extend, and the desire to
give credit where credit is due.

In the end, almost everyone got over this worry and recognized that, on
the whole, nobody is out to appropriate existing Open Source projects
without giving due credit. These early fears have simply not been borne
out in any significant scale. True, it may be there have been some cases
of abuse, but that can happen regardless of the license. I personally
had one of my online books extensively plagiarised and published in
paper form without my consent, although it was clearly a violation of
the copyright license to do so.

In the end, I think the structure we have seen emerge in nearly every
Open Source project -- regardless of licensing structure -- is that
there is a fairly well-established "code of ethics" that ends up being
quite effective despite its informality. On one hand the lack of legal
teeth does in fact make it easier for companies to play without too much
encumberance, and on the other the recognition that should a company or
individual violate the "code" they would be brought to task, quite
publically, for doing so. Perhaps it is not as clear cut as a legally
binding license, but nevertheless it seems to work quite well in
practice.

It is a good question is whether members of the TinyOS community would
exhibit similar good faith in their dealings with one another. This is a
classic case of "coop-etition" and I think one of our goals is to make
the conditions right for the watering hole to be mutually attractive to
all of the players.

Matt




On Tue, 2006-03-14 at 11:08 -0800, Robert Szewczyk wrote:
> Hi all 
>  
> At the closing of our last phone call David pointed out the careful
> balancing
> act that we have to perform, and suggested that one way to achieve it
> is with
> a an explicit code of ethics rather than strongly worded and
> adversarial
> license.  There was a question posed in there as to the nature of the
> community we are trying to build.   
>  
> From my point of view, the thing I desire the most is clarity: I want
> to know
> what the rules are, and what are the penalties resulting from breaking
> these
> rules.  I want to know what is my legal exposure resulting from
> participating
> in the community.  I believe that for most commercial companies the
> main deal
> breaker in adoption is uncertainty; consequently, anything that can be
> done to
> minimize that uncertainty should be good for adoption.  Code of ethics
> does
> not really accomplish that.  While in principle I am not thrilled by
> the
> negative language, could we come up with an example of an entity whose
> participation would be so valuable in the process that we would not
> choose not
> to enforce the licenses to the letter?  
>  
> A successful and vibrant community can be build around restrictive
> licenses,
> such as GPL.  GPL contains several clauses that spell out the
> consequences of
> the license breach and contains several stipulations as to what should
> happen
> in case of a legal proceedings involving the licensed code.  Despite
> that both
> open source projects and commercial ventures have grown using that
> license,
> and the communities they involve are creative and productive.
> Similarly, it
> appears that the Apache license (and project) are supported by a
> number of
> corporations -- Intel and IBM spring to mind.  Consequently I believe
> that the
> language in the license may have quite a bit of latitude. 
>  
> My position is that the BSD copyright contains plety of incentives to
> adopt
> the code, but not enough incentives to contribute the code back into
> the
> tree.  My company has determined that Apache license does contain
> enough
> incentives and protections for us to distribute the code.  We added
> two
> additional provisions to the license, but we would be satisfied if the
> license
> equalled exactly Apache 1.1.   
>  
> Ultimately, I believe that the best way to lower the barriers to
> adoption is
> to adopt the EXACT language of a small set of mutually compatible open
> source
> licenses, with the modification that the copyright belongs to the
> author.  As
> a strawman proposal I would put forth New BSD and Apache 1.1.  By
> sticking to
> exact language of the licenses we ensure that the legal departments of
> the
> various participants will have to deal with well understood (and
> likely
> resolved) issues. 
>  
> The consensus within the group last time around was that the proposed
> scheme
> was very complex, and complexity is clearly a good thing to avoid.
> Would you
> feel that this proposal (Apache or BSD with NesC docs to produce
> appropriate
> documentation) shares the complexity problem of the previous proposal?
> I end
> up thinking about concrete examples in use; if this proposal is too
> complex
> could we come up with examples where the burdens presented by Apache
> and BSD
> licenses are too high for someone to adopt TinyOS?  
>  
> Rob
>  
> Robert Szewczyk
> Moteiv Corporation
> _______________________________________________
> Tinyos-alliance mailing list
> Tinyos-alliance at millennium.berkeley.edu
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-alliance