Three new proposed OSD terms

[Jason White]

Brian Behlendorf writes:
 > 
 > The GPL license is the *ONLY* one I can think of at the moment that says 
 > that if either X or Y is GPL, then X+Y must be GPL, modulo "mere 
 > aggregation".

The OSL is similar in that it requires derivative works which you
distribute to be made available in turn under the OSL.

 > There are some licenses, the LGPL, MPL, CPL, CDDL, etc., 
 > that say under certain conditions, if X or Y is that license, then X+Y 
 > must be also put under that license.  But most of the licenses don't even 
 > go that far - they have terms that apply only to the work and those 
 > portions that survive in derivative works, but not to new IP of your own 
 > in your modifications.

Indeed, but for the class of licenses identified above, (these have
sometimes been referred to as "reciprocal licenses") there can arise
compatibility problems: it may not be possible jointly to satisfy the
conditions of two such licenses while combining code distributed under
them to form a derivative work. This may apply at file boundaries as
in the MPL and similar licenses, or it may preclude the sharing of
code altogether. This is a genuine problem which demonstrates why the
proliferation of mutually inconsistent reciprocal licenses should be
of concern.
 > 
 > Martin Fink's "clear and present danger" isn't in the multiple licenses. 
 > I'd contend it's in two other places:
 > 
 > a) Software projects that do not take contributor agreements or 
 > distribution licenses that allow the license on a project to be changed. 
 > Apache has the ability to change our license in the future because 
 > developers give us the necessary rights to do that (without assignment). 
 > Likewise with the FSF, OpenOffice/Sun, and a few others, but notably this 
 > is not the case for Linux, JBoss, or other projects.  Without that right, 
 > we can't fix defects in our licenses that would allow for greater 
 > sublicensability by other teams, and therefore greater reuse.
 > 

I agree this opens the way to solving the problems of license
incompatibility and code sharing, albeit on a project-by-project
basis. It also has the advantage of allowing, in Eric Raymond's
memorable phrase, projects to adopt new advances in "licensing
technology". Perhaps there should be recommended terms to be used in
distribution licenses or contributor agreements that provide the
project with the flexibility to adopt a different license as
circumstances warrant.

The freedom of the project's maintainer or governing body to do this
would have to be carefully circumscribed, however, for example to
preclude the subsequent adoption of a license that is not open source.
Also, some developers who work on projects subject to licenses such
as the GPL or OSL may object to relicensing, or dual licensing, under
terms permitting their contributions to be incorporated into
closed-source software. Consequently, the scope of the freedom to
change the license has to be defined carefully, along with the manner
in which such a decision can be taken within the project. Doubtless
the OSI will consider these and related questions when, as has been
foreshadowed, issues of project governance and best practice are taken
up.