Viral permissiveness

[dtemeles at nvalaw.com]

Steve,

While the FSF's claim that code can be re-licensed in toto under the  
GPL by someone other than the author of the work is an interesting  
read, the claim wholly ignores copyright law.

A non-exclusive license is an agreement by the licensor not to sue the  
licensee for using the code in a manner that absent the license would  
infringe the monopoly rights granted under the Copyright Act to the  
licensor.  If the licensor is not the author of the code or an  
exclusive licensee (ergo assignee) of one or more copyright interests  
in the code, then the Copyright Act does not grant any monopoly rights  
to the licensor.  Therefore the licensor would have no right to sue  
for infringing the re-licensed code in the first place.  In short, a  
non-exclusive licensee of code cannot sue others for "infringing"  
copyrights in that code because he has no copyrights in it.  He would  
have copyrights only in the modifications he created.

A wise professor once told me to always follow the money when  
analyzing any business issue.  I think there is a helpful corollary or  
refinement of this adage in analyzing open source license issues -  
always follow the copyrights.

Dave


Quoting Steve Thomas <steve.thomas.private at googlemail.com>:

> Jeremy:
>
>> I have seen multiple mentions on this thread about "relicensing" a BSD
>> licensed code as GPL.
>
> "relicensing" as meant in this thread is a restricted kind of
> sublicensing as described in thread [1]. Please read thread [1].
>
>> Nobody except the copyright owner can change the license.
>
> This is strictly true, but read on.
>
>> If a different license is added it is only for the new code. It doesn't
>> change the license for the original existing code.
>
> It depends on precisely what you mean by "only for the new code". The
> FSF in your reference [2] says:
>
> "The GPL is a copyleft license; it formally requires that modified
> versions of GPL'd programs be distributed under the terms of the GPL.
> Although the issue of the breadth of the GPL copyleft on modified
> versions is beyond the scope of this document, it is significant that
> most GPL licensors have refused to adopt a narrow view of what causes
> added code to fall under the copyleft requirement. Developers
> incorporating permissive-licensed code into a GPL'd project can
> generally assume, then, that the totality of the modified project is
> covered by the GPL."
>
> So "the totality of the modified project", including maybe even a
> _verbatim copy_ of code taken under a BSD-license, "is covered by the
> GPL". Also, again in [2]:
>
> "3.2 Requirements of the permissive license
>
> The other half of the question is whether the non-GPL license presents
> any obstacle to incorporation of the code it covers into a larger work
> that is covered as a whole by the GPL's copyleft. For most who are
> familiar with such licenses, the answer might appear to be obvious,
> but it deserves some attention. The terms of permissive licenses allow
> unlimited modification and redistribution in source or binary form, so
> long as the stated minimal notice preservation requirements are met.
> An isolated reading of these simple licenses, in ignorance of
> historical community practice, can in some cases support more than one
> interpretation, depending on whether certain permissions are implicit
> or explicit and on the treatment of that difference under local law.
>
> From the beginnings of their use, however, the permissive licenses
> have been understood by their licensors and licensees alike to permit
> the code they cover to be incorporated within larger works covered as
> a whole by more restrictive terms, including more restrictive FOSS
> licenses like the GPL as well as, indeed, by proprietary licenses.
> This understanding represents the uninterrupted, longstanding practice
> and expectation of the global information technology industry,
> including both its free and proprietary divisions, with vast
> commercial reliance on the result. As such, disruption of the
> established interpretation of the permissive licenses is neither
> likely nor desirable."
>
> For what it's worth, I am also a legal naif who made an "isolated
> reading of these simple licenses, in ignorance of historical community
> practice" and formed a similar half-correct understanding to yours -
> held until quite recently. The fact that BSD-licenses can be, and
> often are, straightforwardly relicensed (in the sense of [1]) is
> crucial in the context of this thread.
>
> Matthew > I fail to see how you could draft a license that is both
> copyleft and permissive.
>
> I meant permissive relatively, as in the opposite of restrictive:
> "contract A is more permissive than contract B". Unfortunately, the
> convention is to use the term "permissive" - without a capital P - for
> non-copyleft, highly (relatively) permissive, easily relicensable
> contracts, like BSD. I should have adhered to this silent didacticism
> - apologies.
>
> The contract I am interested in would, pivotally IMO, be more
> permissive/less restrictive than the GPL in respect of binary
> distributions but also will probably have to be less permissive/more
> restrictive than the GPL in regard of the ability of creators of
> derived works to not "reciprocate" := license modifications of
> contributions back to the contributors on the same terms as the
> contributors' original license. Probably. Otherwise I'll be ...
>
> Remco > [..] just as arrogant and altruist-abusing (not my words).
>
> Not your words, but you did choose to use them.
>
> --
> My GnuPG key ID is 0x82314996
> Preferred keyserver: hkp://subkeys.pgp.net
>
> [1]   
> http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:15800:200804:ofojehedfieaofmbhbna
> [2]   
> http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
>