[License-review] GPL exceptions, eCos, and wxwindows [was re eCos]

[Luis Villa]

On Wed, Sep 3, 2014 at 10:26 AM, Josh Berkus <josh at postgresql.org> wrote:

> On 09/01/2014 06:08 AM, John Dallaway wrote:
> >> > Thanks for pointing to the wxWindows license -- however the OSI's
> >> > approval of that license seems to be from the late 2002 timeframe,
> >> > before the rise of concerns about license proliferation and 'vanity
> >> > licenses' and such.
> > I appreciate OSI concerns regarding license proliferation. This is why
> > the eCos maintainers are seeking legacy approval. The eCos License 2.0
> > appears to fit this approval category well.
>
> Seems like we need a special class for "GPL Exception Licenses".


tl;dr: I am open to considering this, but after thinking about it some I'd
favor a simple statement along the lines that "granting additional
permissions to approved licenses is always OK" and, giving eCos and
WxWindows as useful examples.


*Background*
I simply don't think eCos is best thought of as a license. It is rather
(quite explicitly!) GPL + an exception. The "license" itself even says

[Y]ou can redistribute [eCos] and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation...

My read of this is that an eCos recipient can, if they so desire, simply
redistribute as GPL without the exception. [WxWindows is even more explicit
about this.]

This is different from a case of copying the entire license and changing
the name, as some of the MPL 1.1 variants did - in those cases, a recipient
could not merely say "I'd like to use MPL instead".

*Some pros and cons:*

   1. From a proliferation/analysis perspective, eCox/WxWindows "licenses"
   are less of a problem, since any user who is concerned about compatibility
   can just treat it identically to GPL to simplify their analysis. This
   weighs in favor of approving eCos: it isn't, in practice, a proliferation
   problem.
   2. From a perspective of labeling, these are best described as
   exceptions from the GPL rather than standalone licenses. This weighs
   against approving eCos: calling it a full license is confusing/misleading
   (somewhat offsetting the previous point).
   3. Both of these have been reviewed/"approved" by FSF, so this does not
   create any new grounds for tension between us and FSF. Does not weigh
   against approval, as someone had raised to me off-list.
   4. I don't really want to be in the business of reviewing the many small
   variants of many popular licenses (MIT, BSD, GPL, etc., etc.) That would
   just be a never-ending flood of requests. Weighs against approval.

On balance, these are not very persuasive, but we've probably approved
worse, so I can't rule it out.

*A different approach*

We could simply make a clear statement that any additional *optional
permission* added to an existing/approved license is, itself, open source.
This has always been our defacto policy, I think; would make a clear/useful
statement more broadly; and would prevent us from having to deal with an
ongoing series of requests about the many old, standard exceptions that are
hanging out there.

Thoughts?
Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20140915/7cc11547/attachment.html>