For Approval: Simple Public License (SimPL)

[Jim Sfekas]

This e-mail is to begin discussion of our proposed Simple Public License
(SimPL).  This license was written by Professor Bob Gomulkiewicz of the
University of Washington School of Law.  The text of the license is appended
at the end of this e-mail.  It can also be found at
http://www.law.washington.edu/CASRIP/License/SimplePublicLicense.html.  I am
a student of Professor Gomulkiewicz’s and am working with him on shepherding
the SimPL through the OSI process. 
 
The SimPL is intended to achieve the same coverage as GPL 2.0, while
addressing an oft-repeated complaint that it is too wordy and unwieldy. 
Therefore, the SimPL most resembles GPL 2.0, but is (not surprisingly)
simpler and easier to understand.  It is intended to cover the same terms,
but avoid some of the ambiguities in the GPL and be significantly easier for
the average person to understand.  It is not a modification of the GPL –
it’s more of a reimplementation. 
 
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 does not, for example, have patent
license or termination requirements of the type that render the Apache
Software License 2.0 and the IBM Public License 1.0 incompatible with the
GPL.  Of course, the SimPL is not compatible with non-free licenses. 
 
For those who might be interested, the license was introduced in an article
by Professor Gomulkiewicz that can be found at
http://www.law.washington.edu/Directory/docs/Gomulkiewicz/GenPubLic.pdf. 
There is an annotated version of the SimPL in Appendix II that compares its
terms to those of GPL 2.0.  The annotated version is also available at
http://www.law.washington.edu/CASRIP/License/SimplePublicLicense_annotated.h
tml.  
 
Thank you.

Jim Sfekas

----------------------------------------------------------------------------
------------------

Simple Public License (SimPL)

The SimPL applies to the software's source and object code and comes with
any rights that I have in it. You agree to the SimPL by copying,
distributing, or making a derivative work of the software.
You get the right to:

- Use the software for any purpose;
- Make derivative works of it (this is called a "Derived Work");
- Copy and distribute it and any Derived Work.
 
If you distribute a Derived Work, you must give back to the community by:

- Prominently documenting any changes that you make to the software;
- Leaving other people's copyright notices in place;
- Providing the source code of any Derived Work in a form that is easy to
get and use;
- Letting anyone make, free of charge, derivative works of any Derived Work;
- Licensing any Derived Work under the SimPL.
 
There are some things that you must shoulder:
 
- The software comes with NO WARRANTIES of any kind. None;
- If the software damages you in any way, you may only recover direct
damages up to the amount you paid for it (that is zero if you did not pay
anything). You may not recover any other damages, including those called
"consequential damages." (The state or country where you live may not allow
you to limit your liability in this way, so this may not apply to you);
- Follow all export control laws.
 
The SimPL continues perpetually, except it ends automatically if:

- You do not abide by the "give back to the community" terms (your licensees
get to keep their rights if they abide);
- A patent holder prevents you from distributing the software under the
terms of the SimPL.

[Richard Fontana]

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

[Chris DiBona]

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

[Matthew Flaschen]

Jim Sfekas wrote:
> The SimPL is intended to achieve the same coverage as GPL 2.0, while
> addressing an oft-repeated complaint that it is too wordy and unwieldy.

Most of the GPL (with the exception of the preamble, which is there for
persuasion), exists for an important legal purpose.  Shortening the
license will create ambiguity, not resolve it.  The term changes (like
using "derivative works" instead of a "work based on the Program") hurt
internationalization (as the article notes), while GPLv3 is supposed to
help that.  On that note, releasing this around GPLv3 will inevitably
create confusion and make people think they can use GPLv2 or later
software under this license.

In general, you should only create a license if you want to achieve a
distinct purpose from the existing licenses.  This helps avoid license
proliferation, which is a serious concern for OSI.  Moreover, you should
have an actual program in mind.  You're actually creating more work for
users, since the GPL is an established license with abundant FAQ's and
explanations.  It has also been legally tested.

> The SimPL has the same compatibility with other licenses as GPL, with all
> the good and bad that that entails.

It seems like you've tried to make it GPL-compatible, but it could
easily be found not to be, because of the inherent ambiguity in such a
short license.  IANAL, but I already see several differences.

> The SimPL applies to the software's source and object code and comes with
> any rights that I have in it.

This may include trademark and other rights, which is highly undesirable.

> Prominently documenting any changes that you make to the software

This sounds like it requires changing user documentation, while the GPL
only requires changes to the source code be noted in the source files.

> Providing the source code of any Derived Work in a form that is easy to
> get and use;

This is weaker than the GPL's provision.  It doesn't require written
offers for binary-only distribution, but only that the source is somehow
provided (to who, how?); it also doesn't specify that source code
includes build scripts.  This means the copyleft is diluted, which is
highly undesirable if you really intend to reimplement the GPL.

> If the software damages you in any way, you may only recover direct
> damages up to the amount you paid for it

This explicitly allows cost recovery, which as far as I know is
unprecedented in a FOSS license.  The warranty seems generally weak
(doesn't spell out other types of damages, no caps, etc.), but I
couldn't really say.

> - Follow all export control laws.

People know they have to follow the law, and it's not the license's
place to enforce it.  The OSI and Intel have deprecated a license that
only differed from the new BSD by this idea.

Other provisions of the GPL are missing entirely, like 2.c. , which
requires copyright and warranty notices be maintained in interactive
programs.

Basically, this license is a decent partial summary, and I'm sure it was
undertaken in good faith.  However, in my opinion, the problems above
mean it should not actually be used as a legal document.  Clarity is
nice, but the legal effect is more important.

Matthew Flaschen

[Matthew Flaschen]

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

Not exactly.  It could explicitly allow relicensing (which makes sense
if it's supposed to be a reimplementation).

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

Yes.  It should say that it only ends for a particular distributor, and
only if the patent issue prevents compliance with the license.  However,
this clause is weaker than GPL 7 in some ways since it doesn't take into
account other reasons for non-compliance.

Matthew Flaschen

[Jim Sfekas]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...]
Sent: Thursday, March 15, 2007 10:22 PM
To: Richard Fontana
Cc: sfekas@...; license-discuss@...
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@...> 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

Simple Public License (SimPL)

Edited based on initial comments from the license-discuss list.  New text is underlined.

The SimPL applies to the software's source and object code and comes with any rights that I have in it (other than rights under trademarks). You agree to the SimPL by copying, distributing, or making a derivative work of the software.
You get the right to:

• Use the software for any purpose;
• Make derivative works of it (this is called a "Derived Work");
• Copy and distribute it and any Derived Work.

 
If you distribute a Derived Work, you must give back to the community by:

• Prominently documenting any changes that you make to noting when you change the software;
• Leaving other people's copyright notices in place;
• Providing the source code (including build scripts and interface definitions) of any Derived Work in a form that is easy to get and use;
• Letting anyone make, free of charge, derivative works of any Derived Work;
• Licensing any Derived Work under the SimPL terms substantially similar to the SimPL.

 There are some things that you must shoulder:

• The software comes with NO WARRANTIES of any kind. None;
• If the software damages you in any way, you may only recover direct damages up to the amount you paid for it (that is zero if you did not pay anything). You may not recover any other damages, including those called "consequential damages." (The state or country where you live may not allow you to limit your liability in this way, so this may not apply to you);
• Follow all export control laws.

 The SimPL continues perpetually, except it that your license rights end automatically if:

• You do not abide by the "give back to the community" terms (your licensees get to keep their rights if they abide);
• A patent holderAnyone prevents you from distributing the software under the terms of the SimPL.

[Matthew Flaschen]

Jim Sfekas wrote:
> 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."

I meant a distinct legal purpose, but I understand (though don't
necessarily agree with) your point.

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

I have actually been commenting (at
http://gplv3.fsf.org/comments/gplv3-draft-3.html).  This is more useful
than creating what you admit is likely to be a minority license.

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

Minority licenses are undesirable, if only because they clutter the
license list, create walls between code, and confuse developers.
However, your addition of "terms substantially similar to the SimPL"
should allow at least GPLv2 compatibility, which is good.  It would be
better if that clause was more precise.

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

But you haven't expressed the full purpose.  There are still many things
missing:

1. You don't have to preserve license or warranty notices, or provide a
copy of the license, even when redistributing derivative works (see #5).

2. It is unclear whether you can charge for a separate warranty.

3. It doesn't make it clear that derived works must be licensed to all
third parties.

4. As I said before, it doesn't have the GPL's 2.c (retaining copyright
and warranty options in interactive programs).

5. It doesn't explicitly say /verbatim/ copies of the object code must
include source (or a written offer).  In fact, it doesn't require
anything if you redistribute verbatim copies.  You could probably even
remove copyright notices and warranties, since that wouldn't really
count as a derivative work.  You could also restrict the recipients
rights, which is easy since you don't have to include SimPL.

6. Does noting when you change the software mean noting the date, or
just noting that you changed it ('when' is ambiguous).

7. You can charge royalties for licensing, since there is no requirement
to license at no charge.

8. You may not be allowed to pass along written offers when distributing
occasionally and non-commercially.

9. The geographic limitation provision is not included.

10. You don't provide for multiple versions (e.g. GPL #9).

> 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

I guess that depends what you see as a core term.

> 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

What country's case law?

> If GPL 3.0
> takes a different approach, SimPL 3.0 would follow suit.

It's kind of foolish to even make a GPL 2-style license now, for that
reason.

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

OSD says you can remind them that they are required to follow the law
(simply by virtue of the law's existence).  It also specifically adds,
"however, it may not incorporate such restrictions itself.", which you do.

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

Like GPLv2 does more clearly with "The source code for a work means the
preferred form of the work for making modifications to it."

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

It may in fact be less flexible, since it doesn't specifically allow
written offers (or passing them on).

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

Okay, what about installation scripts?  And does that include OS code?

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

I still think your warranty language is weaker, but IANAL.

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

So it is supposed to include patents?  Because it isn't clear that GPLv2
does.

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

Right.  That's a definite improvement.

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

As I said, I really appreciate this, but it could be more clear.

> Thanks again for the comments.

Thank you.

Matt Flaschen

[Jim Sfekas]

Thank you again for all of your comments on the license.  They've been very
helpful for us in refining and improving it.  Please see our response below.

> Minority licenses are undesirable, if only because they clutter the
> license list, create walls between code, and confuse developers.
> However, your addition of "terms substantially similar to the SimPL"
> should allow at least GPLv2 compatibility, which is good.  It would be
> better if that clause was more precise.

We chose this terminology because we didn't want to close off compatibility
with other copyleft licenses. We could specify "GPL v 2.0", but that would
leave out other options. We do believe that this gives enough guidance to
interpret, especially in light of our expressed intention that the license
parallel the terms of the GPL.

>  But you haven't expressed the full purpose.  There are still many
> things
>  missing:

Thank you for listing the GPL elements not found in the SimPL.  We've
thought carefully about the terms of the GPL and how they can be expressed
in the SimPL. That said, we there is some language in GPL which is nice but
not necessarily fundamental.   You've definitely given us good food for
thought to re-think this one more time and, as you can see below, we've made
some additional changes to the SimPL to cover additional points in the GPL
(fortunately, without adding additional heft).  We'll address those points
below.  

I've rearranged the items on the list to group related items.

>  2. It is unclear whether you can charge for a separate warranty.
>  
>  4. As I said before, it doesn't have the GPL's 2.c (retaining
> copyright  and warranty options in interactive programs).
>  
>  9. The geographic limitation provision is not included.
>  
>  10. You don't provide for multiple versions (e.g. GPL #9).

We have decided to leave out these elements because the extra complexity
that they add outweighs any additional benefit.  For example, the "charging
for a separate warranty" language in the GPL is superfluous; there is
nothing in the license or copyright law generally that would prohibit
charging for a warranty, so this language in the GPL is an FYI.  

>  1. You don't have to preserve license or warranty notices, or provide
> a  copy of the license, even when redistributing derivative works (see
#5).

>  
>  3. It doesn't make it clear that derived works must be licensed to
> all  third parties.
>  
>  5. It doesn't explicitly say /verbatim/ copies of the object code
> must  include source (or a written offer).  In fact, it doesn't
> require  anything if you redistribute verbatim copies.  You could
> probably even  remove copyright notices and warranties, since that
> wouldn't really  count as a derivative work.  You could also restrict
> the recipients  rights, which is easy since you don't have to include

SimPL.
>  
>  7. You can charge royalties for licensing, since there is no
> requirement  to license at no charge.

Good point.  We've modified the license to apply the conditions in the
second set of bullet points to distribution of the software or a Derived
Work, rather than just a Derived Work.  You can see the particular wording
in the new version that I've attached (I've attached a version showing edits
and a clean version showing current state).

>  6. Does noting when you change the software mean noting the date, or
> just noting that you changed it ('when' is ambiguous).

You're right, the language was a bit ambiguous.  We've modified it to be
more clear.

>  8. You may not be allowed to pass along written offers when
> distributing  occasionally and non-commercially.

I'm not sure I understand this point.  Could you clarify?

>  > 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
>  
>  What country's case law?

I'm sorry, we should have been more specific.  We were referring to the fact
that "derived works" is well-understood in U.S. case law.  However, we don't
think this is a particular problem for internationalization.  First, by
using a term that is well-understood in at least one jurisdiction, we give
courts a place to start when interpreting the license.  Even though the U.S.
definition isn't binding elsewhere, it can still be helpful.  In addition,
U.S. copyright law doesn't exist in a vacuum - it's linked to copyright law
of other countries through the various copyright treaties.  These treaties
(e.g. the Berne Convention) directly connect the right to make a derivative
work under U.S. law to parallel rights in other countries.  We believe that
this framework adds certainty to the interpretation.

>  > 5.  Why state that the licensee should "Follow all export control
laws?"
>  
>  OSD says you can remind them that they are required to follow the law
> (simply by virtue of the law's existence).  It also specifically adds,
> "however, it may not incorporate such restrictions itself.", which you
do.

We actually believe that your first interpretation of this term was the
correct one - this is simply a reminder that export control laws may apply.
The license does not include any of the limitations itself, which, under my
understanding, is what is prohibited by that section of the OSD.

>  > 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,
>  
>  Like GPLv2 does more clearly with "The source code for a work means
> the  preferred form of the work for making modifications to it."

The GPL's version turns on the interpretation of "preferred", while ours
turns on the interpretation of "easy".  Both are a bit subjective, but we
doubt either one would be all that hard for a court (or anyone else) to
interpret.

>  Okay, what about installation scripts?  And does that include OS code?

Right, should have included installation scripts as well.  


>  > 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)."  
>  
>  So it is supposed to include patents?  Because it isn't clear that
> GPLv2  does.

Yes, it is.  There are a lot of people who think that GPLv2 does include an
implied license to use any patents that the contributor has the right to
license.  We think it does and would like to avoid the ambiguity by more
clearly including patents in the grant (". . . comes with any rights that I
may have (other than trademarks)...").

Thanks again for your comments.

Jim Sfekas
Bob Gomulkiewicz

Simple Public License (SimPL)

Second edited version based on comments from the license-discuss list.  New text is underlined.

The SimPL applies to the software's source and object code and comes with any rights that I have in it (other than trademarks). You agree to the SimPL by copying, distributing, or making a derivative work of the software.
You get the right to:

• Use the software for any purpose;
• Make derivative works of it (this is called a "Derived Work");
• Copy and distribute it and any Derived Work.

 
If you distribute the software or a Derived Work, you must give back to the community by:

• Prominently noting when the date of any changes you made to it change the software;
• Leaving other people's copyright notices in place;
• Providing the source code, (including build scripts, installation scripts, and interface definitions) of any Derived Work in a form that is easy to get and use;
• Letting anyone make, free of charge, derivative works of any Derived Work;
• Licensing any Derived Work it under terms substantially similar to the SimPL.

 There are some things that you must shoulder:

• The software comes with NO WARRANTIES of any kind. None;
• If the software damages you in any way, you may only recover direct damages up to the amount you paid for it (that is zero if you did not pay anything). You may not recover any other damages, including those called "consequential damages." (The state or country where you live may not allow you to limit your liability in this way, so this may not apply to you);
• Follow all export control laws.

 The SimPL continues perpetually, except that your license rights end automatically if:

• You do not abide by the "give back to the community" terms (your licensees get to keep their rights if they abide);
• Anyone prevents you from distributing the software under the terms of the SimPL.

Simple Public License (SimPL)

Second edited version based on comments from the license-discuss list.  New text is underlined.

The SimPL applies to the software's source and object code and comes with any rights that I have in it (other than trademarks). You agree to the SimPL by copying, distributing, or making a derivative work of the software.
You get the right to:

• Use the software for any purpose;
• Make derivative works of it (this is called a "Derived Work");
• Copy and distribute it and any Derived Work.

 
If you distribute the software or a Derived Work, you must give back to the community by:

• Prominently noting the date of any changes you made to it;
• Leaving other people's copyright notices in place;
• Providing the source code, build scripts, installation scripts, and interface definitions in a form that is easy to get and use;
• Letting anyone make, free of charge, derivative works of any Derived Work;
• Licensing it under terms substantially similar to the SimPL.

 There are some things that you must shoulder:

• The software comes with NO WARRANTIES of any kind. None;
• If the software damages you in any way, you may only recover direct damages up to the amount you paid for it (that is zero if you did not pay anything). You may not recover any other damages, including those called "consequential damages." (The state or country where you live may not allow you to limit your liability in this way, so this may not apply to you);
• Follow all export control laws.

 The SimPL continues perpetually, except that your license rights end automatically if:

• You do not abide by the "give back to the community" terms (your licensees get to keep their rights if they abide);
• Anyone prevents you from distributing the software under the terms of the SimPL.

[Matthew Flaschen]

Jim Sfekas wrote:
> We chose this terminology because we didn't want to close off compatibility
> with other copyleft licenses. We could specify "GPL v 2.0", but that would
> leave out other options.

You could say "terms substantially similar to the SimPL, such as GPL v 2.0"

> We do believe that this gives enough guidance to
> interpret, especially in light of our expressed intention that the license
> parallel the terms of the GPL.

That isn't noted in the actual license.

>>  4. As I said before, it doesn't have the GPL's 2.c (retaining
>> copyright  and warranty options in interactive programs).
[snip]
> We have decided to leave out these elements because the extra complexity
> that they add outweighs any additional benefit.

I would recommend keeping 2.c. in particular, because such in-program
attribution is in high demand right now.

>>  1. You don't have to preserve license or warranty notices, or provide
>> a  copy of the license, even when redistributing derivative works (see
> #5).

It's still not clear that you have to keep the license or warranty
notices, and include the license itself.

>>  3. It doesn't make it clear that derived works must be licensed to
>> all  third parties.

I don't see anything about all third parties.

>>  7. You can charge royalties for licensing, since there is no
>> requirement  to license at no charge.

I still don't see this.  You have "Letting anyone make, free of charge,
derivative works" but it would be better just to require licensing at no
charge, since that includes derivative works.

>>  8. You may not be allowed to pass along written offers when
>> distributing  occasionally and non-commercially.
>
> I'm not sure I understand this point.  Could you clarify?

GPL allows one to satisfy the source requirement by "Accompany[ing] it
with the information you received as to the offer to distribute
corresponding source code." for "noncommercial distribution".  I don't
think SimPL allows this.

> We actually believe that your first interpretation of this term was the
> correct one - this is simply a reminder that export control laws may apply.
> The license does not include any of the limitations itself, which, under my
> understanding, is what is prohibited by that section of the OSD.

It's kind of a matter of interpretation.  However, such a reminder is
really unnecessary. Any copyright license assumes the user follows the
law, because copyright licenses are founded on copyright law.

> The GPL's version turns on the interpretation of "preferred", while ours
> turns on the interpretation of "easy".  Both are a bit subjective, but we
> doubt either one would be all that hard for a court (or anyone else) to
> interpret.

The difference is that preferred is absolute while easy isn't.  I can
obfuscate code a little (e.g. make all variable names single letters)
and have it still be arguably easy to modify; however, it's clearly not
the preferred form if I worked with the long variables.

>>  So it is supposed to include patents?  Because it isn't clear that
>> GPLv2  does.
>
> Yes, it is.  There are a lot of people who think that GPLv2 does include an
> implied license to use any patents that the contributor has the right to
> license.

I think so too, but it isn't *clear*.

Matt Flaschen

[Jim Sfekas]

As always, thanks for your comments on the license.  They've been extremely
helpful.  We've made a few changes in the latest version, which we believe
will address most of your remaining concerns.

Before we get into your specific comments, let me just note that we've added
a copyright license to the license document itself.  It's a very broad
license: anyone can use it or change it, with the only limitation that if
the author changes the license, he or she can no longer call it the SimPL.  

Now, to address your specific comments.

> You could say "terms substantially similar to the SimPL, such as GPL v
2.0"

> > We do believe that this gives enough guidance to interpret,
> > especially in light of our expressed intention that the license
> > parallel the terms of the GPL.

> That isn't noted in the actual license.

We've changed the license in two ways to take this into account.  First, we
added the "such as GPL 2.0" language that you suggested.  Second, we've
added a preamble describing the goals of the license and stating our
intention that the SimPL be interpreted as consistent with GPL 2.0.  The
preamble will help to guide people (and courts) in interpreting the terms of
the license.

> I would recommend keeping 2.c. in particular, because such in-program
> attribution is in high demand right now.

We've tried to address this in a slightly broader form.  Let us know what
you think of this.  First, the license now requires "leaving other people's
copyright notices and warranty disclaimers in place".  This would cover
notices and disclaimers anywhere in the code, including in the interface.

Second, the license now also requires "conspicuously announcing that [the
software or a Derived Work] is licensed under the SimPL".  This is intended
to ensure that people who use the software (or a derived work) are aware
that they are using an open source license.  This seems to us to be an
important element of 2.c.

We believe that the "conspicuously announcing" language allows significant
flexibility in implementation.  For example, in an interactive program, a
conspicuous announcement could include a splash screen on startup.  For an
operating system service, the announcement could be provided on the website
for the program or through some other means.  

> >>  1. You don't have to preserve license or warranty notices, or
> >> provide a  copy of the license, even when redistributing derivative
> >> works (see
> > #5).

> It's still not clear that you have to keep the license or warranty
> notices, and include the license itself.

The new language I mentioned above now requires that you leave copyright
notices and warranty disclaimers in place. Also, anyone distributing the
software or a Derived work is required to license it under the SimPL (or
compatible license).  By necessity, that means that anyone distributing
would have to include the license in the distribution.

> >>  3. It doesn't make it clear that derived works must be licensed to
> >> all  third parties.

> I don't see anything about all third parties.

We've changed the licensing requirement to require "licensing it to everyone
under terms..."  That should make it clear that the software and Derived
Works must be licensed to all third parties.

> >>  7. You can charge royalties for licensing, since there is no
> >> requirement  to license at no charge.

> I still don't see this.  You have "Letting anyone make, free of
> charge, derivative works" but it would be better just to require
> licensing at no charge, since that includes derivative works.

This is an interesting point and is one of the things that has made this
such a learning experience.  We were trying to literally follow the approach
of GPL 2.0 in Section 2(b), but this approach, as you correctly point out,
may not communicate as clearly as it should that all rights are granted
royalty free, not just the right to create derivatives.  

For the SimPL, we have basically incorporated your suggestion.  First, we've
changed the initial license grant to give "the royalty free right to: ..."
Second, we now require that you license the work "to everyone" under terms
substantially similar to the SimPL.  We've also eliminated the "letting
anyone make, free of charge, derivative works" requirement, because it is
now superfluous (i.e., because everyone is required to re-license the
royalty free right to make derivatives granted above).  It would also be
possible to add the phrase "including the royalty free right to create
Derived Works" to the end of the phrase "Licensing it to everyone under
terms substantially similar to the SimPL (such as GPL 2.0)" but we'd prefer
not to do this in the spirit of keeping things as short as possible--we're
fine either way, though.

> GPL allows one to satisfy the source requirement by "Accompany[ing] it
> with the information you received as to the offer to distribute
> corresponding source code." for "noncommercial distribution".  I don't
> think SimPL allows this.

We believe that the current requirement for providing the source code can
include this method without any additional language.  "Easy to get" could
certainly include distribution by physical media, as long as the process
isn't overly difficult.  There doesn't seem to be a compelling reason to add
a special case.

> > We actually believe that your first interpretation of this term was
> > the correct one - this is simply a reminder that export control laws
> > may apply.
> > The license does not include any of the limitations itself, which,
> > under my
> > understanding, is what is prohibited by that section of the OSD.

> It's kind of a matter of interpretation.  However, such a reminder is
> really unnecessary. Any copyright license assumes the user follows the
> law, because copyright licenses are founded on copyright law.

In the interest of not bogging the discussion down on this particular issue
and because it's not in GPL 2.0, we've dropped this clause from the latest
revision.
However, we would like to urge you to give more favorable consideration to
this clause for future licenses.  A clause like this is standard in many
commercial software licenses and is considered a "best practice" among many
licensing lawyers because it helps to protect the developer from liability
under the export control laws, which would be just as useful to an open
source developer as to a commercial developer.

> > The GPL's version turns on the interpretation of "preferred", while
> > ours turns on the interpretation of "easy".  Both are a bit
> > subjective, but we
> > doubt either one would be all that hard for a court (or anyone else)
> > to interpret.

> The difference is that preferred is absolute while easy isn't.  I can
> obfuscate code a little (e.g. make all variable names single letters)
> and have it still be arguably easy to modify; however, it's clearly
> not the preferred form if I worked with the long variables.

The clause now requires that the code be provided "in a form that is easy to
get and is best to modify".  That should prevent the obfuscation that you
were concerned about.

> >>  So it is supposed to include patents?  Because it isn't clear that
> >> GPLv2  does.
> >
> > Yes, it is.  There are a lot of people who think that GPLv2 does
> > include an
> > implied license to use any patents that the contributor has the
> > right to license.

> I think so too, but it isn't *clear*.

Our grant gives people all the rights they need to use and modify the
software.  By necessity, this would include patent rights.  In fact, our
prior modification (excluding trademark rights) makes it clear that we have
considered rights beyond just copyright.  As a bonus, this phrasing includes
any other rights that might apply.  For example, some countries give
protection to rights in databases - if it's necessary to use or modify the
software, we would certainly want to include those rights in the license.

Thanks again for your comments.

Jim Sfekas
Bob Gomulkiewicz

Preamble

This Simple Public License 2.0 (SimPL 2.0 for short) is a plain language implementation of GPL 2.0.  The words are different, but the goal is the same - to guarantee for all users the freedom to share and change software.  If anyone wonders about the meaning of the SimPL, they should interpret it as consistent with GPL 2.0.

You may do anything that you want with the SimPL license document; it's a form to use in any way that you find useful.  To avoid confusion, however, if you change the terms in any way then you may not call your license the Simple Public License or the SimPL (but feel free to acknowledge that your license is "based on the Simple Public License"). 

Simple Public License (SimPL) 2.0

The SimPL applies to the software's source and object code and comes with any rights that I have in it (other than trademarks). You agree to the SimPL by copying, distributing, or making a derivative work of the software.

You get the royalty free right to:

• Use the software for any purpose;
• Make derivative works of it (this is called a "Derived Work");
• Copy and distribute it and any Derived Work.

 
If you distribute the software or a Derived Work, you must give back to the community by:

• Conspicuously announcing that it is licensed under the SimPL;
• Prominently noting the date of any changes you make;
• Leaving other people's copyright notices, warranty disclaimers, and license terms  in place;
• Providing the source code, build scripts, installation scripts, and interface definitions in a form that is easy to get and best to modify;
• Licensing it to everyone under terms substantially similar to the SimPL (such as GPL 2.0).

 There are some things that you must shoulder:

• You get NO WARRANTIES. None of any kind;
• If the software damages you in any way, you may only recover direct damages up to the amount you paid for it (that is zero if you did not pay anything). You may not recover any other damages, including those called "consequential damages." (The state or country where you live may not allow you to limit your liability in this way, so this may not apply to you);

 The SimPL continues perpetually, except that your license rights end automatically if:

• You do not abide by the "give back to the community" terms (your licensees get to keep their rights if they abide);
• Anyone prevents you from distributing the software under the terms of the SimPL.

Preamble

This Simple Public License 2.0 (SimPL 2.0 for short) is a plain language implementation of GPL 2.0.  The words are different, but the goal is the same - to guarantee for all users the freedom to share and change software.  If anyone wonders about the meaning of the SimPL, they should interpret it as consistent with GPL 2.0.

You may do anything that you want with the SimPL license document; it's a form to use in any way that you find useful.  To avoid confusion, however, if you change the terms in any way then you may not call your license the Simple Public License or the SimPL (but feel free to acknowledge that your license is "based on the Simple Public License").  

Simple Public License (SimPL) 2.0

The SimPL applies to the software's source and object code and comes with any rights that I have in it (other than trademarks). You agree to the SimPL by copying, distributing, or making a derivative work of the software.

You get the royalty free right to:

• Use the software for any purpose;
• Make derivative works of it (this is called a "Derived Work");
• Copy and distribute it and any Derived Work.

 
If you distribute the software or a Derived Work, you must give back to the community by:

• Conspicuously announcing that it is licensed under the SimPL;
• Prominently noting the date of any changes you make made to it;
• Leaving other people's copyright notices, warranty disclaimers, and license terms in place;
• Providing the source code, build scripts, installation scripts, and interface definitions in a form that is easy to get and use best to modify;
• Letting anyone make, free of charge, derivative works of any Derived Work;
• Licensing it to everyone under terms substantially similar to the SimPL (such as GPL 2.0).

 There are some things that you must shoulder:

• You get NO WARRANTIES. None of any kind;
• If the software damages you in any way, you may only recover direct damages up to the amount you paid for it (that is zero if you did not pay anything). You may not recover any other damages, including those called "consequential damages." (The state or country where you live may not allow you to limit your liability in this way, so this may not apply to you);
• Follow all export control laws.

 The SimPL continues perpetually, except that your license rights end automatically if:

• You do not abide by the "give back to the community" terms (your licensees get to keep their rights if they abide);
• Anyone prevents you from distributing the software under the terms of the SimPL.

[Matthew Flaschen]

Jim Sfekas wrote:
> Before we get into your specific comments, let me just note that we've added
> a copyright license to the license document itself.  It's a very broad
> license: anyone can use it or change it, with the only limitation that if
> the author changes the license, he or she can no longer call it the SimPL.  

Good.  As a sidenote, it isn't very publicized, but the FSF actually
offers almost the same option for the GPL
(http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL).  You can modify it
as long as you change the name, completely remove the preamble (because
their philosophy may not be reflected in the new license), and remove
references to the FSF or GNU.

> We've changed the license in two ways to take this into account.  First, we
> added the "such as GPL 2.0" language that you suggested.

I just noticed a slight (undoubtedly unintended) problem.
"Conspicuously announcing that it is licensed under the SimPL" implies
the derivative work must be under SimPL.  But "Licensing it to everyone
under terms substantially similar to the SimPL (such as GPL 2.0)." makes
it clear other licenses are okay; in fact, the later can be read
(ignorantly) as requiring that SimPL /not/ be used.  I think both could
be resolved by saying instead:

* Licensing it to everyone under SimPL, or substantially similar terms
(such as GPL 2.0).
* Conspicuously announcing that it is available under that license

>  Second, we've
> added a preamble describing the goals of the license and stating our
> intention that the SimPL be interpreted as consistent with GPL 2.0.

Thank you.  That should mostly resolve the compatibility issues (though
someone could still make an arguably "substantially similar" license
without this compatibility provision and break the chain).

>> I would recommend keeping 2.c. in particular, because such in-program
>> attribution is in high demand right now.
>
> We've tried to address this in a slightly broader form.  Let us know what
> you think of this.  First, the license now requires "leaving other people's
> copyright notices and warranty disclaimers in place".  This would cover
> notices and disclaimers anywhere in the code, including in the interface.

I like the simplicity, but I don't know if it will work.  GPL says in
section 1, "keep intact all the notices that refer to this License and
to the absence of any warranty; and give any other recipients of the
Program a copy of this License along with the Program." but they still
felt 2.c was necessary.  Also, you can hide an interface without
actually removing the code that creates it.

> Second, the license now also requires "conspicuously announcing that [the
> software or a Derived Work] is licensed under the SimPL".

Okay, that along with "Leaving [...] license terms in place" should
guarantee full disclosure of the license.

> We believe that the "conspicuously announcing" language allows significant
> flexibility in implementation.  For example, in an interactive program, a
> conspicuous announcement could include a splash screen on startup.  For an
> operating system service, the announcement could be provided on the website
> for the program or through some other means.

Yes, that makes sense, and in some ways is more accommodating than 2.c
(which basically requires either immediate notice for interactive
programs or no notice for non-interactive ones)..

>> I don't see anything about all third parties.
>
> We've changed the licensing requirement to require "licensing it to everyone
> under terms..."  That should make it clear that the software and Derived
> Works must be licensed to all third parties.

Yes, that seems to work.

>> I still don't see this.  You have "Letting anyone make, free of
>> charge, derivative works" but it would be better just to require
>> licensing at no charge, since that includes derivative works.
>
> This is an interesting point and is one of the things that has made this
> such a learning experience.  We were trying to literally follow the approach
> of GPL 2.0 in Section 2(b), but this approach, as you correctly point out,
> may not communicate as clearly as it should that all rights are granted
> royalty free, not just the right to create derivatives.

Really?  I think the GPL's "You must cause any work that you distribute
or publish [...] to be licensed as a whole at no charge to all third
parties under the terms of this License" covered everything (since the
License includes all rights).

You could do it similarly with "Licensing it, royalty free, to everyone
[...]"

> For the SimPL, we have basically incorporated your suggestion.  First, we've
> changed the initial license grant to give "the royalty free right to: ..."

Yes, I think that should work too.

>> GPL allows one to satisfy the source requirement by "Accompany[ing] it
>> with the information you received as to the offer to distribute
>> corresponding source code." for "noncommercial distribution".  I don't
>> think SimPL allows this.
>
> We believe that the current requirement for providing the source code can
> include this method without any additional language.  "Easy to get" could
> certainly include distribution by physical media, as long as the process
> isn't overly difficult.  There doesn't seem to be a compelling reason to add
> a special case.

Maybe not, but the difference is that here the distributor isn't
"Providing the source code", but rather telling the recipient how to get
it somewhere else.

> In the interest of not bogging the discussion down on this particular issue
> and because it's not in GPL 2.0, we've dropped this clause from the latest
> revision.
> However, we would like to urge you to give more favorable consideration to
> this clause for future licenses.  A clause like this is standard in many
> commercial software licenses and is considered a "best practice" among many
> licensing lawyers because it helps to protect the developer from liability
> under the export control laws, which would be just as useful to an open
> source developer as to a commercial developer.

I don't think export clauses are in any major open source license
(correct me if I'm wrong), so I don't think the liability concern is
very significant (especially now that open source has certain immunity
from this law in the U.S.).

>> The difference is that preferred is absolute while easy isn't.  I can
>> obfuscate code a little (e.g. make all variable names single letters)
>> and have it still be arguably easy to modify; however, it's clearly
>> not the preferred form if I worked with the long variables.
>
> The clause now requires that the code be provided "in a form that is easy to
> get and is best to modify".  That should prevent the obfuscation that you
> were concerned about.

Thank you.  I understand that some of these concerns are relatively
minor, but you only get to write the license once.

> Our grant gives people all the rights they need to use and modify the
> software.  By necessity, this would include patent rights.

I think that makes sense.  I just wanted to be clear that it's possibly
broader/more specific than the GPL.

> Thanks again for your comments.

Thank you.

Matt Flaschen

[Jim Sfekas]

Thanks for working with us this past few months.  I think we have a much
better license than we did at the beginning of the process--better but still
simple.  This will be a much shorter e-mail, since I think there's basically
only one open issue (and that's easy to resolve).  For everyone's
convenience, I've attached the final version of the license.

> > We've changed the license in two ways to take this into account.  
> > First, we
> > added the "such as GPL 2.0" language that you suggested.

> I just noticed a slight (undoubtedly unintended) problem.
> "Conspicuously announcing that it is licensed under the SimPL" implies
> the derivative work must be under SimPL.  But "Licensing it to
> everyone under terms substantially similar to the SimPL (such as GPL
> 2.0)." makes it clear other licenses are okay; in fact, the later can
> be read
> (ignorantly) as requiring that SimPL /not/ be used.  I think both
> could be resolved by saying instead:

> * Licensing it to everyone under SimPL, or substantially similar terms
> (such as GPL 2.0).
> * Conspicuously announcing that it is available under that license

That's a good point.  We certainly didn't intend that.  We've modified the
license as you suggested.

> Thank you.  That should mostly resolve the compatibility issues
> (though someone could still make an arguably "substantially similar"
> license without this compatibility provision and break the chain).

We agree this shouldn't be a material problem.  First and most importantly,
including a compatibility term should be part and parcel of a "substantially
similar" license because this is material term.  Second, if someone decides
to take advantage of the compatibility option they will most likely
re-license under GPL 2.0 which, of course, would be fine.  Third,
re-licensing under a non-GPL OSI-approved open source license would have
gone through the OSI vetting process, so there's a good chance that it will
compatible with other open source licenses.

We appreciate your feedback and we look forward to your board's
consideration of the SimPL in June (thanks for letting us know it's on the
agenda).

Jim Sfekas
Bob Gomulkiewicz

Preamble

This Simple Public License 2.0 (SimPL 2.0 for short) is a plain language implementation of GPL 2.0.  The words are different, but the goal is the same - to guarantee for all users the freedom to share and change software.  If anyone wonders about the meaning of the SimPL, they should interpret it as consistent with GPL 2.0.

You may do anything that you want with the SimPL text; it's a license form to use in any way that you find helpful.  To avoid confusion, however, if you change the terms in any way then you may not call your license the Simple Public License or the SimPL (but feel free to acknowledge that your license is "based on the Simple Public License"). 

Simple Public License (SimPL) 2.0

The SimPL applies to the software's source and object code and comes with any rights that I have in it (other than trademarks). You agree to the SimPL by copying, distributing, or making a derivative work of the software.

You get the royalty free right to:

• Use the software for any purpose;
• Make derivative works of it (this is called a "Derived Work");
• Copy and distribute it and any Derived Work.

 
If you distribute the software or a Derived Work, you must give back to the community by:

• Prominently noting the date of any changes you make;
• Leaving other people's copyright notices, warranty disclaimers, and license terms  in place;
• Providing the source code, build scripts, installation scripts, and interface definitions in a form that is easy to get and best to modify;
• Licensing it to everyone under SimPL, or substantially similar terms (such as GPL 2.0);
• Conspicuously announcing that it is available under that license.

There are some things that you must shoulder:

• You get NO WARRANTIES. None of any kind;
• If the software damages you in any way, you may only recover direct damages up to the amount you paid for it (that is zero if you did not pay anything). You may not recover any other damages, including those called "consequential damages." (The state or country where you live may not allow you to limit your liability in this way, so this may not apply to you);

 The SimPL continues perpetually, except that your license rights end automatically if:

• You do not abide by the "give back to the community" terms (your licensees get to keep their rights if they abide);
• Anyone prevents you from distributing the software under the terms of the SimPL.