Three new proposed OSD terms
brian at collab.net
Fri Mar 4 00:25:42 UTC 2005
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.
More information about the License-discuss