For Approval: Simple Public License (SimPL)
sfekas at u.washington.edu
Sun May 27 05:15:06 UTC 2007
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
> > 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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-discuss