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