For Approval: Simple Public License (SimPL)

[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