On Sun, Aug 26, 2018 at 7:15 AM Michał Górny <[email protected]> wrote: > > On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote: > > On 26/08/2018 12:53, Mart Raudsepp wrote: > > > The common issue here is that upstream COPYING files really do only > > > talk about one of the versions. And then you get to validate or source > > > files to be sure that they do have a "or later" clause in them. And > > > then on each bump you ideally should validate it again, etc, that no > > > sources without "or later" allowance are in there... > > > > Yup, precise tracking of license metadata can be a pain. > > > > I'm not really sure if that level of it is worth for us as a distro. For > > _importing_ other project's source code directly into one's project > > precise license compatibility matters a lot. That's not the scenario > > we're in. I see LICENSES as mostly a mechanism for end users to accept > > or reject EULAs etc, and I'm curious what are other common scenarios. > > > > Michał, could you elaborate on why not distinguishing more precisely > > between these GPL variants in LICENSES is a _problem_ ? I can certainly > > see the information is not always accurate, but it's not obvious to me > > how severe is the downside, what are the consequences in practice. > > > > I'm not aware of any major implications. However, I think that if we > provide for the distinction, the distinction should be used correctly. >
IMO QA policy ought to be that the license is correct. How much time/effort goes into policing the policy in the case of 2/3/2+/3+ is a different matter. If people want to do it, great, but IMO it isn't adding tremendous value. I doubt we have any users relying on license filtering to distinguish between GPL2/2+. If somebody files a bug pointing out an incorrect license it should be fixed as a matter of policy, but I'm not sure more than that is necessary in this particular case. If we were talking about nonfree licenses being missed that would be more critical. -- Rich
