<div dir="ltr"><div class="gmail_extra">On Wed, Sep 3, 2014 at 10:26 AM, Josh Berkus <span dir="ltr"><<a href="mailto:josh@postgresql.org" target="_blank">josh@postgresql.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 09/01/2014 06:08 AM, John Dallaway wrote:<br>
>> > Thanks for pointing to the wxWindows license -- however the OSI's<br>
>> > approval of that license seems to be from the late 2002 timeframe,<br>
>> > before the rise of concerns about license proliferation and 'vanity<br>
>> > licenses' and such.<br>
> I appreciate OSI concerns regarding license proliferation. This is why<br>
> the <span>eCos</span> maintainers are seeking legacy approval. The <span>eCos</span> License 2.0<br>
> appears to fit this approval category well.<br>
<br>
</span>Seems like we need a special class for "GPL Exception Licenses".</blockquote></div><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br><b>Background<br></b><br>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<br><div style="margin-left:40px"><pre>[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...<br></pre></div></div><div class="gmail_extra">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.]</div><div class="gmail_extra"><br></div><div class="gmail_extra">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".<br><br></div><div class="gmail_extra"><b>Some pros and cons:</b><br></div><div class="gmail_extra"><ol><li>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.</li><li>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).</li><li>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.</li><li>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.<br></li></ol></div><div class="gmail_extra">On balance, these are not very persuasive, but we've probably approved worse, so I can't rule it out.<br><br><b>A different approach</b><br><br>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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thoughts?<br></div><div class="gmail_extra">Luis<br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra"><br></div><br></div>