Free Software Licensing Strategy -- Some guidelines

2001-01-16 Thread kmself

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:
http://www.crynwr.com/fsb/) or License-Discuss
(http://www.opensource.org/), 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_
are:



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, 

Re: IPL as a burden

2001-01-16 Thread Ralf Schwoebel

Dave J Woolley wrote:

 I have some concerns that companies like RH will become more and
 more like Microsoft - you can already see it in the marketing
 language on their web sites.

Hi Dave,

but this is a normal development for a company that has
to report back to shareholders and this development will
continue if society does not change (what I do not expect :)

After the discussion yesterday, and we might work a bit on our
license and resubmit it. But the basic idea will stay:

License fees for "Open Source" software and a license that
is covering that widely and explicitly mentions that with the
approval of the community. We think it is time for such
a license and we do believe that the IPL is close enough,
even if some paragraphs caused such a discussion yesterday.

Profit is necessary and licenses like MozPL, etc. are the
first step to such a point of view. Even the GPL notes that
and leaves the door open.
--
best regards,
Ralf "puzzler" Schwoebel
CEO, intraDAT international inc.
11250 Roger Bacon Drive (#3)
Reston, VA 20190
Tel.: 703 796