On Tue, Jan 11, 2022 at 11:32:12AM +0100, Fabio Valentini wrote:
On Mon, Jan 10, 2022 at 5:41 PM David Cantrell <dcantrell@xxxxxxxxxx> wrote:
On Wed, Jan 05, 2022 at 02:59:33AM +0100, Miroslav Suchý wrote:
>Dne 04. 01. 22 v 21:03 David Cantrell napsal(a):
>>One of the difficult things with the Fedora abbreviations is that
>>tokens can have spaces in them. For example, the Apache 2.0 license
>>in Fedora is called "ASL 2.0". This makes it really hard to work with
>>in software.
>>
>>Likewise, we have historically allowed full expressions through that
>>contain otherwise forbidden licenses. For example, many Perl module
>>packages use the License tag "GPL+ or Artistic" so in a way that
>>entire expression is treated as a token.
>>
>>This information is currently captured in this JSON file (not the
>>original author, but I make use of the file):
>>
>>https://github.com/rpminspect/rpminspect-data-fedora/blob/master/licenses/fedora.json
>>
>>rpminspect's license check uses this data to validate the License tag
>>in RPM headers based on the rules as they exist in the packaging
>>guidelines plus the assorted expressions we have historically allowed
>>through that would not otherwise validate.
>
>*nod*
>
>The string
>
> 'GPL+ or Artistic or MIT'
>
>evaluates license-validate as correct, while rpminspect results that as bad license.
But this expression is not valid. It would be valid as
(GPL+ or Artistic) or MIT
That's probably splitting hairs.
The "and" and "or" boolean connectives are associative, so the
parentheses can be dropped without losing information.
Something different would be mixing "and" and "or", then the
parentheses are necessary to preserve structural information.
But for a list of only-"or"-ed or only-"and"-ed licenses, no
parentheses are necessary.
Correct when taking the tokens individually. I was basing my reply on the
fact that Fedora had approved "GPL+ or Artistic" as a single token.
Separately GPL+ is approved and Artistic is not approved. Again, just looking
at the data as found in spec files and the approved license list.
Since this thread, this topic has been discussed and addressing the
inconsistency here is part of the license data cleanup effort.
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
