For Approval: Simple Public License (SimPL)

Sat Mar 31 18:09:50 UTC 2007

Thanks very much to everybody who commented; we found the feedback to be
very useful.  We'll try to respond to all of the comments, but questions
about the unique purpose of the SimPL seemed most prominent so we'll talk
about that first. 

1.  What is the unique purpose of the SimPL?.  

As Matthew Flaschen puts it:  "In general, you should only create a license
if you want to achieve a distinct purpose from the existing licenses."  We
agree.  The SimPL was drafted to achieve a very important and unique goal:
creating a simple, easy to read copyleft license that can be read and
understood by programmers.  Many people consider this to be one of the most
important goals for a license.  No other copyleft license that we know of
was written with this at the forefront or achieves this goal.

Many programmers have complained that they cannot parse the GPL (even with
its extensive FAQ).  FSF acknowledged in its Rationale document for GPL 3.0
that it values simplicity in licenses and mentions that people "have asked
us for a simpler and shorter GPL."  As Linus Torvalds has been quoted as
saying:  "In many ways, my only gripe with the GPL has been how many words
it seems to need to say something very simple."  FSF declined to write a
simpler GPL (and said GPL 3.0 would be even more complex), believing it
could not write a simple license that protects user freedom.  However, it
did throw out this challenge:  "We enthusiastically invite those who believe
that the GPL can protect freedom just as well in fewer words to join our
comment process and show us how it can be done."  We believe that that SimPL
is an easy-to-read license that can protect freedom as well or better than
other copyleft licenses that are hard to read.

2.  Why not just use the GPL?  

It will not surprise us if most programmers do in fact continue to use the
GPL because it is well established and it has the imprimatur of the Free
Software Foundation.  In this sense we don't disagree with Chris DiBona's
prediction that: " . . . your desire to make a simpler gpl will just mean
another minority license. . ."  

However, we have encountered a significant number of programmers who do not
care to pick a license primarily because of its legacy or its endorser.
They simply want the best license for the job, regardless of its origins,
and many of them do not think the GPL is a particularly elegant piece of
legal code.  This may be a minority of programmers but it's a large enough
group that it makes sense to provide them a better tool for making a
copyleft.  In fact, we think the SimPL potentially will encourage more
software to be licensed copyleft because programmers will have a clearer
idea of the license terms-many people do not use the GPL simply because they
do not clearly understand its scope of license.  

By the way, when GPL 3.0 has been finalized, we hope to create a "SimPL 3.0"
that would provide a simple copyleft license based on GPL 3.0 terms.  We
have no intention of weighing in on the GPL 2.0 versus 3.0 debate (the SimPL
was publicly released back in 2005 and was submitted to FSF as part of the
GPL 3.0 comment process at that time).  Our goal is to provide good legal
tools; we're agnostic about whether a programmer should use SimPL 2.0 (as
we'll call the updated version of this license) to make a copyleft under
terms like GPL 2.0 or SimPL 3.0 which will be a re-implementation of GPL 3.0
terms (whatever they ultimately might be).

3.  "Most of the GPL. . . exists for an important legal purpose."
Shortening the license will create ambiguity, not resolve it."

A license does not have to read like legalese to be enforceable; in fact,
legalese can actually degrade enforceability in some cases.  More words do
not necessarily create a clearer or more legally enforceable license; in
fact, the opposite is often the case.  For example, the license grant in the
SimPL is both shorter and less ambiguous than the longer and famously
ambiguous license grant in GPL 2.0.  While it is true that the most of the
words in the GPL are there for a purpose, that purpose can often be
expressed better in fewer words.

By the way, the SimPL is not merely a "partial summary" of the GPL.  The
SimPL was professionally crafted with considerable thought given and care
taken to make sure it was both faithful to the core terms of GPL 2.0 and an
enforceable legal document.  We are confident that the SimPL is at least as
enforceable as GPL 2.0 (so far, courts have said the GPL is likely
enforceable just like any other mass market license-the SimPL would be as
well) and, indeed, we have done some things (such as moving the instructions
for manifesting assent to the top of the document and updating disclaimer
language) to potentially make it more enforceable.  

4.  Use of the term "derivative works."

We acknowledge that there are pros and cons to using the "derivative works"
nomenclature.  On balance we think it is better because it can be
interpreted in light of existing case law, legal scholarship, and software
industry practice.  In addition, many (if not most) licenses use this
terminology, including GPL 2.0, so in this sense the SimPL is merely
following standard industry practice for software licenses.  If GPL 3.0
takes a different approach, SimPL 3.0 would follow suit.

5.  Why state that the licensee should "Follow all export control laws?"

This is simply a matter of good license drafting practice-the export control
laws as best followed by giving notice to potential licensees who may be
subject to these laws.  A software license is a good place to place such a
notice.  It is also explicitly allowed by the Open Source Definition.

6.  Release of source code

We actually believe that by requiring that the source code be easy to get
and use, we're making the right broader.  "Easy" would prohibit code
obfuscation, for example, as well as requiring the distributor to avoid
particularly onerous requirements.  By going broad like this, the license
allows for more flexibility, so that distributors could choose the mechanism
that is most appropriate for the type of program.

We do, however, agree with your point about build scripts so would amend the
license as follows in the fourth bullet:  

"Providing the source code (including build scripts and interface
definitions) of any Derived Work in a form that is easy to get and use."

6.  Limit of liability clause.

Our disclaimer of damages clause is drafted to avoid the possibility that
the license could fail of its essential purpose which could, in the mind of
some courts, allow the possibility that the licensee (despite disclaimers)
could recover consequential damages.

7.  Tweaks to the SimPL based on your feedback.

Here are some changes that we think might make the SimPL better based on
your feedback:

A.  The license grant could be amended to read:  "The SimPL applies to the
software's source and object code and comes with any rights that I have it
(other than rights under trademarks)."  

B.  The license conditions could be amended to read in the first bullet:
"Prominently noting when you change the software."  This removes the concern
that the programmer will have to re-write documentation (which was not our
intent).

C.  The license conditions could be amended to read in the fifth bullet:
"Licensing any Derived Work under a license with terms substantially similar
to the SimPL."

D.  The term section could be amended in two ways:  The intro could be
amended to say:

"The SimPL continues perpetually, except that your license rights end
automatically if"  This makes it clear the termination applies to a
particular licensee.  

Then, keep the first bullet and revise the second bullet to say: "Anyone
prevents you from distributing the software under the terms of the SimPL."
This broadens the clause to cover more than just patent rights, as it
should.

To help the discussion, we've attached a revised version of the license that
is marked up with the changes discussed above.  

Thanks again for the comments.

Jim Sfekas

Bob Gomulkiewicz

From: Chris DiBona [mailto:cdibona at gmail.com] 
Sent: Thursday, March 15, 2007 10:22 PM
To: Richard Fontana
Cc: sfekas at u.washington.edu; license-discuss at opensource.org
Subject: Re: For Approval: Simple Public License (SimPL)

Also, your desire to make a simpler gpl will just mean another minority
license that no one will adopt. If it is just a simpler gpl, why not use the
gpl and get access to billions of lines of code already under that license,
after all. 

By proposing new licenses, you muddy the waters and slow the adoption and
creation of free software and open source software. the world doesn't need
more licenses, it needs way less.

Chirs

On 3/16/07, Richard Fontana <fontana at softwarefreedom.org> wrote:

Jim Sfekas wrote:
> The SimPL has the same compatibility with other licenses as GPL, with all
> the good and bad that that entails.  It should, therefore, be compatible
> with GPL, LGPL, X11 License, etc. 

It can't be compatible with the GPL, because it has its own copyleft
provision:

> If you distribute a Derived Work, you must give back to the community by:
[...]
> - Licensing any Derived Work under the SimPL. 

Also,
> The SimPL continues perpetually, except it ends automatically if:
[...]
> - A patent holder prevents you from distributing the software under the
> terms of the SimPL.

This is more restrictive than GPLv2 section 7 (on which it is presumably 
modeled).

(Unless you mean something nonstandard when you speak of "compatibility".)

-- 
Open Source Programs Manager, Google Inc.
Google's Open Source program can be found at http://code.google.com
Personal Weblog: http://dibona.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070331/5a2c6bdd/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070331/5a2c6bdd/attachment-0001.html>