A prototype License Wizard up and running
bruce at perens.com
Fri Apr 8 06:36:52 UTC 2005
> Yeah, it [my HTML posting] didn't seem to make it. :-/
Well, I'm glad the list doesn't make me use Morse code. OK, here it is
again, translated to flat ASCII for dinosaurs :-)
Chuck Swiger wrote:
> A few minutes to walk the decision tree gives the following list:
> GPL, BSD, Mozilla (MPL), OSL, CPL, CDDL, and LGPL.
You can actually get this down to three licenses, with terms on
derivative works classified as:
Enforced sharing: Terms must apply to all derivative works, and the
license terms are such that callers of the code are considered
derivative. This is what Rosen calls a Reciprocal license in his book.
Gift: Rosen calls this an Academic license. No significant requirements
other than attribution.
Share-Gift mix: Sharing terms apply to a separable work such as a
library, but not to a larger derivative work.
Having selected licenses for those three sets of terms, you can apply
them to all of these common business purposes for Open Source. I have
stated them as goals, rather than the way you stated them which would be
difficult for people to understand.
Dual-licensing - Open Source with a revenue stream from proprietary users
The software is made available under two licenses: a Sharing Mandiatory
license that is offered to all comers, and a non-Open-Source
"proprietary" license that is offered only to customers who pay some
sort of fee. The proprietary license explicitly allows the distribution
of proprietary derivative works. Customers who wish to produce
proprietary derivative works can develop their code under the Open
Source license but must secure the proprietary license before
distributing those works. For example, MySQL uses the GPL in parallel
with a proprietary license of their own creation.
When companies that operate dual-licensing accept modifications from
their Open Source community, they must have the right to apply their
proprietary license to those modifications. Thus, they must acquire
either a right to relicense or a copyright assignment from each
contributor. Sun Microsystems has settled on a joint copyright
assignment for OpenOffice, which gives Sun all of the rights of a
copyright holder, while the author of the modifications keeps those same
Releasing Open Source while maximally restraining proprietary competition
In some cases a company will wish to carry on a collaboration with an
Open Source community, while restricting their competitors as much as
possible. The Sharing Mandiatory license removes the financial incentive
from proprietary modifications, by requiring that they be distributed to
all comers in source form without charge. When I write Open Source
software with my own funding rather than for a customer, I apply the GPL
license, because my desire is to increase the amount of software that
people share, rather than be the unpaid employee of some proprietary
software company that benefits from my work while returning nothing. If
such a company did wish to use my code, they would be welcome to contact
me and negotiate a commercial license.
Open Source tool kits intended for building proprietary applications
Some software is intended to be part of a larger application that may be
proprietary. An example of this is the Ruby on Rails web application
framework or the GNOME graphical user interface toolkit. When the
creator of such software does not desire to gain revenue from the
software through a dual-licensing paradigm, the software should be
issued with a Share-Gift Mix or a straight Gift license.
When you want everyone to do things your way
Most successful standards today that are developed in parallel with an
Open Source reference implementation. When you want everyone to do
something your way, for example when you are promoting a standard and
wish all developers, both proprietary and Open Source, to implement some
facility in the same way, you should issue software that implements that
facility and is under a Gift license. The gift license is minimaly
intimidating to proprietary developers, and thus makes it more likely
that such developers will include your implementation in their product.
When you want to restrain people from doing things any other way
The problem with a Gift license for a standards reference platform is
that it makes an embrace-and-extend strategy possible. This strategy,
usually attributed to Microsoft, is a means for the dominant vendor in a
market to take over an open standard and divert the user community to a
proprietary derivative of that standard.
To do this, the vendor implements a product making use of the standard
along with extensions. Patents and copyright are used to protect the
extensions so that they are not available to Open Source developers and
so that competitors can not use them or would have to license them for a
fee. Then, the vendor distributes the implementation for free. Microsoft
would generally have the program installed automaticaly with an upgrade
of their operating system. Once users upgrade, the proprietary
application becomes the one used by most users, and sunddenly
implementations based on the open standard are no longer compatible with
the majority. In a well-known court case, Sun Microsystems accused
Microsoft of attempting to do this with the Java language, and driving
users from Open Standards to Microsoft-specific versions has been viewed
as the strategy behind Internet Explorer and other Microsoft web efforts.
In response to Microsoft's actions with Java, Sun created a license that
attempts to poison embrace-and-extend tactics, called the Sun Community
Standards Source License (SCSSL). That license has terms similar to a
Gift license, except that it requires the producers of extensions to
make a reference implementation of new extensions to a standard freely
available. The reference implmentation did not have to be the same code
that was used in a distributed product, but it had to demonstrate how
the extension worked in a way that could be used by the creators of the
standard and all other parties. This license was applied to OpenOffice
as an alternative to the GPL. Sun representatives voiced dissatisfaction
with the result - which was that IBM was able to make proprietary
derivatives of OpenOffice because of the gift terms. This seems to be a
flaw in Sun's licensing strategy for OpenOffice, rather than a failure
in the SCSSL license.
But a Sharing mandiatory license like the GPL would be a simpler
strategy to restrain embrace-and-enhance than the SCSSL. The problem is
that a Sharing mandiatory license does not allow proprietary derivative
works, and developers of standards generally do intend to make such
Some Open Source work is funded by taxpayers. Such is true for
university research that is supported by government grant. When the
taxpayers have paid for software work, it is the property of all of the
taxpayers. Those taxpayers should get the maximal possible utility from
that work: they should be able to make use of it in all contexts,
including within a work of proprietary software. Thus, the Gift license
is appropriate for taxpayer-funded software.
In contrast, some have suggested that it is in the interest of the
taxpayer and government to promote open standards as much as possible
because of the level economic playing field for fair competition that
such standards create. Thus, it would be appropriate to prevent the use
of embrace-and-extend tactics, as discussed above.
Releases of corporate research
IBM has a maxim: If you aren't going to give it away, throw it away!
This is in regard to the research work they carry out, and means that
non-product research work that is not released to the public might as
well be thrown in the garbage for all of the good it does them. Just
keeping it on the shelf and waiting for another company to license the
work doesn't attract enough attention to make any other company want to
license the work. Research is more likely to spawn a commercially-viable
result when people are using it, even if those people aren't inside of
the company that created the research. A Sharing mandiatory license is a
good choice for the results of research. The GPL, for example, contains
a patent grant that allows patents to be used in all GPL software, but
retains for the company owning the patents the right to restrict the use
of those patents in non-GPL settings. Thus, it allows research work to
grow outside of the company while retaining a proprietary advantage that
the company can use once that research has spawned a commercial avenue.
I'd be interested in hearing about additional business purposes to the
ones I have listed above.
The specific licenses I apply to the three sets of terms on derivative
works are currently:
Sharing mandiatory: the GPL. I was going to try Rosen's OSL for this,
but Rosen insists that the OSL would not disallow a proprietary
application from using an OSL library and I am currently looking for a
tightly-binding license as an alternative to the GPL. Any suggestions?
Gift: Post-1999 form of the BSD license.
Share-Gift Mix: GPL with exception allowing larger derivative works to
not be covered by the GPL. Some would use the LGPL here, but the GPL
with exception means one less license to understand.
You have probably guessed that this is part of a paper I'm working on. I
could make a web application that walks you through the decision
process, but I'm not sure that would be more useful than having people
read the paper and understand the situation a little better.
Or should I say -... .-. ..- -.-. .
More information about the License-discuss