For Approval: Simple Public License (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