[License-review] Legacy Approval, Licnese of Jam

McCoy Smith mccoy at lexpan.law
Mon Apr 26 20:03:26 UTC 2021

> -----Original Message-----
> From: Richard Fontana <rfontana at redhat.com>
> Sent: Monday, April 26, 2021 12:52 PM
> To: mccoy at lexpan.law; License submissions for OSI review <license-
> review at lists.opensource.org>
> Subject: Re: [License-review] Legacy Approval, Licnese of Jam
>If you say licenses of this sort are not open
> source, that would mean that many packages assumed to be open source
> are actually only partly open source, and perhaps even embody some sort of
> FOSS license violation. In this case it is clear from the license text that "use"
> was meant to encompass permission to modify.
> There are other cases where legacy licenses have later come to be seen as
> non-FOSS, the best example of which may be the Sun RPC license.
> (See: https://spot.livejournal.com/315383.html) But those are cases where it
> is impossible to read the license as being consistent with normative
> definitions of FOSS.
> I don't know if OSI should start granting legacy approval to the large numbers
> of licenses of this sort, but I see some benefits to moving OSI approval closer
> to the reality of how "open source" is understood in the community.
> The strongest objection I see to granting legacy approval here is why the OSI
> should start with *this* license when there are plenty of others in the same
> category that are probably more frequently encountered.
Yes, it seems like the legacy standard is looser than for non-legacy approvals. I'm curious how loose it ought to be. This one probably meets the OSD if you assume a lot of liberality on implied license grants (both copyright, and patent). Also, for legacy approvals, what quanta of current usage is required? One package seems pretty low.

More information about the License-review mailing list