Re: Free Software Licensing Strategy -- Some guidelines

2001-01-17 Thread Andrew J Bromage

G'day all.

Karsten, you've done an excellent job with this.  There is one point
that I'd like to make which might be worth adding, as it's a common
misconception.

On Tue, Jan 16, 2001 at 02:11:24AM -0800, [EMAIL PROTECTED] wrote:

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

The author of Perl and the Artistic License, Larry Wall, has publically
stated several times that it was specifically designed to be used as
part of a dual licensing scheme only.  For example:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-08/msg01317.html

When choosing the Artistic License, if you ignore Larry's advice and
do not dual license with some other open source licence, you do so at
your own legal risk.

Cheers,
Andrew Bromage



Re: Free Software Licensing Strategy -- Some guidelines

2001-01-17 Thread Ben Tilly

Tom Hull [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
 
[...]
  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.)
[...]

My understanding is that the Artistic License is a feel-good
document which is legal Swiss cheese.  It certainly does not
achieve its stated aim, is probably not legally enforcable,
if it were it would be trivial to subvert, and there are
multiple versions out there.  (Having had the wording of the
version in Perl modified several times without getting the
explicit permission of all copyright holders makes its status
somewhat...nebulous.)

I don't think that it should be generally used.

IANAL and this is not legal advice.

Cheers,
Ben
_
Get your FREE download of MSN Explorer at http://explorer.msn.com




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,