On Thu, May 23, 2019 at 4:08 PM Richard Fontana <[email protected]> wrote: > On Wed, May 22, 2019 at 4:48 AM Henrik Ingo <[email protected]> wrote: > > > - According to many imprecise metrics, 99% of all open source software > > in the world is covered by a list of about 20 licenses > > (https://web.archive.org/web/20190115063327/https://www.blackducksoftware.com/top-open-source-licenses) > > - OSI list is 82 licenses, plus 15 retired or superceded licenses. So > > it follows that this covers way more than 99% of open source software > > ever written. > > - Naturally there will be a lot more licenses that also do comply with > > the OSD. Especially if they are trivial variations of an approved > > license. > > - When we say that software is only open source if released with an > > OSI approved license, it really comes with this rounding error that > > 0,0..1% of software exists that is also open source. In practical > > terms this is small enough that it is not worth to mention separately, > > rather the "fundamenalist" statement is close enough. > > But very often -- at least in the traditional Linux distribution > universe I spend a lot of time in -- non-OSI-approved legacy > (generally non-copyleft) licenses appear *within* packages that are > portrayed or at least popularly conceived as being under another > license, whether that's a copyleft or noncopyleft license. > > I think the value of 'mass legacy approval' might be to address the > criticism I've seen of the OSI apparently claiming that non-approved > licenses are not open source or validly referred to as open source > when no one could credibly argue that they are not open source. It > would also address my concerns about Van's interpretation. But I'm not > sure whether the effort would be justified.
Note that distros and OSI have different motivations here. For a distro there is value in actively pulling in some code, because it provides some functionality that makes the distro better and provides value to users. The distro then has a process for determining that the added code can be considered open source. (And in many cases also a process for adding non-free code via a clearly separate channel.) OSI process otoh is based on someone being bothered to first submit the license to OSI. So the motivation starts at an external source. >From this it quite naturally follows that I would expect the list of licenses in distros to always be a superset of the OSI list. In fact, the opposite world doesn't make sense: OSI wouldn't approve licenses that nobody is using. A specific recent example was the (mailing list) rejection of the libpng license. It was rejected as a bad license, even if it probably is open source. In this situation it is natural that distros continue to ship libpng. The goals for OSI and distros are different. My argument in the quoted email was that OSIs list is rather comprehensive and it is indeed not worth the effort to chase the long tail of still unapproved licenses. But from this email one might conclude that if we wanted to pursue that, an approach that aligns with existing processes would be for the distros to come together and submit a batch of (hopefully short) licenses for OSI to approve. henrik -- [email protected] +358-40-5697354 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 _______________________________________________ License-discuss mailing list [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
