Free Software Licensing Strategy -- Some guidelines

[Tom Hull]

kmself at ix.netcom.com wrote:
> 
> A work in progress for some time, but somewhat prompted by the IPL
> discussion yesterday, I thought I'd cast this out to the wolves.

Thanks for the meat.

> Intent is to provide a reference addressing more strategic than legal
> considerations for those contemplating entry into the free software
> licensing fray, either with an existing or a novel license.  While I
> have some biases, I'm generally trying to present a relatively centrist
> (from the FS/OS world) view.
> 
> ------------------------------------------------------------------------
> 
> This document originated as a response to a posting on the CNI-COPYRIGHT
> mailing list asking for some very general advice on choosing or creating
> a free software license.  I feel it may be helpful as a strategic guide
> to others.  It is not intended as legal advice.  I _am_ interested in
> feedback on this, it may be the germ of something of broader scope.
> 
> ------------------------------------------------------------------------
> 
> Posted recently to a mailing list:
> 
> > My company is considering making the source code of a relatively minor
> > software tool we developed available to the public.  Any thoughts
> > about pros and cons of going through one of the existing open source
> > licenses (and, if so, which one?) or do something else?
> 
> You're providing very little specific information on what the software
> is or why you want to take it open source.

Without knowing more, I'd say GPL, unless:

 1) The software is inextricably linked to other software that you are not
    willing or able to release (which could include dependencies on software
    that is not yours and is incompatibly licensed).
 2) You have a special business model requirement.

You could also use a simple permissive license, but you would be less likely
to be able to benefit from other people's changes to your code. That may or
may not bother you, but one common reason for releasing source code is to
encourage more people to work with and contribute to it.

<...>

> 1. Understand the standard licensing models
> -------------------------------------------

<...>

> The Artistic License is notable for its use with the Perl programming
> language, however, it's a somewhat eclectic and ambiguous document.

My take is that the Artistic License is mostly an argument with GPL over
what constitutes a derived work: in particular, it disclaims embedding
(like the Guile license) and command extensions (regardless of how they
are implemented), and it does so in ways that are very specific to Perl.
(That is, one has to rewrite the license to apply it to anything else.)

> 2. Fit the license to your needs
> --------------------------------
> 
> Licenses tend to have two functional components:  goals they wish to
> forward, and threats they attempt to protect against.  Goals, in free
> software tend to include many non-pecuniary objectives, including
> adoption of an ideology, technology, or business model.  Threats usually
> include the relatively standard risks of liability and implied
> warrantee, as well as a number of risks which vary by specific license
> and organizational objective.
> 
> I categorize most licenses as follows:
> 
>   - Ideological:  The GPL and LGPL are specifically ideological tools.
>     Their intent is to further the adoption of free software.   They
>     have other effects, many of which are beneficial, and do expressly
>     provide for several business models, including sale of software and
>     warrantee services.

Sure, Stallman is ideological, but there are many counterexamples who use
the same license -- Linus Torvalds, most notably. Moreover, there are people
who advocate BSD-style licenses on purely ideological grounds. So to classify
GPL as an Ideological license is erroneous, uninformative, and more than a
little pejorative.

Something like "Community" (or more explicitly "Community Building") comes
closer to the truth. The key aspect of GPL and its variants is that they
erect a fence around their works, and force you to decide whether you want
to work inside the fence -- where everything is shared/free -- or outside
the fence. The result is that the insiders form a community.

Sun has muddied the waters a bit here with their SCSL -- a community in
the same sense as a fan club: in thrall to the founder's business goals.

>   - Technological:  the BSD and MIT licenses (and derivatives) are
>     largely aimed at propagating technologies.  Their greatest success
>     has been in furthering standards.  Several which have become widely
>     used are:  BIND, Apache, Sendmail, the X Window System, and the *BSD
>     Unix distributions.

Lots of other licenses are aimed at propagating technologies, and these
examples (more commonly referred to as "simple permissive licenses") are
very weak at maintaining standards conformance. What is distinctive about
BSD/MIT is that these licenses were applied to projects that were
subsidized by government and/or business. The salient feature here is
that they permit businesses to fork proprietary derivatives. For this
reason we might call them "Business/Free" licenses.

There are, of course, people who prefer these licenses for ideological
reasons. Although in my experience, most of those people work for
commercial software companies, and their work is not so generously
licensed.

>   - Business/Pragmatic:  The Mozilla Public License (MozPL) adapts
>     concepts from the LGPL and makes them a bit more business friendly.
>     An emerging trend is to dual-license code under the MozPL (or
>     similar license) and some combination of GPL and/or LGPL.  Both
>     Mozilla and Sun are trending in this direction.

MozPL is a generalization of NPL (Netscape Public License), which falls
into the more general category of "Special Interest" licenses. MozPL
itself has some characteristics of each of these categories: like GPL,
it draws a fence around a work (but that fence is outside of the GPL
fence, and exclusive of the GPL community); like the Business/Free
licenses, it supports private, binary-only derivatives. Sort of a non-
simple, non-permissive, incompatibly copylefted, localized, worst of
all worlds license. What's so pragmatic about that?

>   - Corporate Licenses:  Generally focused to the specific needs of a
>     company, and often reflecting its inner fears.

An early trend here seems to have been branding. I wish we could say
that everyone who was swept up in that trend has by now been thoroughly
humiliated.

> You should identify the goals, concerns, and risks associated with
> opening source, and apply an appropriate license.  Recognize that the
> typical "roll-your-own" novel license effort I've seen involves:

<...>

> One emerging trend is the use of dual or multiple licensing.  This has
> been used by Perl for quite some time (Artistic + GPL).  More recently,
> Sun has released OpenOffice (formerly StarOffice) under a combination of
> Sun's own SISSL, the GNU GPL, and the GNU LGPL.  Mozilla is also looking
> at a combination of the MozPL, GPL, and LGPL.
> 
> My understanding of multiple licensing is that the licensee gets terms
> of both incorporation and transmission.  I claim right to incorporate
> library libqtfoo under the terms of any one of: (Qt|QPL|GPL), but I
> _transmit_ rights of third-party use under _all_ of (Qt QPL GPL).  It
> becomes somewhat like file permission security under GNU/Linux, though
> you allow _both_ files and users to have multiple group associations.
> Essentially, file belongs to groups Qt, GQL, and GPL.  If user belongs
> to any one group, user has access to file.  User transmits file with all
> three group flags, by default.
> 
> Multiple licensing seems to be gaining acceptance within the free
> software community, including favorable nods from several projects and
> Richard Stallman.  There may be some as yet unforeseen issues, but it
> looks generally useful and practical.

Dual licensing provides a way for software that was originally licensed
incompatible with GPL to gain access to the GPL community (and vice versa).
The risk is that the GPL community may fork the code and not dual-license
the derived work.

Note that the same risk is already present in simple permissive license
(BSD, et al.) code. In practice, I haven't noticed this to be a problem,
but it is an argument for releasing code under GPL rather than an BSD-
like license, since the former promises to return the derived changes to
you, while the latter allows them to be kept private.

The other thing is that dual licensing is probably harder to enforce.
I doubt that this is much of an issue, given how little money tends to
be at stake in open source software.

> 3. Understand and appreciate the licensing landscape
> ----------------------------------------------------

<... much more good stuff...>

-- 
/*
 *  Tom Hull * thull at kscable.com * http://www.ocston.org/~thull/
 */