A prototype License Wizard up and running

[Bruce Perens]

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


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 
works possible.


Taxpayer-funded work

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.

Thanks

Bruce

Or should I say -...  .-.  ..-  -.-.  .