Free Software Licensing Strategy -- Some guidelines

[kmself at ix.netcom.com]

on Tue, Jan 16, 2001 at 04:45:32PM -0600, Tom Hull (thull at kscable.com) wrote:
> 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.

I only ask that the visible carnage be cleaned before you leave....

<...>

> > > 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:

Without knowing more, in general, I'd refrain from making specific
advice.  Which is more or less the point of this document -- it frames
the process of deciding on a free software licensing strategy, but
doesn't impose an answer of itself.  Though I believe it hints broadly
in making a strong case for the GPL, or something compatible with it,
later on.

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

See Andrew Bromag's and Ben Tilly's responses.

Artistic has been described as preserving artistic integrity.  It really
largely disclaims virtually everything (including, as I read it,
artistic integrity) through overly liberal relicensing language.  Given
one or two generations of removal from the original material, virtually
any licensing terms, including proprietary, may be applied.

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

I'm speaking of the license's original intent and practical effects.
Not diverse justifications for adoption.  I myself find the L/GPL useful
for its pragmatic effects, and place these at a higher value.  RMS has
emphatically stated (in his writings, and in direct personal
conversation) that his primary interest is in freedom, not pragmatic
aspects.  I'm told the Gilmore quote about transaction costs isn't
accepted by Stallman.  This doesn't diminish its truth.  It does
emphasize Stallman's focus on ideology.

And the effect of the license itself is to further spread the meme of
free software, because its own immutable terms[1] are always preserved.
Regardless of why individuals adopt it.  Your statement regarding the
BSD/MIT licenses falls into the same category of error: you're
describing stated reasons for adoption.  I'm describing effects _of_
adoption.

BSD/MIT encourages adoption of a technology by providing a reference
implementation which can be utilized by others in either free or
proprietary applications.  The ramp for adoption is lowered.  With
sufficient utility, marketing, moxie, or combination, we may find a
world in which SMTP, BIND, HTTP, etc., are widely adopted.

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

Still?

<...>

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

No.  They're utterly ineffectual at it.  My standard lecture on
standards conformance is to use a branding or certification program for
same, backed by a trademark or certification mark.  What the BSD/MIT
license provide are the copyright mechanisms for effecting the adoption
of technology, not the certification/compliance mechanisms for ensuring
conformance.  

See last year's Kerberos debacle, as an example.  Evan Liebovich and I
went a few rounds at ZDNet on this -- Evan was flogging the GPL to solve
problems he ascribed to the BSD license.  Fan as I am of the GPL, he had
picked the wrong tool for the job.  Others, and I, pointed out that
trademark was the appropriate means to secure conformance.

OT:  I'm largely convinced that Sun's attempts to enforce Java
compliance through copyright licensing terms are sadly misguided.  It's
not that compliance and standards are bad, it's that they've chosen the
wrong mechanism.  I've heard general agreement from multiple quarters on
this.

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

It does not.  It allows binary-only additions (on a file-by-file basis)
to the original covered work.  All portions of the original work (on a
file-by-file basis) must remain covered and distributed under the terms
of the MozPL, which itself meets the definitions of the OSD, the FSF
Free Software definition, and, I believe, of Copyleft.  Though its scope
is slightly narrower than the GNU GPL (see following).

> Sort of a non- simple, non-permissive, incompatibly Copyleft ed,
> localized, worst of all worlds license. What's so pragmatic about
> that?

I believe your interpretation of the MozPL is somewhat clouded.  I see
the MozPL as, in large part, an update, with greater corporate focus, of
the LGPL.  It contains language specific to branding and trademarks, a
more comprehensive treatment of patents, and some quite
developer-friendly language.  The license also preserves (through the
allowing of files under non-MozPL terms) a business model for
proprietary extension of a project.  Though this might lead to warped
code in the long run.

In sum:  MozPL preserves a business model, addresses some business-
related concerns (trademarks, patents), has tighter language, but
generally achieves a similar aim to the LGPL.  It's a business-pragmatic
free software license.

<...>

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

General agreement here.

Though I'll note, again, that it's otherwise difficult to bring new
ideas into the licensing arena.  Not that we see good ones often, but
they do crop up from time to time.

<...>

> > One emerging trend is the use of dual or multiple licensing.  

<...>

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

Yes, this is a possibility.  But, again, to what strategic end?

If you'll recall from excised portions of my original post, free software
builds on open standards.  As I've said (though you challenge), BSD/MIT
licenses are useful for promoting a standard across both free and
proprietary software domains.  The GPL, while it preserves licensing
terms associated with a particular code development branch, has
historically tended toward slower adoption rates (a situation somewhat
changed in the past few years), in part because the code couldn't be
incorporated into proprietary software.

In the same way that the Linux kernel benefitted from the existence of a
POSIX standard, compilers, and shell tools, BSD/MIT licensed projects
have benefitted from the existence of a thriving free software
development community -- based in large part on GPLd software -- to
point to the viability of the free software development model.

I see BSD/MIT and GPL as complementary licensing models.  By providing
broad licensing terms under BSD/MIT, a standard can propagate through a
range of technologies.  By securing the same code under GPL at the same
time, the knowledge that an attempt to accelerate a proprietized fork of
the technology will likely be met by a countervailing GPLd fork may be
sufficient to prevent the first.  Sure, minor proprietary development
can happen (and may even be encouraged), but the primary development
track will be along the free branch, and paths will tend to either be
convergent, or consisting of small departures from the main branch.
Ultimately, those who keep branching off the main tree and backtracing
either learn that this is too expensive a habit and start chipping back
to the free software version, or start securing richer, dumber, clients.
For the various network and community effects I detailed earlier, the
broader-based development effort is likely to have a significant
advantage over all but the most well-backed proprietary efforts.  

In fact, the threat of a GPLd fork may not even be necessary.  Roy
Fielding, writing on the Apache project, notes that various proprietary
forks of Apache have all (to date) failed, despite the fact that they
are allowed under Apache's license, and that the GPL is incompatible
with the Apache licensing terms.

Which addresses the reasons why a proprietary fork of the BSD/MIT code
is unlikely.  As to why some GPL faction doesn't create a GPL-only fork
of the project -- this is likely to, again, lose a significant part of
the development effort, and, absent the looming threat of a proprietary
fork in process, for little or no apparent ends.  Forking is expensive
and difficult.  Most GPLd efforts *don't* operate under strong and
well-funded central control, making these efforts difficult to sustain.
I suspect the project will tend toward a steady-state of existence under
a dual license.  Yes, with some flux, but stable within a range of
variance.

I'll toss this one out to the crowd:  are there any significant
instances in which dual-licensed code has forked under a single license,
or in which non-advertising clause BSD, MIT-licensed code, or similar,
have been forked to GPL?

<...>

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

Why should dual licensing be harder to enforce?  Terms are now more
permissive, but ultimately failure to comply with one set or the other
results in fallback (at least for BSD/MIT and GPL) to copyright law.
Statutory penalties are sufficiently strong, and, as you observed,
direct gains sufficiently small, that incentives to violate free
software licensing terms tend to be small.

--------------------
Notes:

[1] Well, immutable, bar version changes.

-- 
Karsten M. Self <kmself at ix.netcom.com>    http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?       There is no K5 cabal
  http://gestalt-system.sourceforge.net/         http://www.kuro5hin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20010118/9e5a1a47/attachment.sig>