Date   

meeting at top of the hour

J Lovejoy
 

Hi all,

Just a last minute reminder of our regular call today at the top of the hour.

As mentioned previously, for the next release cycle (through end of Sept) we are going to focus on updating and improving documentation related to the SPDX License List. Please have a look at the issues labeled “documentation” - we’ll discuss whether there is anything else we should add to our list on the call and start divvying up tasks!

https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.19+%28documentation%29%22

Thanks,
Jilayne


Idea: SPDX-DCO-File-License-Identifier

Richard Fontana
 

I've thought some more about certain unintended problems some of us
were previously discussing regarding the use of
SPDX-License-Identifier: in source files. In particular it's occurred
to me that the practice is in tension with the use of the Developer
Certificate of Origin. This is significant given that Linux is the
most important project to have adopted both the DCO and the use of
SPDX-License-Identifier.

Somewhat problematically, the DCO makes reference to a license of a
*file* in its certification: "The contribution was created in whole or
in part by me and I have the right to submit it under the open source
license indicated in the file." Most open source projects (including
possibly most DCO-using open source projects, a tiny minority of open
source projects) do not use explicit licensing of source files, a
practice I understand SPDX at least implicitly disapproves of. In
typical situations, the use of SPDX-License-Identifier: has the nice
feature of clarifying what the "open source license indicated in the
file" is in a standard way.

But for any source file that properly uses SPDX-License-Identifier and
is based on multiply-licensed code (for example, a file properly
reflecting contributions under both GPLv2 and the 3-clause BSD
license), the DCO-related benefit goes away. I don't know if there is
an example like this in the kernel, but suppose the kernel had such a
source file, saying "SPDX-License-Identifier: GPL-2.0-only AND
BSD-3-Clause". What is the "license indicated in the file" for
purposes of the DCO? Prior to the use of SPDX-License-Identifier, the
variously-worded GPL headers might have made it sufficiently clear
that the license for purposes of the DCO is GPLv2 (GPL-2.0-only). Or
the situation was ambiguous but you could then rely on the note from
Linus Torvalds in the kernel COPYING file (or wherever that lives
now). Now, it appears that a DCO-certifying contributor to a file that
already has (based on an analysis of past-incorporated license
notices) "SPDX-License-Identifier: GPL-2.0-only AND BSD-3-Clause" is
certifying that they have the right to submit it under the stated
composite license. It's not even clear this is non-nonsensical -- how
can a single isolable contribution by one person be licensed under two
different open source licenses in a conjunctive, not disjunctive,
sense? (As I said previously, the snippet construct is probably not
going to be practical to use in most cases and I'm not sure it solves
the problem anyway.)

So I am wondering if it would be a good solution to introduce an
additional construct like "SPDX-DCO-File-License-Identifier" for those
cases involving source files where SPDX-License-Identifier: would
imply a licensing policy at odds with the actual policy of the
project. For example, you could have a source file with the following
header:

SPDX-License-Identifier: GPL-2.0-only AND BSD-3-Clause
SPDX-DCO-File-License-Identifier: GPL-2.0-only

Note this is different from the issue that McCoy was asking about in
an earlier thread, but I think it is somewhat related.

The issue of course is not really limited to projects using the DCO,
but rather any project that informally or otherwise adopts an
"inbound=outbound" approach to licensing of contributions, which is
the vast majority of open source projects (so maybe a solution
shouldn't seem to be DCO-specific). A concern I have is that the use
of SPDX-License-Identifier: may be unintentionally optimized for the
use of that minority of projects that use asymmetric contributor
license agreements to handle licensing in of contributions.

Richard

On Mon, Jul 18, 2022 at 8:14 PM Richard Fontana <rfontana@...> wrote:

I feel like what some projects might find useful is something like:

SPDX-License-Identifier-Concluding-What's-Been-Contributed-As-Of-Some-Past-Time:
SPDX-License-Identifier-Of-What's-Been-Contributed-After-That-Past-Time-And-Default-License-of-Future-Contributions:

since these might point to different licenses. The snippet construct
can possibly express this adequately in some cases but I think
reliable identification of a snippet will normally be impractical.

Richard

On Sun, Jul 17, 2022 at 3:18 PM McCoy Smith <mccoy@...> wrote:

At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs outbound, then AND may not be commutative, since the order of listing the licenses may convey information about which license is inbound vs outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point already.

On Jul 17, 2022, at 11:22 AM, Richard Fontana <rfontana@...> wrote:

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard





b


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Neal Gompa
 

On Mon, Aug 1, 2022 at 4:20 AM Phil Odence via lists.spdx.org <phil.odence=synopsys.com@...> wrote:

Nice. This certainly makes it easy to map from Fedora to SPDX IDs!

 SPDX license identifiers have emerged as a standard

 

Woo hoo!

_,_._,_

I hope you are all ready for the upcoming pains in the next few years. Transitioning Fedora to SPDX is not going to be a happy time for a little while, since there's a huge impedance mismatch between Fedora and SPDX, as well as an incomplete identification of licenses on the SPDX side. I know I'm not looking forward to recategorizing all the MIT and BSD license variants. I expect we're going to see a lot of new license submissions over the coming years as all packages get re-audited in a future phase...

I wonder if we're going to regret this extra "precision" in the end?

On a personal note, I am still rather upset about some aspects of the expression syntax that I had been informed years ago would be fixed, but has apparently not been. In particular, the specification still does not allow lowercase "or"/"and"/"with" even though all the parsers accept it. Reading SPDX expressions with capital operands is very painful for humans (which is what these things are actually for). Any chance we can get this fixed soon?



--
真実はいつも一つ!/ Always, there's only one truth!


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Phil Odence <phil.odence@...>
 

Nice. This certainly makes it easy to map from Fedora to SPDX IDs!

 SPDX license identifiers have emerged as a standard

 

Woo hoo!

 

 

From: Spdx-legal@... <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...>
Date: Saturday, July 30, 2022 at 12:06 PM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>, spdx@... <spdx@...>, Spdx-tech@... <Spdx-tech@...>, Spdx-outreach@... <Spdx-outreach@...>
Subject: Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Jilayne, this is awesome news -- thanks for passing it along!

 

Looking forward to us working with the Fedora community to support them adding SPDX license IDs across the distro.

 

Steve

 

On Fri, Jul 29, 2022 at 12:21 PM J Lovejoy <opensource@...> wrote:

Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne



-------- Forwarded Message --------

Subject:

[Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)

Date:

Fri, 29 Jul 2022 11:19:48 -0400

From:

Matthew Miller <mattdm@...>

Reply-To:

legal@...

To:

devel-announce@...

CC:

packaging@..., legal@..., devel@...




On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../


-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
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/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


the "documentation release" for 3.19

J Lovejoy
 

Hi all,

On our call a few days ago, Steve raised the idea of using the next release to JUST focus on documentation improvements. There haven’t been a ton of new license requests and some of the documentation could use a refresh with a bird’s eye view. I have now gone through all the issues and added a few accordingly. Please feel free to start adding notes or other issues, if I’ve missed any documentation we ought to review.

https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.19+%28documentation%29%22

I included a couple “technical issues” for 3.19 at least for discussion as those also seemed to have gotten overlooked.

We’ll focus on getting 3.18 out (see previously email) and then get after documentation!


Thanks,
Jilayne


prep for 3.18 release

J Lovejoy
 

Hi all,

I just went through all the issue in terms of what we can likely get in for the 3.18 release. Seems like most issues are already assigned to Steve or I :)

Could someone pick up this one and prepare the XML and .txt files? https://github.com/spdx/license-list-XML/issues/1525

If we could get help on that one, even if we need to push the release a few more days, I think that would be good.

Thanks!
Jilayne


Re: [spdx-tech] Important changes to software license information in Fedora packages (SPDX and more!)

Steve Winslow
 

Jilayne, this is awesome news -- thanks for passing it along!

Looking forward to us working with the Fedora community to support them adding SPDX license IDs across the distro.

Steve

On Fri, Jul 29, 2022 at 12:21 PM J Lovejoy <opensource@...> wrote:
Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne


-------- Forwarded Message --------
Subject: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
Date: Fri, 29 Jul 2022 11:19:48 -0400
From: Matthew Miller <mattdm@...>
Reply-To: legal@...
To: devel-announce@...
CC: packaging@..., legal@..., devel@...



On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../



-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
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/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


Important changes to software license information in Fedora packages (SPDX and more!)

J Lovejoy
 

Hot off the press!

Link to blog post of this here: https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/

Thanks for the support on this from SPDX-legal. There is more work to come, for sure, but being able to use SPDX license identifiers in a full distro is a great challenge for our project to meet!

:)

Jilayne


-------- Forwarded Message --------
Subject: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
Date: Fri, 29 Jul 2022 11:19:48 -0400
From: Matthew Miller <mattdm@...>
Reply-To: legal@...
To: devel-announce@...
CC: packaging@..., legal@..., devel@...



On behalf of all of the folks working on Fedora licensing improvements,
I have a few things to announce!


New docs site for licensing and other legal topics
--------------------------------------------------

All documentation related to Fedora licensing has moved to a new
section in Fedora Docs, which you can find at:

https://docs.fedoraproject.org/en-US/legal/

Other legal documentation will follow. This follows the overall Fedora
goal of moving active user and contributor documentation away from the
wiki.


Fedora license information in a structured format
-------------------------------------------------

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are
now stored in a repository, using a simple structured file format for
each license (it’s TOML). You can find this at:
https://gitlab.com/fedora/legal/fedora-license-data

This data is then presented in easy tabular format in the
documentation, at:

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/



New policy for the License field in packages — SPDX identifiers!
----------------------------------------------------------------

We’re changing the policy for the "License" field in package spec files
to use SPDX license identifiers. Historically, Fedora has represented
licenses using short abbreviations specific to Fedora. In the meantime,
SPDX license identifiers have emerged as a standard, and other
projects, vendors, and developers have started using them. Adopting
SPDX license identifiers provides greater accuracy as to what license
applies, and will make it easier for us to collaborate with other
projects.


Updated licensing policies and processes
----------------------------------------

Fedora licensing policies and processes have been updated to reflect
the above changes. In some cases, this forced deeper thought as to how
these things are decided and why, which led to various discussion on
Fedora mailing lists. In other cases, it prompted better articulation
of guidance that was implicitly understood but not necessarily
explicitly stated.


New guidance on “effective license” analysis
--------------------------------------------

Many software packages consist of code with different free and open
source licenses. Previous practice often involved “simplification” of
the package license field when the packager believed that one license
subsumed the other — for example, using just “GPL” when the source code
includes parts licensed under a BSD-style license as well. Going
forward, packagers and reviewers should not make this kind of analysis,
and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach
is easier for packagers to apply in a consistent way.


When do these changes take effect?
----------------------------------

The resulting changes in practice will be applied to new packages and
licenses going forward. It is not necessary to revise existing packages
at this time, although we have provided some guidance for package
maintainers who want to get started. We’re in the process of planning a
path for updating existing packages at a larger scale — stay tuned for
more on that!


Thank you everyone!
-------------------

A huge thanks to some key people who have worked tirelessly to make
this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav
Suchý. Behind the scenes support was also provided by David Levine,
Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable
feedback from Fedora community members in various Fedora forums.

Please have a look at the updated information. If you have questions,
please post them to the Fedora Legal mailing list:

https://lists.fedoraproject.org/archives/list/legal@.../



-- 
Matthew Miller
<mattdm@...>
Fedora Project Leader
_______________________________________________
legal mailing list -- legal@...
To unsubscribe send an email to legal-leave@...
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/legal@...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


legal call at top of the hour

J Lovejoy
 

Hi all,

Just a quick reminder that the SPDX-legal call will be at the top of the hour.

We'll focus on what tasks can be completed for the next release and, if there's time, I have an update on Fedora and SPDX identifiers.


Jilayne


SPDX Spec Version 2.3 Available for Review

Gary O'Neall
 

Greetings all,

 

The SPDX spec version 2.3 is now available for review at https://spdx.github.io/spdx-spec/v2.3-RC1/.

 

A summary of the changes can be found in the SPEC Annex I.

 

If you identify any issues, please submit an issue or pull request in the SPDX spec repository.  See the CONTRIBUTING.md file for details.  You can also submit issues to the SPDX tech mailing list.

 

Please submit any issues or proposed spec changes by end of day August 10.

 

Best regards,

SPDX Tech Team

 

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Re: [spdx-tech] stable spec URLs

J Lovejoy
 

On Jul 26, 2022, at 1:41 AM, Max Mehl <max.mehl@...> wrote:

~ J Lovejoy [2022-07-26 06:00 +0200]:
If I wanted to link to, for example, Annex D, in a way that would remain
stable with subsequent versions of the spec, then I could use the HTML
format, and then the link
https://spdx.github.io/spdx-spec/SPDX-license-expressions/ - and this
would still point to the Annex D on SPDX license expressions even for
version 2.3 of the spec - is that right? (assuming of course that Annex
D doesn't change name such that the link also changes)
Interesting question! I, too, am a bit confused of the various URLs.

Asked the other way round: are there also stable links for older
versions, e.g. a permalink for 2.2 and its clauses/annexes once 2.3
would be released?
Hi Max,

Given the evolution of the SPDX Specification format(s) - that is, it was mainly in .pdf form for most of the past versions, I’d say that if you want to refer to a specific version, I’d use the .pdf link
which may or may not have a linkable table of contents. See https://spdx.dev/specifications/
e.g., for 2.2, you can always use: https://spdx.dev/wp-content/uploads/sites/41/2020/08/SPDX-specification-2-2.pdf

Jilayne


Re: [spdx-tech] stable spec URLs

Max Mehl
 

~ J Lovejoy [2022-07-26 06:00 +0200]:
If I wanted to link to, for example, Annex D, in a way that would remain
stable with subsequent versions of the spec, then I could use the HTML
format, and then the link
https://spdx.github.io/spdx-spec/SPDX-license-expressions/ - and this
would still point to the Annex D on SPDX license expressions even for
version 2.3 of the spec - is that right? (assuming of course that Annex
D doesn't change name such that the link also changes)
Interesting question! I, too, am a bit confused of the various URLs.

Asked the other way round: are there also stable links for older
versions, e.g. a permalink for 2.2 and its clauses/annexes once 2.3
would be released?

Best,
Max

--
Max Mehl - Programme Manager -- Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl -- @mxmehl
The FSFE is a charity that empowers users to control technology


stable spec URLs

J Lovejoy
 

(cross-posting to tech and legal team, as I suspect others may be interested)

Hi SPDX-tech team,

I just wanted to confirm my understanding of the various formats we now have for the SPDX specification and linking to specific sections.

If I wanted to link to, for example, Annex D, in a way that would remain stable with subsequent versions of the spec, then I could use the HTML format, and then the link https://spdx.github.io/spdx-spec/SPDX-license-expressions/ - and this would still point to the Annex D on SPDX license expressions even for version 2.3 of the spec - is that right? (assuming of course that Annex D doesn't change name such that the link also changes)

Thanks!
Jilayne


Re: Commutativity of SPDX expressions

Richard Fontana
 

I feel like what some projects might find useful is something like:

SPDX-License-Identifier-Concluding-What's-Been-Contributed-As-Of-Some-Past-Time:
SPDX-License-Identifier-Of-What's-Been-Contributed-After-That-Past-Time-And-Default-License-of-Future-Contributions:

since these might point to different licenses. The snippet construct
can possibly express this adequately in some cases but I think
reliable identification of a snippet will normally be impractical.

Richard

On Sun, Jul 17, 2022 at 3:18 PM McCoy Smith <mccoy@...> wrote:

At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs outbound, then AND may not be commutative, since the order of listing the licenses may convey information about which license is inbound vs outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point already.

On Jul 17, 2022, at 11:22 AM, Richard Fontana <rfontana@...> wrote:

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard





b


Re: Commutativity of SPDX expressions

Gary O'Neall
 

Thanks Sebastian - since we haven't finished the review of the version 2.3,
I think there is still time.

Best regards,
Gary

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
Sebastian Crane
Sent: Monday, July 18, 2022 9:13 AM
To: Spdx-legal@...
Subject: Re: Commutativity of SPDX expressions

Dear Gary,

I've always assumed the AND and OR operators to be commutative and the
SPDX Java tools take full advantage of the commutative properties when
comparing license expressions.

I would welcome a pull request to Annex D to clarify this since at
least one member of the community found this ambiguous and/or
confusing.
I've made a pull request for this :) Not sure whether it'll make 2.3
though - has
the final draft been released yet?

https://github.com/spdx/spdx-spec/pull/748

Best wishes,

Sebastian



Re: Commutativity of SPDX expressions

Sebastian Crane
 

Dear Gary,

I've always assumed the AND and OR operators to be commutative and
the SPDX Java tools take full advantage of the commutative
properties when comparing license expressions.

I would welcome a pull request to Annex D to clarify this since at
least one member of the community found this ambiguous and/or
confusing.
I've made a pull request for this :) Not sure whether it'll make 2.3
though - has the final draft been released yet?

https://github.com/spdx/spdx-spec/pull/748

Best wishes,

Sebastian


Re: Commutativity of SPDX expressions

Gary O'Neall
 

I've always assumed the AND and OR operators to be commutative and the SPDX Java tools take full advantage of the commutative properties when comparing license expressions.

I would welcome a pull request to Annex D to clarify this since at least one member of the community found this ambiguous and/or confusing.

Gary

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
Richard Fontana
Sent: Sunday, July 17, 2022 2:36 PM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: Commutativity of SPDX expressions

The order of operations is a different issue, I think. I guess the SPDX spec
assumes, as you say, that commutativity of AND and OR is implicit (like
counterpart operations in propositional logic), but this implicit property was
not obvious to one Fedora contributor.

Richard

On Sun, Jul 17, 2022 at 4:08 PM J Lovejoy <opensource@...> wrote:

Hi Richard,

Annex D explains the order of precedence for the operators and use of
parentheses.
https://spdx.github.io/spdx-spec/SPDX-license-expressions/

I admit, I find the use of parentheses easier to understand overall (than
relying on remembering the order of precedence).

I’m not sure it explicitly states that "MIT AND Apache-2.0" is equivalent to
"Apache-2.0 AND MIT” but I think that’s kind of implicit, no?

I also think this entire annex could use a re-write to make it a bit
more user-friendly (on the topic of improving documentation…)

Jilayne

On Jul 17, 2022, at 12:21 PM, Richard Fontana <rfontana@...>
wrote:

I'm working on some draft documentation for Fedora around use of
SPDX expressions in RPM spec file License: fields. I was surprised
to apparently not see anything in the SPDX spec that says that the
AND and OR operators are commutative. I want to assert that the
expression "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND
MIT". Does the SPDX spec actually take no position on this?

Richard








Re: Commutativity of SPDX expressions

Warner Losh
 



On Sun, Jul 17, 2022 at 2:43 PM McCoy Smith <mccoy@...> wrote:
Rather than getting into further debates about what various licenses do and don't require, or for that matter what copyright law does or doesn't require, I guess I'd turn back to the ath5k example.
Is the license designation they used the same as the AND operator in SPDX? I think it is not (or if AND encompasses it, AND may be interpreted too broadly so as to potentially cause confusion or incorrect assumptions about the license state).
Ath5k license designation is here: https://lwn.net/Articles/247806/
Now, people are free to respond back that the ath5k license designation is legally invalid, but I for one will not stand here and have Richard Fontana's legal skills besmirched!

Each of the individual files retains the original copyright and license, as the original author required. You are required to still abide by the terms in those files (but each individual grant is not the sum of the requirements).

The current kernel.org Linux ath5k driver is marked as 'MODULE_LICENSE("Dual BSD/GPL");', The kernel.org version of this driver does not have these changes included. In addition, the OpenBSD folks were none-too-happy with this attempt to strip off the BSD licenses. https://undeadly.org/cgi?action=article&sid=20070829001634 has the details (but Google finds many other instances, I've not chased them all down). LICENSE_MODULE is beyond the scope of SPDX and is up to the Linux Kernel Community what licenses they support and when.

The SPDX matching tool, which implements the SDPX license matching guidelines, would say that there's multiple licenses you must comply with. That means the union of all the licenses which is the meaning of AND in a SPDX-License-Identifier which I believe would be the result for several of the files. I've not run it on the current version of these files, but have obtained that result for other code that has multiple licenses.

I'm not entirely sure, given the contentious history that this makes a good example, though.

Warner
 
> -----Original Message-----
> From: J Lovejoy <opensource@...>
> Sent: Sunday, July 17, 2022 1:18 PM
> To: McCoy Smith <mccoy@...>
> Cc: Richard Fontana <rfontana@...>; SPDX-legal <spdx-
> legal@...>
> Subject: Re: Commutativity of SPDX expressions
>
> Hi McCoy,
>
> I’m wondering if you are trying to adapt SPDX identifiers in a situation not
> anticipated. Consider that aim of an SPDX document (as per the SPDX
> specification, and thus, using SPDX license ids in the various specification
> field, is to communicate licensing, copyright, provenance, etc. information
> for a given bundle of software. For example, I sell you Jilaynes-awesome-
> software-app and provide an SPDX document for that software product. The
> licensing info in this context would be presubaly what I think you are
> referring to as the “outbound” license - that is the license under which the
> software is used by the recipient.
>
> Let’s say, Jilaynes-awesome-software-app includes some open source
> software under various open source licenses, say, MIT and Apache-2.0, and I
> also added some of my own (new) code under BSD-3-Clause, that all of this
> can be reflected in the appropriate license fields at the package, file, and/or
> snippet level.
>
> I think of “inbound”, in relation to open source software, as usually referring
> to the license under which contributions are provided to the project. But I
> think you might be meaning “inbound” in  relation to Jilayne’s-awesome-
> software-app - that is, the open source software that I incorporate into my
> app under MIT and Apache-2.0. Is that right?
>
> Thanks,
> Jilayne
>
> > On Jul 17, 2022, at 1:18 PM, McCoy Smith <mccoy@...> wrote:
> >
> > At the risk of sounding like I’m hijacking this to re-raise my prior issue:
> > If AND is the operator to be used when having different inbound vs
> outbound, then AND may not be commutative, since the order of listing the
> licenses may convey information about which license is inbound vs
> outbound, and (maybe) which license applies to different parts of the code.
> > Which militates to me toward a new expression, but I’ve made that point
> already.
> >
> >> On Jul 17, 2022, at 11:22 AM, Richard Fontana <rfontana@...>
> wrote:
> >>
> >> I'm working on some draft documentation for Fedora around use of
> >> SPDX expressions in RPM spec file License: fields. I was surprised to
> >> apparently not see anything in the SPDX spec that says that the AND
> >> and OR operators are commutative. I want to assert that the
> >> expression "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND
> >> MIT". Does the SPDX spec actually take no position on this?
> >>
> >> Richard
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >








Re: Commutativity of SPDX expressions

Richard Fontana
 

The order of operations is a different issue, I think. I guess the
SPDX spec assumes, as you say, that commutativity of AND and OR is
implicit (like counterpart operations in propositional logic), but
this implicit property was not obvious to one Fedora contributor.

Richard

On Sun, Jul 17, 2022 at 4:08 PM J Lovejoy <opensource@...> wrote:

Hi Richard,

Annex D explains the order of precedence for the operators and use of parentheses. https://spdx.github.io/spdx-spec/SPDX-license-expressions/

I admit, I find the use of parentheses easier to understand overall (than relying on remembering the order of precedence).

I’m not sure it explicitly states that "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT” but I think that’s kind of implicit, no?

I also think this entire annex could use a re-write to make it a bit more user-friendly (on the topic of improving documentation…)

Jilayne

On Jul 17, 2022, at 12:21 PM, Richard Fontana <rfontana@...> wrote:

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard






Re: Commutativity of SPDX expressions

McCoy Smith
 

Rather than getting into further debates about what various licenses do and don't require, or for that matter what copyright law does or doesn't require, I guess I'd turn back to the ath5k example.
Is the license designation they used the same as the AND operator in SPDX? I think it is not (or if AND encompasses it, AND may be interpreted too broadly so as to potentially cause confusion or incorrect assumptions about the license state).
Ath5k license designation is here: https://lwn.net/Articles/247806/
Now, people are free to respond back that the ath5k license designation is legally invalid, but I for one will not stand here and have Richard Fontana's legal skills besmirched!

-----Original Message-----
From: J Lovejoy <opensource@...>
Sent: Sunday, July 17, 2022 1:18 PM
To: McCoy Smith <mccoy@...>
Cc: Richard Fontana <rfontana@...>; SPDX-legal <spdx-
legal@...>
Subject: Re: Commutativity of SPDX expressions

Hi McCoy,

I’m wondering if you are trying to adapt SPDX identifiers in a situation not
anticipated. Consider that aim of an SPDX document (as per the SPDX
specification, and thus, using SPDX license ids in the various specification
field, is to communicate licensing, copyright, provenance, etc. information
for a given bundle of software. For example, I sell you Jilaynes-awesome-
software-app and provide an SPDX document for that software product. The
licensing info in this context would be presubaly what I think you are
referring to as the “outbound” license - that is the license under which the
software is used by the recipient.

Let’s say, Jilaynes-awesome-software-app includes some open source
software under various open source licenses, say, MIT and Apache-2.0, and I
also added some of my own (new) code under BSD-3-Clause, that all of this
can be reflected in the appropriate license fields at the package, file, and/or
snippet level.

I think of “inbound”, in relation to open source software, as usually referring
to the license under which contributions are provided to the project. But I
think you might be meaning “inbound” in relation to Jilayne’s-awesome-
software-app - that is, the open source software that I incorporate into my
app under MIT and Apache-2.0. Is that right?

Thanks,
Jilayne

On Jul 17, 2022, at 1:18 PM, McCoy Smith <mccoy@...> wrote:

At the risk of sounding like I’m hijacking this to re-raise my prior issue:
If AND is the operator to be used when having different inbound vs
outbound, then AND may not be commutative, since the order of listing the
licenses may convey information about which license is inbound vs
outbound, and (maybe) which license applies to different parts of the code.
Which militates to me toward a new expression, but I’ve made that point
already.

On Jul 17, 2022, at 11:22 AM, Richard Fontana <rfontana@...>
wrote:

I'm working on some draft documentation for Fedora around use of
SPDX expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the
expression "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND
MIT". Does the SPDX spec actually take no position on this?

Richard








81 - 100 of 3280