Three new proposed OSD terms

[Brian Behlendorf]

The compatibility issue is almost completely a red herring.

Let's first realize there's a couple different ways in which software can 
be "compatible".  You can put every Open Source package onto a single CD 
and redistribute that CD - that was the raison d'etre of the Debian Free 
Software Guidelines in the first place.   You can also write a web browser 
in any license and have it talk to a web server in any license.

Most of the world of software users are simply not going to have to worry 
about this.  If they engage in redistributing software under a license 
other than that which they obtained it, then yeah, they need to read up.

My company, and those of many of you, have no problem running services or 
even shipping products comprised of Open Source software under many 
different licenses.  There are complexities - I doubt it gets much simpler 
to explain than that put together by Larry Rosen and the folks at 
SpikeSource at <http://www.spikesource.com/license_corestack.html>.  But 
still, nothing stops e.g. SpikeSource from using, and contributing back 
to, each of the projects they incorporate into their distribution.

Where it gets somewhat interesting is when one project (X) wants to 
incorporate code from another project (Y) under a different license than 
the first, e.g. sublicensing.  Rarely is it possible for the terms of the 
license of X to also be satisfied by the terms of the license of Y.  That 
doesn't however, mean that they are incompatible; it simply means that 
when dealing with a derived work combining both, X+Y, you need to satisfy 
the requirements of both.

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

Finally, we see evidence of dual licensing or license changes to adopt 
more sublicensable licenses when such a change would prevent massive 
parallel efforts.  Mozilla's dual licensing under LGPL and GPL has 
appeared to have staved off the prospect of a large number of Gnome 
hackers spending too much time writing their own browser (though there's 
nothing wrong with friendly competition).  Likewise ObjectWeb very 
graciously relicensed some of their own JOnAS components under the MIT 
license so that Apache could pull them into Geronimo, on the premise that 
Geronimo would contribute bugfixes and other enhancements back.

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.

b) Egos, on the part of individual developers or of companies, for whom 
collaboration means capitaluation.  Whose passion for their own work or 
approach keeps them from considering working with a "competing" effort. 
Who think they've stumbled upon the "correct" approach to a problem and 
its worth should be self-evident.  Or whose business model rests too 
strongly on branding or "ownership" of a community.  There are good 
reasons for duplicating effort - when there genuinely are two different 
approaches to take to solving the same set of problems.  Or even different 
styles of development - one team focused more on production-system-quality 
conservative-change processes, another on shoot-from-the-hip 
try-new-ideas-until-something-sticks, with-good-unit-tests.  Or even 
wildly different personalities - you won't find Marc Fluery and Dain 
Sundstrum working on a project together in the future, nor should we 
consider it a tragedy unless they do.  But when such emotional resistance 
to working together on a common codebase is based on less defensible 
grounds, we should invest the time to ask why.  Rather than attack a 
symptom like license proliferation.


Of course, if you all want to channel that effort into convincing people 
to relicense under MIT or Apache, I won't stop ya.

 	Brian