For Approval: Simple Public License (SimPL)

[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

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