Hey,
I confirmed it with upstream.
The files with GPL 2 license were actually not included in compilation and are now removed. Most of the small files without license are test data which obviously cannot be edited to contain license, but I have omitted the license from individual code files too, because I hope it would be sufficient to have GPL3 in the main docs, covering the whole library.The winpthreads.md needs to be included with Windows binaries, but that library is not used in other platforms, and thus not relevant to this.
Should I go ahead with GPL3 then?
Regards,
Purusharth S.
On Sat, 9 May 2020 at 00:18, David Cantrell <dcantrell@xxxxxxxxxx> wrote:
On Fri, May 08, 2020 at 06:11:32PM +0100, J. Randall Owens wrote:
>On 08/05/2020 17:33, David Cantrell wrote:
>> On Fri, May 08, 2020 at 03:41:36AM +0530, Purusharth Saxena wrote:
>>> Hi folks,
>>>
>>> I'm packaging tpcclib
>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1832562)
>>> and as per the review, I wanted to confirm the licence for tpcclib (
>>> https://gitlab.utu.fi/vesoik/tpcclib/-/blob/master/license.md)
>>> Should it be "GPLv2+ and GPLv3+ "or something else?
>>
>> The copying.md file includes this:
>>
>> "This program library is free software; you can redistribute it and/or
>> modify
>> it under the terms of the GNU General Public License as published by the
>> Free
>> Software Foundation; either version 3 of the License, or (at your
>> option) any
>> later version."
>>
>> The '+' on the GPLv3+ means "GPL version 3 or any later version.
>>
>> It's also a good idea to check for license text in individual files in the
>> project. For GPL projects, I like to do this:
>>
>> find . -type f | xargs grep "General Public"
>>
>> Which does a more or less ok job of finding files with what is probably
>> a GPL
>> boilerplate. That gives me 39 files. Now, that's all files including
>> non-source. But in this case I am looking for any file that would indicate
>> something other than GPLv3+ Further refining:
>>
>> find . -type f | xargs grep "General Public" | \
>> cut -d ':' -f 1 | sort | uniq
>>
>> Gives me 10 files. I can do this:
>>
>> find . -type f | xargs grep "General Public" | \
>> cut -d ':' -f 1 | sort | uniq \
>> xargs grep -i "any later version"
>>
>> And see it matches 6 files. So 4 of those original files found lack the
>> same
>> kind of boilerplate. Running the previous command and comparing it to what
>> was found, I see the sounds files in v1/ and v2/ were left out.
>
>Side tip: I'm guessing you don't know about `grep -rl`, & maybe a little
>`sort -u`? These could be much simplified as:
> grep -rl "General Public"
> grep -rl "General Public" | xargs grep -i "any later version"
>(which I guess eliminates the `sort | uniq` step anyway).
I do actually know about those options. They've just never made it to my
muscle memory. cut(1) is my hammer and stdin are nails. ¯\_(ツ)_/¯
In this case, my needlessly exhaustive and verbose command makes it clear to
the reader what I'm doing where condensing it with options could be somewhat
more confusing depending on the audience. (though cut is also cryptic to
anyone who hasn't used it...oh well)
Thanks,
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
