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

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

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

-----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

the final draft been released yet?

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

Best wishes,

Sebastian

-----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

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

-----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