Free Software Licensing Strategy -- Some guidelines

kmself at kmself at
Tue Jan 16 10:11:24 UTC 2001

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.

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.  

You may want to look at the mailing lists FSB (Free Software Business: or License-Discuss
(, where business and legal matters
concerning free software are discussed.

I tend to focus on the strategic, rather than the strictly legal, issues
of a free software initiative.  In general, my own _recommendations_

0. Use an existing license

The costs and penalties involved in authoring your own license are
tremendous.  Very few firms outside the Fortune 10 should even consider
creating one.

This is contentious suggestion, particularly among new (or hopeful)
entrants to the free software world; it also has its critics within the
free software community who contend that there is a need for new
licensing models to better support the slightly conflicting aims of
producing free software and generating revenues at the same time.  

I'm personally less convinced that any major themes within this space
are yet uncovered:  the L/GPL, BSD/MID, and MozPL offer a fairly broad
range of possible business models.  My own feeling is that there is more
a lack of creativity on the business side of the house, with a fixation
on the traditional "software as a money mint" model of selling bits at a
huge premium over marginal cost.  I feel rather strongly that this is a
business model tied strongly to a period of time which is now passing,
and only worked truly effectively for a handful of companies at best.

Presenting a license which _doesn't_ meet the existing definitions of
"free software" (from the FSF) or "open source" (from the OSI), but
presenting it as if it does, is likely to draw much negative attention
to your efforts.  If your license is criticized, particularly in forums
such as FSB, license-discuss, or news:gnu.misc.discuss, as not meeting
definitions of free or open source software, listen to your critics.
They very likely know what they are talking about.  Some of them may be
the same people as will decide (or advise those who do) on your license's
qualifications under these definitions.

I do feel that there should be better mechanisms for introducing
potential changes and modifications into the licensing mix, and have
suggested several possible options of doing so in the past.

While I won't _insist_ that a project or organization use an existing
license, I will *VERY STRONGLY ENCOURAGE* this tack.  If a novel license
is proposed, it should be accompanied by an _exhaustive_ analysis of
major existing licenses (GPL, LGPL, BSD, MIT, MozPL) and the reasons for
which the existing licenses were deemed inadequate.

1. Understand the standard licensing models

In general, these include the GNU GPL and LGPL, the BSD and MIT
licenses, and the Mozilla Public License (MozPL).  Other licenses are
largely variants of these (in particular, there are many versions of the
BSD/MIT license, most of which are compatible), and a collection of odd
or eclectic licenses more-or-less divided into a handful of business
licenses, a bunch of odds'n'ends, and the Artistic License.  

IBM, Sun, and Apple have each authored their own licenses.  Sun and
Apple have been evolving toward more traditional free software terms
(Apple's most recent changes being on January 4, 2001).  The
"odds'n'ends" range from smaller organizations to small projects and
independent developers who've tried to restrict specific actions or uses
of software.  I tend to consider many of these attempts misguided.  

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

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.

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

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

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

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:

  - A year or more of authoring and revision time.  While an initial
    draft may be published and a "first viable license" produced in far
    less time, working out the kinks to the point of producing a
    generally acceptable license generally takes longer.

  - Many meetings of internal, legal, and external advisors.  Expensive
    both in terms of time and money.

  - If OSI approval is sought, yet another considerable delay, and
    probable round of revisions, each to be subject to the same
    consideration and approval delay.  While OSI approval is seen as a
    requirement for many licensing efforts, the process of securing same
    is slow, the current backlog large, and available staff very limited
    (this from recent personal communication with the OSI's executive).

  - A significant marketing effort of the license itself to the
    developer community.  Again, producing real and internal costs.

  - Often subsequent evolution toward, or wholesale adoption of, an
    existing free software license.  Cf:  Zelerate (formerly OpenSales),
    Sun, Apple, and Mozilla.

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.

3. Understand and appreciate the licensing landscape

If you're interested in a profile of use of licenses, you might take a
look at the SourceForge software index, which includes a categorization
by license.  Of the roughly 8,800 listed projects with a license in
early January, 2001: 

    8,384 are based on an OSI approved license.
      208 are based on an other or proprietary license.
      235 are public domain.

Of the OSI licenses, the breakdown is as follows:

    GNU GPL:	6,178
    GNP LGPL:	  844
    BSD:	  480
    Artistic:	  302
    MozPL:	  114
    MIT:	  110
    Python:	   78
    QPL:	   60
    zlib/libpng:   46
    IBM-PL:	   10
    MITRE (CVW):    4

So, the GNU GPL/LGPL combination accounts for 83% of the OSI-approved
license projects.  Translating this into effective importance is more
complicated, but a very large portion of the underpinnings of the free
software platform are based on GPL/LGPL work, with most of the
significant others being BSD/MIT, and in the case of Perl, Artistic/GPL.   

Note that there is, generally, a licensing transitivity -- code written
under the GPL, LGPL, MIT, Artistic, Python (and other -- zlib, some BSD
???) licenses can be incorporated into projects using the GPL.  This
transitivity is largely one-way, however.  Barring other arrangements,
it is _not_ possible to take GPLd software and use it under non-GPL
terms.  Transitivity extends the scope of GPLd software to include 7,434
projects, or 90% of all projects.

I've been playing recently with some ideas based on Metcalfe's Law
("the value of a network increases with the square of its nodes") and
its impact on network valuation.  While hard quantitative results are
probably not fully appropriate, it's helpful to keep in mind that
strategies which maximize your user, developer, and sharable code pools
tend to maximize value of the free software development model when
considering licenses and business models.  In general, restrictive and
incompatible licenses, on the one hand, and limited-scope community
models on the other, are probably both non-optimal long-term choices for
free software development.

Doing the math on two examples, each involving three projects with 20%
marketshare each, the "Metcalfe metric" for inclusive licensing terms
(logical ANDing of user/code/developer bases) vs. exclusive (logical OR)
terms, is on the order of several thousand fold:

    (1 -( 1 - 0.2 )^3)^2 / (( 0.2 )^3)^2

While there are strong theoretical and practical reasons to question the
accuracy of such a calculation, the negative costs of restricting a base
of developers, users, and/or code to 0.8% rather than 49% of the
available universe should be readily apparent.  Incompatible licensing,
restrictive distribution terms, and "gated development communities" all
serve to restrict adoption of a project.  Gated development may be
appropriate for _incubating_ development, but beyond this stage, the
relative advantage of a more open alternative is likely to be large.
You are advised.

The other problem with license proliferation is that it vastly
complicates the task of identifying what licenses are compatible with
what other license.  This becomes more complicated in code which is
derived from multiple sources, themselves variously licensed.  One group
I've sat with seriously discussed creating an application for the
purpose of determining software licensing terms from within a source
tree and performing compatibility tests to see whether or not a
particular application was internally consistent -- from a licensing
standpoint.  My own sense is that in this direction lies madness.

To quote John Gillmore:

   Free software is about reducing the transaction cost of coöperation.

Raising these costs, through added complexity, is antithetical to the
objectives of free software licensing.

4. Understand the limitations of free software

Realize also that opening your source is no guarantee of success of your
project, and that _how_ you run your project is critical to its
potential for success.  There are some good guidelines on running a free
software product from Brian Behlendorf ( and IBM.  In
particular, a free software development effort which is other than
nominal requires a strong commitment and very open communications lines
to the external development community.  

My own direct experience with software development is that there are two
communications models, each of which can work very effectively by

  - Stick a bunch of coders in a room, lock the door, and have them
    kibitz code over their shoulders.

  - Scatter a bunch of coders to the winds, and have them kibitz code
    over email.

The mixed model tends to fail badly.  Software development is a very
social activity, and people will use the most convenient communications
channel available.  Where this is the "cube-wall conference", anyone
outside of earshot is by necessity excluded.  While the mixed model can
work, it takes a conscious and constant effort.

Among the things free software *isn't* a guarantee of:

  - Business success.
  - Software quality.
  - System security.
  - Product adoption.
  - Intelligent management.
  - Competition elimination.

In a market in which free and non-free products compete, there's
_likely_ to be an advantage on the free software products, and an
emergence of a successful (or possibly several, in a sufficiently rich
space) projects based on a free software market. If anything,
competition in the free software space is going to be as critical if not
more so than in the so-called commercial marketspace. 

Any given free software project has a likelihood of failure. However,
within a problem space, there's a likelihood of one or more free
software successes, competitive with, and possibly superior to,
proprietary alternatives. 

5. Understand the motivators of free software 

I've noticed a number of convergent trends in free software, Metcalfe
effects, among them.  
I've created my own typography of what I think leads to the
success of free software, and I think if you reflect on the points,
you'll understand why I don't think any sort of "half-open" model will
be truly successful in the long term.

The factors:

  - Development methodology:  Cathedral & the Bazaar.  Many eyes,
    comprehensive code review, massively parallel debugging.  Predicated
    on open sources, and rights to copy, modify, and distribute same.

  - A software architecture:  Modular code.  This both reduces
    complexity, and increases access to code by allowing single
    developers to "wrap their head" around a specific component
    without getting bogged down in interactions effects with other
    portions of the system.  Many proprietary projects lacking
    sufficient modularity of code founder on initial release as free
    software due to their internal complexity.

  - A legal framework:  free software licensing.  You can ensure code
    will be available for use, modification, and distribution.

  - An economic model:  There is a rational economic justification for
    engaging in free software.  I'm inclined to believe it's a
    functionality enablement / cost-avoidance model rather than a 
    profit-seeking model, but there's work to be done here.  That is,
    the value of free software is the functionality it enables (and
    presumably a related economic activity), and the avoided costs of
    downtime, unavailable functionality (e.g.:  new feature request),
    security threats, etc.

  - Cheap or free transmission and distribution:  The Internet.  Note
    that several proposals exist which could greatly impact this
    component, including various initiatives to proprietize
    communications, restrict ability to self-provide services (e.g.:
    mail, web), restrict availability of discretionary encryption and
    privacy tools, enforce use of imposed encryption and "copy
    protection" mechanisms.

  - Open standards:  GNU/Linux emerged on the dual foundations of the
    Unix/POSIX standard and the GNU Project's utilities and development
    environment.  While free software _can_ be used to promote
    standards, it also to a large extent relies on them.

Licenses or business models which impede or reject any of these
principles will correspondingly weaken the dynamic for the corresponding
software project.

Oblig:  IANAL, this is not legal advice.

Karsten M. Self <kmself at>
 What part of "Gestalt" don't you understand?       There is no K5 cabal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <>

More information about the License-discuss mailing list