Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add appendix describing SPDX Listed License fields #46

Closed
goneall opened this issue Oct 13, 2017 · 38 comments
Closed

Add appendix describing SPDX Listed License fields #46

goneall opened this issue Oct 13, 2017 · 38 comments
Labels
help wanted profile: licensing Licensing Profile and related matters tech team review
Milestone

Comments

@goneall
Copy link
Member

goneall commented Oct 13, 2017

There are several properties used in the SPDX Listed Licenses which are not documented in the specification.

They are currently documented in the RDFa terms used section of the Accessing SPDX Licenses document. There are also references to these fields in the License XML Elements and Attributes document.

Missing elements include:

  • isOsiApproved
  • isFsfFree (recently added)
  • standardLicenseHeader
  • example (used in Exceptions)

Propose we add another appendix Listed License Information which details out all the fields including those in common with extracted license text (e.g. licenseId, etc.).

@robinagandhi
Copy link

Would it be better to name it as isFSFIdentified or isFSFApproved. The currently suggested name, without context may give a first impression that the software is free of any FSF approved licenses!

@wking
Copy link
Contributor

wking commented Oct 13, 2017

Having an inline table of licenses is fine (although I'd prefer it be autogenerated, see the implementation in #10). However, there's lots of important information in the license repo that is not going to end up in this spec (e.g. optional and alternate markup). I'd rather have license-list-XML document itself (spdx/license-list-XML#391) and then have this spec link to a pretty landing page for a specific version of license-list-XML.

Cross-linking the list threads.

@goneall
Copy link
Member Author

goneall commented Oct 13, 2017

@wking I tend to separate out the internal fields used by the legal team in the creating and maintenance of the licenses from the external fields used by tools. The latter are properties used in the JSON and RDF formats in the license-list-data repository. I would suggest the latter be standardized and documented since changes would be disruptive to tool implementers. The former can be more flexible and should be described in the XML schema document.

@goneall
Copy link
Member Author

goneall commented Oct 13, 2017

@robinagandhi Good point on the possible (miss)interpretation. The definition of the property would be that the license is designated as "Free" by the FSF (see https://www.gnu.org/licenses/license-list.html).

@jlovejoy @kestewart Thoughts?

@goneall
Copy link
Member Author

goneall commented Oct 13, 2017

In reviewing https://www.gnu.org/licenses/license-list.html, the FSF specifies "Free and Compatible with GPL", "Free and Incompatible with GPL" and "non-free". Do we need to capture all of these states? If so, do we want a second boolean ("FsfGplCompatible")? We could always implement a second boolean in the future.

@jlovejoy @kestewart - what do you think?

@wking
Copy link
Contributor

wking commented Oct 13, 2017 via email

@goneall
Copy link
Member Author

goneall commented Oct 13, 2017

That's good. On this front, I would prefer if none of the FSF/OSI
material was maintained by the legal team. It should instead be
maintained by the FSF and OSI teams. I'm ok with the tech team
caching license ID matches in license-list-XML or downstream in
license-list-data for now, although with automated matching
(spdx/license-list-XML#418) I'd rather move
even that out of license-list-XML.

Agree in principle, but from a practical point of view we may need to maintain the FSF information in the XML format until the FSF implements some sort of supported API. I just added an issue to the tools to automatically generate the OSI information from their API's.

I'm not sure the XML format should be purely internal. If that's the
format we find most convenient to maintain our license information,
wouldn't it also be a convenient format for external authors
(e.g. defining their own extension licenses?).

I think we can eventually make the XML external, but it would require more review and will likely slow down the implementation of the internally used XML format. We decided a few months back to keep it internal for the first release of the license XML and revisit the external discussion later. Suggest keeping this a separate decision from documenting the fields in the external license list data.

As far as documentation goes, I'm in favor of documenting all of our
formats. I'm just not sure a spec appendix is the best place to do
it.

I don't feel strongly that it needs to be an appendix. I do feel it needs to be documented in a format and location that is considered the source of record. It also needs to be easy to find.

@wking
Copy link
Contributor

wking commented Oct 13, 2017 via email

@bradleeedmondson
Copy link

@robinagandhi:

Would it be better to name it as isFSFIdentified or isFSFApproved. The currently suggested name, without context may give a first impression that the software is free of any FSF approved licenses!

@goneall:

Good point on the possible (miss)interpretation. The definition of the property would be that the license is designated as "Free" by the FSF (see https://www.gnu.org/licenses/license-list.html).

With respect to "isFsfFree" one option floated on the last legal call that might help this is to call it "isFsfLibre." That helps avoid the possibility of misinterpretation, at least in English. (This danger is also somewhat, although not fully, mitigated by taking note of the context of the property -- applying to a license rather than a package/file.)

IIRC, on that same call (and someone please correct me if I'm wrong) FSF's John Sullivan said that (1) they are not too concerned about the name of the internal identifier SPDX chooses to use, but that (2) FSF views "FSF Approved" and "Is FSF Free/Libre" as different categories (which I took to mean, essentially, that FSF maintains at least two different "approval" lists) -- and that their concern was in SDPX conflating the two (or leading SPDX users to conflate them). I believe what SPDX intends to capture with this property is "Is FSF Free/Libre,"so if that's correct we would probably want to call it something with "Libre" in the name.

@robinagandhi
Copy link

@bradleeedmondson and @goneall: In our interviews with many companies, we found that in internal practices, SPDX may not be adopted entirely but the fields do influence information recorded in internal databases. That said, it is important to not assume that context will always follow the field. So I appreciate the follow up on this topic. I think that isFSFLibre suggested by @bradleeedmondson will be a better alternative to the current name.

@goneall
Copy link
Member Author

goneall commented Oct 16, 2017

+1 on FsfLibre proposal

@lofidevops
Copy link

Will there be advice given for other parties to indicate that they "approve" a license (without adding overhead on your side)? I'm thinking primarily of Debian Free Software Guidelines. Other (smaller) examples include Free Cultural Works or Copyfree.

@wking
Copy link
Contributor

wking commented Oct 25, 2017 via email

@lofidevops
Copy link

I'll take that as a definitive answer! I've pinged the debian-legal mailing list for a machine-readable version (if it exists). However, reading those last two links I was reminded:

It is possible to have a package containing software under a "free" license with some other aspect that makes it non-free. Sometimes, debian-legal comments on a license in abstract, not applied to any particular software. While these discussion can suggest possible problems, often no firm answers can be reached until some specific software is examined.

...which suggests that "DFSG approved" may not make sense / be helpful as a license flag. I'll update with any definitive response from the mailing list.

@wking
Copy link
Contributor

wking commented Oct 26, 2017

...which suggests that "DFSG approved" may not make sense / be helpful as a license flag. I'll update with any definitive response from the mailing list.

So licenses can be tagged "DFSG (in)compatible" with a note explaining that using DFSG licenses is necessary, but not sufficient, to get a DFSG-compatible package. I still think an API for license rulings makes sense and would be helpful.

@goneall
Copy link
Member Author

goneall commented Oct 26, 2017

Completely agree on having an API.

I would like to propose an additional approach.

If a 3rd party provided a machine readable list or map which allows us to map the SPDX license ID to their license list. For example, a simple JSON file with an array of supported SPDX license ID's.

Reason for this approach: Some organizations to not maintain the license texts for all licenses. Some are just URL references to other license sites. For example, we ran into this for several Free Software Foundation referenced licenses. In this situation, we should allow the 3rd party to express what SPDX license ID's match those references.

If a 3rd party only provides licenses texts, we could use the algorithm @wking suggested above.

If a 3rd party only provides a map of SPDX license ID's, we could use that.

If a 3rd party provides both, we could use the list/map and run a verification against the license text.

@goneall
Copy link
Member Author

goneall commented Oct 26, 2017

Note that we could add this to the spec, but any updates to the information provided on the SPDX license list HTML pages (https://spdx.org/licenses) would be decided by the legal team. If an organization would like to be added to the index page or the individual license pages, they should post the request to the legal team mailing list [email protected]

@wking
Copy link
Contributor

wking commented Oct 26, 2017 via email

@goneall
Copy link
Member Author

goneall commented Oct 26, 2017

I don't think we want to encourage this use case ;)

Good point and I agree. I think the ideal situation is they provide both so that we could verify.

c. A link to the license text they considered with the understanding
that we can, at our discretion, use any text ever retrieved from
that location when determining the matching SPDX ID

I would prefer not to take on the responsibility of identifying the mapping. Suggest we only allow:

a. The license text they considered,
b. The SPDX ID they're delegating to

@wking
Copy link
Contributor

wking commented Oct 26, 2017 via email

@lofidevops
Copy link

@wking I've separated out the Debian flag as #48 , including comments from you and debian-legal

@sharpaper
Copy link

Another relevant thread.

@kestewart
Copy link
Contributor

This looks like something we can put into 2.2, (after specifics are figured out). Needs tech team discussion.

@davidhedlund
Copy link

@goneall

In reviewing https://www.gnu.org/licenses/license-list.html, the FSF specifies "Free and Compatible with GPL", "Free and Incompatible with GPL" and "non-free". Do we need to capture all of these states? If so, do we want a second boolean ("FsfGplCompatible")? We could always implement a second boolean in the future.

The Code for the left border at https://www.gnu.org/licenses/license-list.html defines five properties:

  • Free licenses, compatible with the GNU GPL
  • Free licenses, compatible with the FDL
  • Free licenses, incompatible with the GNU GPL and FDL
  • Nonfree licenses
  • Licenses for works stating a viewpoint

It would be useful for the FSF if you added them.

PS. I'm working as an intern with the FSF tech team at this writing and writing a script to retrieve licenses data from https://raw.githubusercontent.com/spdx/license-list-data/master/json/licenses.json to build license pages for the FSF project https://directory.fsf.org/wiki/

@wking
Copy link
Contributor

wking commented Aug 17, 2018

The Code for the left border at https://www.gnu.org/licenses/license-list.html defines five properties...

You can get these now from https://github.com/wking/fsf-api. But having the FSF pulling data about its own opinions from someone else seems... inefficient ;), Any chance of me handing that over so the FSF can provide its own API? There were some noises in that direction in wking/fsf-api#18.

@goneall
Copy link
Member Author

goneall commented Aug 17, 2018

@davidhedlund Thanks for the feedback on the fields. I think I'll queue this up for discussion on the legal and tech teams for inclusion in the spec if there are no objections.

@goneall
Copy link
Member Author

goneall commented Aug 17, 2018

Any chance of me handing that over so the FSF can provide its own API?

I agree with @wking that this would be a valuable approach. Ideally, the FSF would own the source data and API used to generate their human readable web pages and we could use the same source data to populate the SPDX data. This would be much better than our current approach of parsing / scraping the FSF HTML to generate the data.

@jlovejoy
Copy link
Member

@davidhedlund as to the question about the FSF categories of: "Free and Compatible with GPL" and "Free and Incompatible with GPL" - we just want to capture the ones that are considered free. We don't need/want to get into the in/compatible level of detail.
The licenses considered free by the FSF are marked as Y on the SPDX License List. I think it'd be fine to also include the licenses considered non-free as N and then anything blank would indicate a license not considered by the FSF. But first priority is to make sure we have all the free/libre licenses captured correctly!

@kestewart
Copy link
Contributor

From discussion on call, looking for volunteer to generate pull request. Usual suspects oversubscribed, so moving this to 3.0 for now, and revisiting.

@goneall
Copy link
Member Author

goneall commented Sep 6, 2021

Add obsoletedBys per request spdx/LicenseListPublisher#12

@davidhedlund
Copy link

Add obsoletedBys per request spdx/LicenseListPublisher#12

Thank you.

@davidhedlund
Copy link

@jlovejoy
Copy link
Member

@goneall - is the name of this issue right?
the SPDX Licnese List fields are documented in the repo, I don't think they should be an appendix to the spec

@goneall
Copy link
Member Author

goneall commented Sep 15, 2021

@jlovejoy I have a different opinion on documenting the fields in the spec.

I do want to clarify one thing, however. I'm only suggesting we document the fields that are published on the website and in the license-list-data repo. I'm NOT suggesting we document fields used internally by the legal team in the spec. Those should only be documented in the license-list-XML repo.

Since these fields are being used programmatically in applications, they should be documented in the spec so everyone knows where to go for the field information. They also need to be reviewed and released with version control that comes with the spec.
It would also allow these fields to be included in the ISO specification for standardization.

Be happy to discuss on a legal team call or tech team call if you like.

@goneall
Copy link
Member Author

goneall commented Dec 19, 2022

@zvr @swinslow Since you're working on the SPDX 3.0 license profile, do you have any opinions on this issue? Not having this resolved is causing other issues (as you can see in the references above).

@swinslow
Copy link
Member

@goneall As part of the Licensing profile, I am working on documenting the license model generally in line with the draft document that you and I (together with some of the GSoC students) had been working on here in 2020.

I haven't reviewed the linked issues above, but I'll aim to take a look at those together with the draft writeup that I'm working on.

@goneall
Copy link
Member Author

goneall commented Apr 4, 2024

These have now been added to the spec in 3.0 - thanks to @swinslow

@goneall goneall closed this as completed Apr 4, 2024
@davidhedlund
Copy link

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted profile: licensing Licensing Profile and related matters tech team review
Projects
None yet
Development

No branches or pull requests

10 participants