"Scope" of licenses to be covered by SPDX
Kevin P. Fleming <kpfleming@...>
On 06/28/2012 01:10 PM, Bradley M. Kuhn wrote:
Other license lists aren't designed to allow for cataloging the detailsSPDX files don't require that the licenses they refer to be present in the "SPDX License List". The license that you find in a source file can be represented on its own in the SPDX file. The primary purpose of the license list is to provide consistent names for the commonly used licenses, provide standard texts and (eventually) provide a mechanism for automated matching of license text gathered from source files against these standard licenses. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org |
|
Tom Incorvia
As long as the licenses are
- Carefully named and vetted for exact license text
- Somewhat broadly applicable (“somewhat broadly” is fuzzy, but we do want the list to grow starting with very common and moving to less common – it is a way to get more value with our limited bandwidth to vet the licenses)
Then more is better.
SPDX is looking for volunteers to submit additional licenses that meet the above criteria.
To nominate a license, provide this info: http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added.
Legal team: I can help with the reviews of proposed licenses, although I am not available until the end of July.
Tom
Tom Incorvia tom.incorvia@... Direct: (512) 340-1336
-----Original Message-----
On Jun 28, 2012, at 12:02 PM, Bradley M. Kuhn wrote:
> But, note that exceptions are all over the place, in things like > Classpath, autoconf, and plenty of other places. I wonder: has anyone > taken a Fossology (the best scanning tool available as Free Software) > run of Debian distribution and just made sure every license it finds > has a moniker in SPDX? If not, why not? Seems like a necessary first > step for SPDX to have any chance of being complete.
FWIW, one of our FOSSology contributors (thank you Camille) put together a spreadsheet (HarmonisationLicenseIDs.ods) highlighting the differences between the fossology license list and the SPDX license list:
http://www.fossology.org/projects/fossology/wiki/MatchSPDXLicenceIDs
We plan on using this to update fossology with the SPDX license short names and insure we have license signatures for all the SPDX licenses.
Bob Gobeille _______________________________________________ Spdx-legal mailing list https://lists.spdx.org/mailman/listinfo/spdx-legal
This message has been scanned by MailController - portal1.mailcontroller.co.uk This message has been scanned by MailController.
|
|
Philip Odence
Bradley,
toggle quoted message
Show quoted text
See spec http://www.spdx.org/system/files/spdx-1.0.pdf on pages 23-24. There's a section in an SPDX file called Other Licensing Information Detected to handle licenses not on the standard list. The person creating SPDX file creates an extension to the standard list that is local to the particular SPDX file with similar short names. So, if you find the Bradley Kuhn License you could designate it at BMKL-1.0, say, and then could use that identifier throughout that SPDX file to reference that license. The Other Licensing Information Detected section would map BMLK-1.0 to the specific text of the license. Hope that increases your comfort that the SPDX standard can handle-non standard licenses. And, as others have pointed out, you could also submit the BMKL to the SPDX legal team for future inclusion on the standard list. Best, Phil Jilayne, I am not yet on the legal list, so please forward. On 6/28/12 2:10 PM, "Bradley M. Kuhn" <bkuhn@...> wrote:
Jilayne Lovejoy wrote at 16:05 (EDT) on Wednesday:Do you expect the SPDX License List to cover every license you find?I'm not clear on what the value of SPDX's license list unless it's |
|
Philip Odence
Polite request:
Could we shift this discussion off of the General Meeting list and onto the Legal Team list only? TThis is GREAT discussion for the legal team.
This is not a big problem, but I want to respect the norms we established when we formed the Legal, Business and Tech teams. Part of splitting up the lists was to keep the traffic on the General Meeting list light so as not to burden folks who are only
looking to monitor goings across the teams and at a high level. Real work (and this is real work) is supposed to be done on the team lists.
So, if anyone responds to this (or other emails in the thread) please remove spdx@... from the CC.
Note: anyone not on the legal list and wanting to follow the discussion can sign up at http://lists.spdx.org/mailman/listinfo/spdx-legal
Thanks,
Phil
From: Tom Incorvia <tom.incorvia@...>
Date: Thu, 28 Jun 2012 14:14:32 -0500 To: Bob Gobeille <bob.gobeille@...>, "Bradley M. Kuhn" <bkuhn@...> Cc: SPDX-legal <spdx-legal@...>, <spdx@...> Subject: RE: "Scope" of licenses to be covered by SPDX As long as the licenses are
- Carefully named and vetted for exact license text
- Somewhat broadly applicable (“somewhat broadly” is fuzzy, but we do want the list to grow starting with very common and moving to less common – it is a way to get more value with our limited bandwidth to vet the licenses)
Then more is better.
SPDX is looking for volunteers to submit additional licenses that meet the above criteria.
To nominate a license, provide this info: http://spdx.org/wiki/spdx-license-list-process-requesting-new-licenses-be-added.
Legal team: I can help with the reviews of proposed licenses, although I am not available until the end of July.
Tom
Tom Incorvia Direct: (512) 340-1336
-----Original Message-----
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Bob Gobeille Sent: Thursday, June 28, 2012 1:50 PM To: Bradley M. Kuhn Cc: SPDX-legal; spdx@... Subject: Re: "Scope" of licenses to be covered by SPDX
On Jun 28, 2012, at 12:02 PM, Bradley M. Kuhn wrote:
> But, note that exceptions are all over the place, in things like > Classpath, autoconf, and plenty of other places. I wonder: has anyone > taken a Fossology (the best scanning tool available as Free Software) > run of Debian distribution and just made sure every license it finds > has a moniker in SPDX? If not, why not? Seems like a necessary first > step for SPDX to have any chance of being complete.
FWIW, one of our FOSSology contributors (thank you Camille) put together a spreadsheet (HarmonisationLicenseIDs.ods) highlighting the differences between the fossology license list and the SPDX license list:
http://www.fossology.org/projects/fossology/wiki/MatchSPDXLicenceIDs
We plan on using this to update fossology with the SPDX license short names and insure we have license signatures for all the SPDX licenses.
Bob Gobeille _______________________________________________ Spdx-legal mailing list https://lists.spdx.org/mailman/listinfo/spdx-legal
This message has been scanned by MailController - portal1.mailcontroller.co.uk This message has been scanned by MailController. _______________________________________________ Spdx mailing list Spdx@... https://lists.spdx.org/mailman/listinfo/spdx |
|
Peter Williams <peter.williams@...>
On Fri Jun 29 07:04:27 2012, Philip Odence wrote:
Polite request:Is that really the best choice? This issue seems to be cross functional issue in that it concerns both the license list and the technical details of representing license data in SPDX files (and in the license list itself). I think both the legal and tech teams need to collaborate to solve this problem. Relegating it into any single functional area list will, i fear, hinder progress to a solution quite significantly. Peter openlogic.com |
|
Peter A. Bigot
On Fri, Jun 29, 2012 at 10:19 AM, Peter Williams
<peter.williams@...> wrote: On Fri Jun 29 07:04:27 2012, Philip Odence wrote:Agreed. In this general forum we've heard that the existing SPDXIs that really the best choice? This issue seems to be cross functional license list approach does not meet the needs of Linux distributions (in the case I raised, OpenEmbedded) because it does not have the flexibility to succinctly and accurately represent the current licenses of many GPL packages like gcc and its libraries. Missing a "BMKL" is one thing. Missing GPL-2.0+-with-GCC-exception and other GPL variants in common use, and/or requiring all such variants to be listed explicitly in the spec or named arbitrarily at the discretion of independent compilers of SPDX files, seems to be a more fundamental weakness in the technical description of licenses. Resolution of this is likely to require fairly wide familiarity with what packages should have supported license descriptions in combination with legal insight on how to express their licenses. Adding spdx-tech (which I've just done, and joined) and dropping general (which I have not done), might make sense, recognizing that this sort of fragmentation does make it more likely that issues will not be discovered and resolved in a timely fashion. Peter |
|
Jilayne Lovejoy <jilayne.lovejoy@...>
Great, Bradley. When I find someone who will *do* that work, we will
toggle quoted message
Show quoted text
definitely ask for you input! - Jilayne On 6/28/12 12:02 PM, "Bradley M. Kuhn" <bkuhn@...> wrote:
Jilayne Lovejoy wrote at 16:02 (EDT) on Wednesday:So, if you have an idea as to how to implement this idea, whileIMO, "implementing" is trivial. The tough part is careful cataloging to |
|