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

[John Dallaway]

Luis

On Tue Sep 16 04:39:04 UTC 2014, Luis Villa wrote:

> 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).

I see the distinction between "standalone" and "GPL + exception" as
somewhat artificial since an exception clause can change the licensing
terms in a very significant way (not necessarily permissive).
Nevertheless, the distinction could be useful for the purpose of
categorisation.

>    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.

The legacy approval process limits such requests to "historic/legacy
licenses that have already been extensively used by an existing
community, but have not previously been approved". On that basis, the
rate at which approval requests are received seems likely to diminish
over time.

> 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?

With the above approach, the onus is on the licensee (rather than the
OSI) to determine whether a exception clause is strictly permissive-only
and hence whether the license can be considered to be OSI-approved.
Consider the scenario where the wording of an exception clause could be
interpreted as restrictive in some sense by some readers, but the
licensor claims that the license is OSI-approved. How would a licensee
or a funding body which has an "OSI-approved licenses only" policy
confirm beyond doubt the status of the license?

On the other hand, if the OSI board was to adopt a policy that all "GPL
+ permissive exception" licenses which meet the "legacy approval"
submission criteria should be approved, it seems that the subsequent
effort involved in approving and listing such licenses would be small.

Regards

John Dallaway