Define a "DFSG compatible" flag #876
Comments
|
Have sent email to pabs to see what his thoughts are on the topic, and call his attention to the request. If there's support on the Debian side to have the DFSG licenses listed here, will see if we can work up a proposal and get their agreement. After all, they already basically support the use of SPDX license identifiers in DEP5 (aka debian/copyright) files so matching should be easier. |
|
I find it sensible for Debian to maintain a machine-readable list of licenses Debian consider compliant with Debian Free Software Guidelines. I find it less useful for SPDX to host such a list, because SPDX is not authoritative on deciding what goes into that list. I believe others have raised similar concerns for the isFsfLibre tag on the SPDX mailinglist. |
|
On Fri, Oct 27, 2017 at 09:17:46PM -0700, Jonas Smedegaard wrote:
I find it sensible for Debian to maintain a machine-readable list of
licenses Debian consider compliant with Debian Free Software
Guidelines. I find it less useful for SPDX to host such a list,
because SPDX is not authoritative on deciding what goes into that
list.
I agree with this, although I don't have a problem with the SPDX
providing a non-canonical copy of the Debian metadata as a
convenience. So SPDX says “we assert that the the Debian ID for this
license is ${DEBIAN_ID} and the Debian metadata is
${DEBIAN_METADATA}”. Folks that aren't comfortable trusting the SPDX
assertions would be free to hit the Debian API directly to get the
information straight from them.
And because there is no canonical provider of ID mapping information
having each party provide the license text and/or template would allow
consumers to verify asserted ID matching on their own as well
(spdx/license-list-XML#418).
|
|
Hi @jonassmedegaard. The isFsfLibre tag is something that the FSF is interested that SPDX support, to give their Free/Libre supporters equal visibility with OSI licenses. pabs came back as neutral to the idea of about isDFSGcompatible. So if you want to host an API in Debian that's cool, we can look at pulling it, as we're now doing with OSI's. @wking Debian ids are very close to SPDX ids [1]. We went through an exercise of reconciling the two lists (and changing several of the SPDX identifiers to match the Debian ones) about 4 years ago. For the canonical text for the licenses, Debian refers to the SPDX list. [2] More information on compatabiity between the two can be found in the debian/copyright page [3] and links from there. [1] "For SPDX compatibility, versions with trailing dot-zeroes are considered to be equivalent to versions without (e.g., “2.0.0” is considered equal to “2.0” and “2”)." |
|
This is probably more a license list item. |
|
This is an older issue that had been in the spdx-spec repo. The tech team asked to transfer this over to license-list-XML for the legal team to consider. Speaking just for myself, I don't know that the SPDX legal team currently has bandwidth to prioritize going through the existing license set to match up against the DFSG list. If others in the community have an interest in doing so, and in maintaining it as additional licenses are added to either list, I wouldn't be opposed. As @kestewart noted in #876 (comment) this might be more feasible if there were an API from Debian where the SPDX license list could query for Debian's determinations. But manually recreating + matching and maintaining over time might not be a priority for the volunteers in the legal team community. |
|
I'm currently helping @uniqx move F-Droid license approval completely over to trusted orgs, and SPDX provides a great way to do that, with the FSF- and OSI-approved API. DFSG would also be great to have on SPDX. I'm also a Debian developer, so happy to help in that realm. @jonassmedegaard I agree that SPDX should not be the canonical location for the DFSG approved license list, but SPDX should provide that list in its API, since it is rapidly becoming the central repo of info like that. So we need to figure out where Debian should provide that list. The are two such lists that I know about:
I think in Debian we should push more for using SPDX license tags for any license in debian/copyright that is known to SPDX. There is agreement in Debian that this should be done: FYI, my comment is building upon https://github.com/spdx/license-list-data/issues/53#issuecomment-538644754 |
These licenses were already in our repo. The are not FSF- or OSI-approved, but they are included in Debian. So for now at least, we should maintain them in our list until we have a clearer picture of how we should make the list of licenses we support. * fdroidserver!682 * spdx/license-list-XML#876 * Beerware in Debian: https://metadata.ftp-master.debian.org/changelogs//main/libm/libmd/libmd_1.0.1-3_copyright * XSkat in Debian: https://metadata.ftp-master.debian.org/changelogs//main/x/xskat/xskat_4.0-7_copyright
|
as there has been no more movement on this, I think we can close? |
|
Please don't drop this - it is a great idea. I am sorry if my remark came across as being against such tag - I merely wanted to emphasize that Debian is canonical on what Debian decides, and it seems there was no need to worry on that. What do folks here think is needed at the Debian side of things to be usable for SPDX? Are those existing lists enough for SPDX to work with for now? What is missing to further progress on getting an isDfsgCompatibe tag? |
|
I think what is missing is exactly what @jonassmedegaard specified [amended]:
The SPDX project cannot be scraping a web page published by Debian, read text targeted to humans ("Apache license"), follow links to other pages (not license texts), and then identify which SPDX License Identifier each entry is about. So, the idea is great and we are all for it, but unless upstream (the Debian project) actually provides the data, it makes no sense for us to have an open ticket. I am confident that, if upstream data materializes, we will learn about it and create a new ticket for integrating them immediately. |
|
In which machine-readable formats do OSI and FSF provide their canonical data? I am already aware that ideal format is some RDF serialization as used by SPDX itself - question here is what is the minimally required for SPDX to consume Debian canonical information, which I assume should be no more strict than for OSI and FSF. |
|
I'm a Debian Developer also and I think we can get this into a single JSON file
up on a Debian website. I'm planning on working on it, unless Jonas or someone
else wants to take it on.
The data that SPDX needs is available in a machine readable format, just not in
one single, standard file. With the debian/copyright standardization, it is
pretty easy to get the list of licenses included in Debian/main, but it means
reading the debian/copyright for every package in Debian. That can be done as a
cron job which then outputs a single JSON file. My goal is to get that single
JSON file up on debian.org in a standard path for anyone to consume.
Here is an example file:
*
https://metadata.ftp-master.debian.org/changelogs//main/c/cmake/cmake_3.18.4-2_copyright
I'm thinking it should just be a list of all tags in License: fields of all
packages in main. There could be a file per-release (stretch, buster, bullseye,
testing, sid) then perhaps some kind of single file that is a union of all of
them. Or maybe it makes more sense to stick to a single Debian release as the
source of ground truth. I think we'll be able to make that decision when we see
how the data looks.
|
|
I also think that we (Debian) can eventually provide a single canonical machine-readable file. I recommend that we only discuss here the part relevant for SPDX. @eighthave: Can I encourage you to join the #licenses channel on OFTC.net to discuss the Debian side of this further? Otherwise if you prefer to work alone, I can suggest to update https://wiki.debian.org/CopyrightReviewTools whenever you got something working... |
|
Thanks all! Here's a bit of background info re: OSI and FSF (tl;dr - it's not helpful /repeatable here) and other considerations: For OSI - this is maintained manually (still). We added "OSI approved" early on (2011) and at that point in time, OSI wasn't really getting or approving new licenses, so it was sort of just playing catch-up and we didn't really think about automation back then. Over time, we just keep an eye on what's going on over there, but a better process would be good. We just haven't gotten around to coordinating that. Given the process for approving new licenses by OSI is easy to follow and takes some time, it hasn't been too hard to keep up. But not ideal, clearly! For FSF - FSF asked for this, the SPDX team did a first pass comparison. This is an important point: someone needs to go in and identify the license text and check it against the SPDX matching guidelines. We did as much as we could, but had a list of licenses we had questions on (e.g., couldn't find text for license or other things like that) and never got help on that. I think someone from SPDX also tried to write a tool to be able to automate this after the first push, but I think that languished as well. (Honestly, given it is incomplete, I think we should remove the isFSFfree category until we can say it's complete/correct...) so... now you might understand why we don't want to manually maintain another categorization without a good plan for maintenance! Key thing to consider: there are sort of two parts to this:
It might be easier to have a chat? Happy to dedicate one of our team calls to do so. (or move to mailing list?) |
|
Thanks for those details, @jlovejoy I noticed in the email announcement earlier today that SPDX is moving to Jitsi - much appreciated! |
|
the meeting Thursday is the general call which is monthly and gives an overview of what's going on with the SPDX project, plus sometimes a guest speaker. see https://spdx.dev/participate/ I meant a legal team call, which are every other week (next one, May 13th) the legal team mailing list would be most appropriate for this conversation. :) |
|
closing this for now. As stated above, SPDX is open to this idea, but we need to work through a way to do that in an automated way and consider the on-going process aspects. If we want to consider this, it'd be a better thing to raise on the mailing list and perhaps have a call to discuss with tech people as well. |
User story: I am a package maintainer thinking about inclusion in Debian (and derivatives). I would like to know if a given license is suitable for inclusion.
Suggested solution:
Define an "isDfsgCompatible" flag, using the same mechanism as "isOsiApproved" and "isFsfLibre".
Notes:
...but it would be helpful to know if a license is compatible with achieving DFSG status
Debian does not currently (Oct 2017) maintain a machine-readable list of licenses. The closest equivalents are in the references below. In particular the list of licenses that already appear in Debian (de facto compatible), and the list that will never appear in Debian.
Next steps:
Coordination between SPDX and Debian? Scraping Debian list(s)? A pony?
References:
The text was updated successfully, but these errors were encountered: