1. Spdx-legal@lists.spdx.org
  2. Messages
   Date   
Re: public domain dedications proliferation

Michael Dolan
 

In addition to Steve's thoughts... I will respond quickly as that was the request ... and likely miss issues. My only additional though is could we add a generic public domain license reference to the license list and then keep a list of discovered uses in the metadata? It would break from the traditional identifier = 1 specific license text model, but technically we do allow for variations in the headers already. 

A) Full Name: Public Domain Generic Dedication
B) Identifier: PDGD
C) Other web pages for this license: [insert example URLs where these generic dedications show up]
D) Notes: Public domain dedications occur in varying texts and contexts. The PDGD license identifier encompasses all texts dedicating unlicensed works to the public domain.
E/F) Yes if on either list... unlikely... but possible
G) Full text would be "Public domain" - which seems to encompass all the examples here. There may be other public domain dedications/declarations we could include. 
 
I do realize its odd to suggest adding a (non-license) public domain dedication to the License List - but... hey, you asked for fast :-)

-- Mike



On Mon, Aug 15, 2022 at 8:28 PM Steve Winslow <swinslow@...> wrote:
Hi Jilayne, since you asked for input ASAP, here are a few immediate gut reactions  :)

I think getting the data of seeing a bunch of different ways that people said "this code is released into the public domain" is _slightly_ useful, but not very useful. My guess is that there's a ton of variations that are substantively saying the same thing but doing so in a way that would be extremely difficult to meaningfully capture into a few categories with regexs / pattern matching.

If the goal is really to find one or a few different regular-expression-matchable phrases that would go on the license list in its current form and format, then maybe that would be helpful data. But I guess I'm skeptical that we would find those patterns in a way that fits the current approach to license IDs on the license list, without ending up with a hundred variations of basically the same thing.

Maybe I'm jumping ahead to "what are the options?" before getting the data, but it seems to me like there are basically 4 options for whether and how to capture public domain statements:

1. No change: Don't add "this is in the public domain" statements to the license list. People can use LicenseRef's if they want.
Pro: Maintains the current approach that the License List is for licenses with specific text.
Con: Doesn't solve the problem people are having, with wanting to represent public domain statements generally with a common identifier.

2. Add a category ID to the spec: Alongside NONE and NOASSERTION as values defined in the SPDX spec, add PUBLIC-DOMAIN as another option defined in the spec rather than on the license list. Unlike NONE and NOASSERTION, PUBLIC-DOMAIN would presumably be useable in complex expressions (e.g. MIT AND PUBLIC-DOMAIN).
Pro: Provides a general identifier for public domain statements. Also maintains the current approach that the License List is for licenses with specific text.
Con: We're frankly too late to get this in as a substantive change for the SPDX 2.3 spec.

3. Add a category ID to the license list: Rather than changing the spec, add a category ID for "Public-Domain" (or similar) to the License List. Modify the license list schema somehow to indicate that this ID is meant to represent the collection of texts stating that a work is in the public domain, rather than one specific text.
Pro: Wouldn't be tied to a change to the spec. Would probably represent the way that most human users tend to think about public domain statements.
Con: Breaks expectations about all other License List entries, that they are tied to a particular text. Might also have implications for the SPDX spec that aren't coming to mind at the moment.

4. Add each statement individually: Add Public-Domain-1, Public-Domain-2, ... to the License List as separate entries, to capture every non-matching representation that we run into to say "this is in the public domain".
Pro: Maintains the current approach that the License List is for licenses with specific text.
Con: Get ready for 700 new Public Domain entries on the license list  :)  Probably becomes unwieldy for humans to meaningfully make use of this.

Definitely open to other options, but these are the ones that come to mind offhand. (And the above is intentionally ignoring public domain dedications that really do have a set standard text, such as CC-PDDC.)

Personally, if we weren't about to have SPDX 2.3 released imminently, I'd probably lean towards option 2. Given that it is about to be released, I could be persuaded to consider option 3, though I suspect we would need significant input from the tooling community as to whether this breaks too many current expectations on their side.

Steve

On Mon, Aug 15, 2022 at 7:15 PM J Lovejoy <opensource@...> wrote:
Hi SPDX-legal,

I have raised this a couple times in the past few months or so, but now that it is more of a "ripe" topic, I wanted to get some input on preliminary ideas:

Background:
Fedora has now officially adopted the use of SPDX ids in packages meta data (specifically, the license field of the package spec file). Due to Fedora historically using "category" short names for groups of similar licenses, we suspect there may be a number of additions to the SPDX License List needed. 

Public domain category:
Specifically, Fedora has used "public domain" for any public domain dedication, without capturing the exact text. For Fedora package maintainers who are keen to update the license info for their packages, we have given this interim advice:
https://docs.fedoraproject.org/en-US/legal/license-field/#_public_domain
and
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_callaway_short_name_categories (see section on "public domain")

SPDX approach:
The SPDX License List has always operated from the principle that an SPDX license id represents a specific, identifiable license/set of text. This is critical as part of our project goal of being both human and machine-readable.

However, if it turns out that there are a large number of slight variations of text that mean the same thing (e.g., a simply one line statement of public domain dedication), then perhaps SPDX might consider a slightly different approach?

But, in order to even consider this, we'd need data.

Idea for going forward:
As Fedora package maintainers find these texts that had been marked generically as "public domain" - what if we asked them to copy the actual text of what they found and maybe a link to where they found it (or some other such pointer) in a simply formatted file in the Fedora license-list-data repo?
See https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/54

This would be at least a beginning of collecting this data that SPDX-legal could then review in a more bulk fashion in order to consider the above potential approach.

If so, what other info besides the text itself should be collected and how can it be most easily formatted to enable easy consumption later?

For example, it could be something like this:

===
package = Foo
text = This is released into the public domain.
source = <url to file or other such pointer>
===

I wouldn't want to be more than a few pieces of information. There is also always the ability to search on the short name "public domain" or the interiem SPDX id of "LicenseRef-Fedora-Public-Domain", but might as well start collecting info if package maintainers are looking as well.

Thoughts? (need input ASAP :)

thanks,
Jilayne

Re: public domain dedications proliferation

Steve Winslow
 

Hi Jilayne, since you asked for input ASAP, here are a few immediate gut reactions  :)

I think getting the data of seeing a bunch of different ways that people said "this code is released into the public domain" is _slightly_ useful, but not very useful. My guess is that there's a ton of variations that are substantively saying the same thing but doing so in a way that would be extremely difficult to meaningfully capture into a few categories with regexs / pattern matching.

If the goal is really to find one or a few different regular-expression-matchable phrases that would go on the license list in its current form and format, then maybe that would be helpful data. But I guess I'm skeptical that we would find those patterns in a way that fits the current approach to license IDs on the license list, without ending up with a hundred variations of basically the same thing.

Maybe I'm jumping ahead to "what are the options?" before getting the data, but it seems to me like there are basically 4 options for whether and how to capture public domain statements:

1. No change: Don't add "this is in the public domain" statements to the license list. People can use LicenseRef's if they want.
Pro: Maintains the current approach that the License List is for licenses with specific text.
Con: Doesn't solve the problem people are having, with wanting to represent public domain statements generally with a common identifier.

2. Add a category ID to the spec: Alongside NONE and NOASSERTION as values defined in the SPDX spec, add PUBLIC-DOMAIN as another option defined in the spec rather than on the license list. Unlike NONE and NOASSERTION, PUBLIC-DOMAIN would presumably be useable in complex expressions (e.g. MIT AND PUBLIC-DOMAIN).
Pro: Provides a general identifier for public domain statements. Also maintains the current approach that the License List is for licenses with specific text.
Con: We're frankly too late to get this in as a substantive change for the SPDX 2.3 spec.

3. Add a category ID to the license list: Rather than changing the spec, add a category ID for "Public-Domain" (or similar) to the License List. Modify the license list schema somehow to indicate that this ID is meant to represent the collection of texts stating that a work is in the public domain, rather than one specific text.
Pro: Wouldn't be tied to a change to the spec. Would probably represent the way that most human users tend to think about public domain statements.
Con: Breaks expectations about all other License List entries, that they are tied to a particular text. Might also have implications for the SPDX spec that aren't coming to mind at the moment.

4. Add each statement individually: Add Public-Domain-1, Public-Domain-2, ... to the License List as separate entries, to capture every non-matching representation that we run into to say "this is in the public domain".
Pro: Maintains the current approach that the License List is for licenses with specific text.
Con: Get ready for 700 new Public Domain entries on the license list  :)  Probably becomes unwieldy for humans to meaningfully make use of this.

Definitely open to other options, but these are the ones that come to mind offhand. (And the above is intentionally ignoring public domain dedications that really do have a set standard text, such as CC-PDDC.)

Personally, if we weren't about to have SPDX 2.3 released imminently, I'd probably lean towards option 2. Given that it is about to be released, I could be persuaded to consider option 3, though I suspect we would need significant input from the tooling community as to whether this breaks too many current expectations on their side.

Steve

On Mon, Aug 15, 2022 at 7:15 PM J Lovejoy <opensource@...> wrote:
Hi SPDX-legal,

I have raised this a couple times in the past few months or so, but now that it is more of a "ripe" topic, I wanted to get some input on preliminary ideas:

Background:
Fedora has now officially adopted the use of SPDX ids in packages meta data (specifically, the license field of the package spec file). Due to Fedora historically using "category" short names for groups of similar licenses, we suspect there may be a number of additions to the SPDX License List needed. 

Public domain category:
Specifically, Fedora has used "public domain" for any public domain dedication, without capturing the exact text. For Fedora package maintainers who are keen to update the license info for their packages, we have given this interim advice:
https://docs.fedoraproject.org/en-US/legal/license-field/#_public_domain
and
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_callaway_short_name_categories (see section on "public domain")

SPDX approach:
The SPDX License List has always operated from the principle that an SPDX license id represents a specific, identifiable license/set of text. This is critical as part of our project goal of being both human and machine-readable.

However, if it turns out that there are a large number of slight variations of text that mean the same thing (e.g., a simply one line statement of public domain dedication), then perhaps SPDX might consider a slightly different approach?

But, in order to even consider this, we'd need data.

Idea for going forward:
As Fedora package maintainers find these texts that had been marked generically as "public domain" - what if we asked them to copy the actual text of what they found and maybe a link to where they found it (or some other such pointer) in a simply formatted file in the Fedora license-list-data repo?
See https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/54

This would be at least a beginning of collecting this data that SPDX-legal could then review in a more bulk fashion in order to consider the above potential approach.

If so, what other info besides the text itself should be collected and how can it be most easily formatted to enable easy consumption later?

For example, it could be something like this:

===
package = Foo
text = This is released into the public domain.
source = <url to file or other such pointer>
===

I wouldn't want to be more than a few pieces of information. There is also always the ability to search on the short name "public domain" or the interiem SPDX id of "LicenseRef-Fedora-Public-Domain", but might as well start collecting info if package maintainers are looking as well.

Thoughts? (need input ASAP :)

thanks,
Jilayne

public domain dedications proliferation

J Lovejoy
 

Hi SPDX-legal,

I have raised this a couple times in the past few months or so, but now that it is more of a "ripe" topic, I wanted to get some input on preliminary ideas:

Background:
Fedora has now officially adopted the use of SPDX ids in packages meta data (specifically, the license field of the package spec file). Due to Fedora historically using "category" short names for groups of similar licenses, we suspect there may be a number of additions to the SPDX License List needed. 

Public domain category:
Specifically, Fedora has used "public domain" for any public domain dedication, without capturing the exact text. For Fedora package maintainers who are keen to update the license info for their packages, we have given this interim advice:
https://docs.fedoraproject.org/en-US/legal/license-field/#_public_domain
and
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_callaway_short_name_categories (see section on "public domain")

SPDX approach:
The SPDX License List has always operated from the principle that an SPDX license id represents a specific, identifiable license/set of text. This is critical as part of our project goal of being both human and machine-readable.

However, if it turns out that there are a large number of slight variations of text that mean the same thing (e.g., a simply one line statement of public domain dedication), then perhaps SPDX might consider a slightly different approach?

But, in order to even consider this, we'd need data.

Idea for going forward:
As Fedora package maintainers find these texts that had been marked generically as "public domain" - what if we asked them to copy the actual text of what they found and maybe a link to where they found it (or some other such pointer) in a simply formatted file in the Fedora license-list-data repo?
See https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/54

This would be at least a beginning of collecting this data that SPDX-legal could then review in a more bulk fashion in order to consider the above potential approach.

If so, what other info besides the text itself should be collected and how can it be most easily formatted to enable easy consumption later?

For example, it could be something like this:

===
package = Foo
text = This is released into the public domain.
source = <url to file or other such pointer>
===

I wouldn't want to be more than a few pieces of information. There is also always the ability to search on the short name "public domain" or the interiem SPDX id of "LicenseRef-Fedora-Public-Domain", but might as well start collecting info if package maintainers are looking as well.

Thoughts? (need input ASAP :)

thanks,
Jilayne

3.18 License List release

Steve Winslow
 

Hello all,

The version 3.18 release of the license list is now tagged and live at https://spdx.org/licenses.

10 new licenses / exceptions were added to the list:
  • CC-BY-3.0-IGO
  • GStreamer-exception-2005
  • GStreamer-exception-2008
  • LZMA-SDK-9.11-to-9.20
  • LZMA-SDK-9.22
  • MS-LPL
  • Minpack
  • mpi-permissive
  • NICTA-1.0
  • Python-2.0.1
The release also included updates to various documentation, adjustments to markup for various licenses and other minor changes.

More details can be found in the release notes at https://github.com/spdx/license-list-XML/releases/tag/v3.18.

Thank you as always to the participants in the SPDX Legal community and license request submitters who contributed to this release.

Steve
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
141 - 160 of 3344