[spdx] [ANNOUNCE] FOSDEM 2024 - Fringe event - open source SBOM and SCA tooling workshop on Friday 2024-02-02
Hello everyone! This is a one time announcement. Are you heading to FOSDEM? Join us for a one-day workshop for developers and users of open source SCA, SBOM, and license and security compliance tools on Friday, February 2nd, 2024 in Brussels just before FOSDEM 2024: https://opencollective.com/aboutcode/events/fosdem-2024-fringe-workshop-on-foss-license-and-security-compliance-tools-ea75e63c As distinguished SPDX experts, you are super welcome to join! The event is also co-sponsored by SPDX. The program will be an unconference with the day split in two: tools developers share their plans in the morning and users share their requirements in the afternoon. Registration is required and free (including a free lunch and free coffee), but we encourage your contributions to help us pay for the event's expenses! We booked at https://www.tricoterie.org/en that some of you may know from past FOSS events. We're also looking for generous sponsors to help fund the venue and catering - you can contribute online directly or email me directly at pombreda...@nexb.com I look forward to seeing you there. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com AboutCode - Open source for open source - https://www.aboutcode.org ScanCode - scan your code, for origin/license/vulnerabilities, report SBOMs - https://github.com/nexB/scancode-toolkit https://github.com/nexB/scancode.io package-url - the mostly universal SBOM identifier for packages - https://github.com/package-url DejaCode - What's in your code?! - http://www.dejacode.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1827): https://lists.spdx.org/g/spdx/message/1827 Mute This Topic: https://lists.spdx.org/mt/103662235/21656 Group Owner: spdx+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: public domain dedication variants in the wild (found in Fedora)
Hi Warner, Steve: On Thu, May 11, 2023 at 3:22 PM Warner Losh wrote: > On Thu, May 11, 2023, 7:07 AM Steve Winslow wrote: >> 4. Add a single “PUBLIC-DOMAIN” identifier to the SPDX License Expression >> syntax: Instead of putting a group ID on the license list, define one in the >> SPDX license expression syntax (and the underlying data model). This is >> similar to how NONE and NOASSERTION are specially defined in the spec rather >> than on the License List. >> Among these options, personally I am leaning towards #4 (I can be convinced >> otherwise): > > So tag -> license with PUBLIC-DOMAIN is easy: no license needed so no > obligations. But text-> tag is impossible without a database, which means > something more is needed for that aspect of things because the matching > guidelines can't apply. I'm also not sure how a supply chain chases back a > BOM that has PUBLIC-DOMAIN in it to make sure the original dedication > is sufficient for their jurisdiction. So I'm not sure how each organization > deciding something different would work in practice. That is, unless I've > missed something in #4's description. Steve: I am siding with Warner and I do not see changing the license expression syntax adding a PUBLIC-DOMAIN as a viable solution. If anything this would lose all traceability back to a clear dedication text and IMHO offers no clear benefits and has many drawbacks such as requiring code changes across the board rather than only requiring data change on the license list. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com AboutCode - Open source for open source - https://www.aboutcode.org VulnerableCode - the open code and open data vulnerability database - https://github.com/nexb/vulnerablecode ScanCode - scan your code, for origin/license/vulnerabilities, report SBOMs - https://github.com/nexB/scancode-toolkit https://github.com/nexB/scancode.io package-url - the mostly universal SBOM identifier for packages - https://github.com/package-url DejaCode - What's in your code?! - http://www.dejacode.com nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3376): https://lists.spdx.org/g/Spdx-legal/message/3376 Mute This Topic: https://lists.spdx.org/mt/98776908/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: public domain dedication variants in the wild (found in Fedora)
Hi Jilayne: On Tue, May 9, 2023 at 5:34 AM J Lovejoy wrote: > Some time ago, I raised the issue of the possibility of finding a > proliferation of "public domain "dedication" texts in the course of Fedora > reviewing package license info to adopt SPDX ids. Please see > https://lists.spdx.org/g/Spdx-legal/topic/93048752#3202 for the background > > Fedora has been "collecting" such texts here > https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/public-domain-text.txt > and using a specific LicenseRef-Fedora-Public-Domain as a sort of placeholder > SPDX id. This is awesome! I guess that "LicenseRef-Fedora-Public-Domain" is now the de-facto way to use namespaces for LicenseRef in the same way I have been using them and advocating for this all along with ScanCode with "LicenseRef-scancode-" license keys. > The idea being, no assessment of how many of these types of dedications exist > has been collected in one place in order for the SPDX-legal community to > assess. > > I estimate that Fedora has collected about 48 variations of public domain > statements that are not specifically identified on the SPDX License List. > I'm going to assume many of these packages also show up in other major > distros. A couple notes: - We track over 750 unique public domain dedications variations in ScanCode Toolkit that we have seen in the wild, and you should consider using these. I reckon that you may already be using ScanCode to build some of https://gitlab.com/fedora/legal/fedora-license-data , right? - Some of the dedications listed in this Fedora doc https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/public-domain-text.txt are for bona-fide SPDX licenses such as NIST-PD, SAX-PD, libselinux-1.0 and some are permissive notice that are not public domain and are tracked separately in ScanCode. > I'd like to raise the conversation as to: > 1) Should each unique entry be added to the SPDX License List as a standalone > entry (like normal, in that one SPDX license id represents a specific, > identifiable license/set of text)? > > 2) Should SPDX consider a different approach by defining one SPDX id to > represent any one of a collection of specifically identified and vetted texts? Either way is fine, but be ready to create eventually somewhere around 500+ license identifiers if you go with option 1). We handle these in ScanCode as in your suggested option 2): we have a few license identifiers each with many variants of the license text. And we report the matched license text in scan results (and SPDX documents) of course, so there is never any ambiguity. See https://scancode-licensedb.aboutcode.org/?search=public-domain for the dientifiers we use. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com AboutCode - Open source for open source - https://www.aboutcode.org VulnerableCode - the open code and open data vulnerability database - https://github.com/nexb/vulnerablecode ScanCode - scan your code, for origin/license/vulnerabilities, report SBOMs - https://github.com/nexB/scancode-toolkit https://github.com/nexB/scancode.io package-url - the mostly universal SBOM identifier for packages - https://github.com/package-url DejaCode - What's in your code?! - http://www.dejacode.com nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3366): https://lists.spdx.org/g/Spdx-legal/message/3366 Mute This Topic: https://lists.spdx.org/mt/98776908/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[ANNOUNCE] License and Security Compliance tools users and developers meeting on Feb. 3rd 2023, one day before FOSDEM in Brussels
Hi: If you drop by FOSDEM, there is this one day event before FOSDEM, on Feb. 3rd 2023, in Brussels. https://opencollective.com/aboutcode/events/fosdem-2023-fringe-event-foss-license-and-security-compliance-tools-developers-and-users-workshop-bruxelles-2023-02-03-159433c1 Registration is needed but free (or for a fee) and we have limited seating. FOSDEM Fringe event - Friday February 3rd 2023 FOSS license and security compliance tool developers and users workshop We are organizing a one day workshop for developers and users of open source compliance tools. This is planned in Brussels just before FOSDEM on Friday February 3rd, 2023. We are inviting anyone interested in open source license and security compliance tools to join. The goal of this one day event is for open source developers, users and contributors to exchange around tool requirements, plans, and collaboration opportunities. Which tools is this about? FOSS tools for software provenance detection tools, license detection and compliance tools, code scanning tools, package dependency analysis tools, container analysis tools, SBOM creation and consumption tools, and license or vulnerability databases -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com AboutCode - Open source for open source - https://www.aboutcode.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3305): https://lists.spdx.org/g/Spdx-legal/message/3305 Mute This Topic: https://lists.spdx.org/mt/96199730/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces
Dear David: On Thu, Jun 16, 2022 at 6:57 AM David Kemp wrote: > > Philippe, > >> I am not sure I read you correctly but if are you suggesting that >> Dennis, other ScanCode contributors and I are "refusing to collaborate >> on deconflicting local IDs" for SPDX license ids, that's quite the >> opposite. > > > I did not think that, and I sincerely apologize for ineptly giving that > impression. My intention was to thank Dennis for the opportunity to learn > about ScanCode, and to express puzzlement that a namespacing approach was > being considered. > > I hope that processes and procedures for maintaining a coordinated license > list can be worked out, and I'll try to avoid further interfering with that > process. You are not interfering at all... and I found your reply and insights super useful. I do not know your background, but it is clear that you have experience in this domain. So please do not stop! -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3150): https://lists.spdx.org/g/Spdx-legal/message/3150 Mute This Topic: https://lists.spdx.org/mt/91669820/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces
e incorrectly assuming that Dennis, ScanCode and its contributors are "not agreeing on a unified local ID list". Again that's quite the opposite and speaking on behalf of this community, I am 100% for a unified license ID list which will benefit everyone and be a disservice to none. Please tell me if this is a correct reformulation: you are suggesting having a single, unified list of license identifiers maintained at SPDX and assigned on a first-come-first-served basis. And with a simple rule that no two ids conflict ignoring case and no two ids point to the same text (say using SPDX matching guidelines). If this is what you suggest, I couldn't agree more and I would support this 100%. Weirdly enough I do not think that this has ever been suggested before. Let's do it! This feels massively simpler and more efficient than qualifying license ids with a namespace. -- Cordially, Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3149): https://lists.spdx.org/g/Spdx-legal/message/3149 Mute This Topic: https://lists.spdx.org/mt/91669820/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Artistic-2.0 derivative - npm License
Hi Till: You have eagle eyes! On Mon, May 2, 2022 at 10:46 AM Till Jaeger via lists.spdx.org wrote: > I noticed that NPM is using an Artistic-2.0 with additional terms and > conditions: This is IMHO a total and complete mess and non-sense, eventually non FOSS at all. Anyone from Microsoft or GitHub to fix this monstrosity? Till: Do you know when this showed up? NB: I am adding a rule to ScanCode Toolkit to report this ASAP. -- Cordially Philippe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3116): https://lists.spdx.org/g/Spdx-legal/message/3116 Mute This Topic: https://lists.spdx.org/mt/90831357/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: License text for LGPL-3.0
Steve, Max: FWIW, I already voiced my objection on this topic in the past and I think this is going to be a source of confusion and ambiguity. Why would we need to change the SPDX text for the purpose of one tool and convention? Max: Could you not change your text in your tool instead? - I do not think any of the license texts in SPDX have been designed to be used as reference texts; if anything the templating makes them non suitable for this purpose. - If mixing related texts together is the new way to craft a license text, why not also change the texts of the LGPL 2 and 2.1 to include the text of the GPL 2 in them? - Like the LGPL, every other exception of the GPL would technically demand to include a GPL text too... Does this mean that all the exception texts should be updated now? On Thu, Mar 10, 2022 at 4:06 PM Steve Winslow wrote: > Hi Max, circling back on this thread and your question: > > We briefly discussed this as a follow-up on the last legal team call, and > agreed that there did not appear to be any significant objections to > modifying the LGPL-3.0[-only/-or-later] templates as earlier described here. > I'm planning to submit a PR to incorporate the GPL text as optional in the > templates, so that it'll be included for the next license list release. > > Best, > Steve > > On Mon, Jan 24, 2022 at 11:02 AM Max Mehl wrote: >> >> ~ Steve Winslow [2022-01-10 22:33 +0100]: >> > *Proposal*: >> > >> > REUSE would like to see the combined LGPL-3.0 + GPL-3.0 text used as the >> > plain text file for LGPL-3.0 on the License List. That way, anyone pulling >> > from the plain text licenses will (correctly) include both the LGPL and GPL >> > texts. >> > >> > To implement this, the XML template for LGPL-3.0 would also be updated, to >> > add the GPL-3.0 text with tags following the non-optional >> > LGPL-3.0 text. >> > >> > Personally, I'm +1 to make these changes: >> > * It solves the problem REUSE has identified for their use case >> > * It means that the LGPL-3.0-* templates will continue to match standalone >> > files with only the LGPL text, as well as matching files that contain the >> > combined LGPL+GPL texts. >> > * It doesn't resolve all possible ambiguities about "did you mean >> > everything in this repo is LGPL, or that some things are LGPL and some are >> > GPL?" But neither does the current state of affairs. Using SPDX short-form >> > license IDs and/or standard license headers solves this. So I don't see >> > this as particularly significant to this specific proposal. >> > >> > Please discuss. >> >> Following up on Steve's proposal, I see many people agreeing on it, or >> at least shrugging. There has been a proposal by Alexios that would >> require a larger rework as I understand it, but it feels not like a >> blocker to this concrete proposal, rather like a good idea to make >> special cases like these easier to handle in the future. >> >> Are there any more blockers? >> >> Best, >> Max -- Cordially Philippe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3097): https://lists.spdx.org/g/Spdx-legal/message/3097 Mute This Topic: https://lists.spdx.org/mt/88334638/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Please add FDK-AAC license identifier to SPDX license list
Hi Neal! On Mon, Nov 8, 2021 at 2:48 PM Neal Gompa wrote: > Since SPDX's effort to include all remaining approved Fedora licenses > in SPDX has stalled out (again!)[1][2], can someone *please* add the > FDK-AAC identifier to SPDX? It's blocking my submission of > fdk-aac-free to openSUSE[3] right now. > > It is actively used in Fedora for fdk-aac-free[4][5]. > > [1]: https://pagure.io/packaging-committee/pull-request/971#comment-154838 > [2]: > https://lists.spdx.org/g/Spdx-legal/topic/proposal_for_fedora_to_start/84468700 > [3]: https://build.opensuse.org/request/show/928162 > [4]: https://src.fedoraproject.org/rpms/fdk-aac-free > [5]: https://fedoraproject.org/wiki/Licensing/FDK-AAC If this can help we have tracked this in ScanCode for as long as I and git can remember: https://scancode-licensedb.aboutcode.org/fraunhofer-fdk-aac-codec.html We use this SPDX identifier: LicenseRef-scancode-fraunhofer-fdk-aac-codec -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3023): https://lists.spdx.org/g/Spdx-legal/message/3023 Mute This Topic: https://lists.spdx.org/mt/86905565/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Caldera license question
Dear Warner, Armijn and Jillayne: On Tue, Oct 26, 2021 at 1:20 AM Warner Losh wrote: >> Did they harvest these files from the 7th Edition of Unix, or did Sun >> license these and Caldera made them put this license on things? The version >> 7 /bin/sh was included in the grant of the original license, and the System >> V version was excluded which is what the OpenSolaris one is based on if it >> came from Sun's repo... But I've not done the software archaeology to know >> from whence this project started their sources... So with a bit of digging in CVS (yeah!) ... on only one file (gmatch.c), it looks like the original commit had this caldera license header alright and that must have been added when porting from the 7th edition, per the "Derived from /usr/src/cmd/sh/expand.c, Unix 7th Edition:" comment in that file. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/expand.c did not have such notice. So I would surmise that Gunnar Ritter (Heirloom's original creator) took the original 7th edition code from TUHS and used the TUHS-provided Caldera notice (such as at https://www.in-ulm.de/~mascheck/bourne/Caldera-license.txt ) to add as a comment in the code. The timeline of various events supports this analysis. Sven Mascheck has an extensive Shell history at https://www.in-ulm.de/~mascheck/bourne/#heirloom including a Heirloom shell commit log that matches the CVS's log at https://sourceforge.net/projects/heirloom/ With all that said, the license text that we discuss here and as seen in gmatch.c is IMHO closest to a plain BSD-4-Clause with minor variations (e.g. scope of source and documentation vs. only source in BSD-4-Clause) so if the intro blurb seen in the SPDX Caldera text is not material, then may be the body text itself could be just a minor variant of the BSD-4-Clause. Someone could bug Gunnar Ritter at of course to get confirmation. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3017): https://lists.spdx.org/g/Spdx-legal/message/3017 Mute This Topic: https://lists.spdx.org/mt/86580130/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: SPDX License List coverage for a full distro
Hi Karsten: On Tue, Aug 17, 2021 at 10:55 AM Karsten Klein wrote: > I see the following option (as outlined the one or the other time before): > SPDX (in the future) assesses and captures licenses on two levels. In my > brief words: > Level 1 - License Text and Provision of SPDX-Id > The license text is just captured as is and an SPDX identifier is derived. > This id can then be used to identify this particular license text. > Level 2 - License Text, License Text Metadata, Matching Rules and Provision > of SPDX-Id > This is the current scheme and requires modelling of the licenses and > matching rules. A big +1 for this. (And until then, namespaced LicenseRef- are an OK approach) -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2985): https://lists.spdx.org/g/Spdx-legal/message/2985 Mute This Topic: https://lists.spdx.org/mt/84928724/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] capitalization rules for SPDX license ids and operators
Alexios, Jilayne: On Thu, Jul 29, 2021 at 9:52 AM Alexios Zavras wrote: > You can refresh your memory on the discussions (2015-2020) by reading > https://github.com/spdx/spdx-spec/issues/63 > I still like my example from that thread: Do we really want to be able to > understand > Mit and gpl-2.0 And Gpl-1.0+ aNd ePl-1.0 aND isc > or can we simplify our lives and have one way of expressing the combinations? >> From: spdx-t...@lists.spdx.org On Behalf Of J >> Lovejoy >>> However, please be aware that it is often important to match with the case >>> of the canonical identifier on the SPDX License List. This is because the >>> canonical identifier's case is used in the URL of the license's or >>> exception's entry on the List, and because the canonical identifier is >>> translated to a URI in RDF documents. >> I'm wondering - was there a particular reason that the license expression >> operators are case-sensitive (while the license ids are not)? IMHO it would be a good time to revisit this. The case of license identifier does not and never did really matter otherwise. It does not matter to users. And most tools do not care either. The tyranny of a serialization format (e.g. RDF) or a technical requirement such as URL on a website should not impact everyone. These should be solved differently. What about adopting a simple way: define once for all that a canonical license expression and identifier representation are either all lowercase or all uppercase and be done with this topic for good. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2968): https://lists.spdx.org/g/Spdx-legal/message/2968 Mute This Topic: https://lists.spdx.org/mt/84523812/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Combined version of LGPL + GPL 3.0
Hey Max, You wrote: On Wed, Jul 28, 2021 at 11:01 AM Max Mehl wrote: > In the scope of REUSE we've noticed [^1] that just providing LPGL-3.0* – > as downloaded from SPDX – in a repo does not suffice as it requires its > mother license, GPL-3.0*. LGPL could be seen as an exception to GPL, but > it's not treated as such by the FSF. > > Matija and I discussed that with FSF and the different options we have > to suit SPDX, REUSE and other downstreams. We found a compromise: there > is now an officially acknowledged license text that contains both > LGPL-3.0 and GPL-3.0: > > https://www.gnu.org/licenses/lgpl+gpl.txt Has this been discussed publicly? > Now my request: can we get this combined version into SPDX' license list > data, e.g. [^2]? > [^1]: https://github.com/fsfe/reuse-tool/issues/86 > [^2]: > https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-or-later.txt I think that you stated explicitly this is not a new license, just a clarification (optional one?) that providing both texts when referencing LGPL-3* is better. How could one ever handle this sanely in practice? If this is not a new license, why would you need a new license identifier? If this is a new license, or a new previsously unstated requirement of the LGPL 3 it would need some wide open and public discussion IMHO. Some examples of the new and updated clarity issues this brings: Say I stumbled on the text at https://www.gnu.org/licenses/lgpl+gpl.txt in some project... is this project using the LGPL only or the LGPL and the GPL that apply? It is impossible to disambiguate which one applies short of a statement by the authors that they mean the GPL not to apply but that only the LGPL should be considered there and that the GPL text is there only for reference. What if a project contains both GPL3 and LGPL 3-licensed code? They could use the exact same text as above and I would still not be able to disambiguate short of extra statements. Now say the author added a license identifier in the code saying that this is "LGPL-3.0-only"... did they forget to reference the GPL text in the combined text above? Or is this really just LGPL? Or is some part of the code GPL-licensed but not marked as such? I cannot say for sure either and I would not trust that. I still need some more explicit statements to get clarity. IMHO the status of the LGPL as a self standing text or whether it needs to be accompanied by the GPL text has been a jolly mess of ambiguity since the release of the L/GPL3*. I cannot see how the FSF releasing a text that combines two texts makes it any better, to the contrary: it just adds even more ambiguity and confusion. Even more so if there has been no public discussion on the topic. I cannot fathom how this kind of confusion, uncertainty and doubt is helpful to anyone producing or consuming LGPL-licensed code. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2951): https://lists.spdx.org/g/Spdx-legal/message/2951 Mute This Topic: https://lists.spdx.org/mt/84501245/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Options for metadata license identifiers
Hi Richard: On Thu, Mar 18, 2021, Richard Purdie wrote: [...] > The worry is something like: > > # SPDX-License-Identifier: MIT > LICENSE = "GPLv2 & bzip2-1.0.4" > > makes for very confusing reading and can be badly interpreted. FWIW, I have been involved with quite a few license audits for Yocto- based products and this is already a source of confusion as it is: in many cases knowing if a license applies to the recipe or to the package being built by the recipe is far from obvious. My first reaction and suggestion would be to forego using SPDX-License- Identifier in recipes and instead to use a new variable in a recipe for this such as this: RECIPE_LICENSE = "MIT" LICENSE = "GPLv2 & bzip2-1.0.4" And if you need to have a separate license variable for patches: PATCHES_LICENSE = "MIT" This would be explicit, clear and nicely integratable in your tooling IMHO. Ideally of course you'd want the content of these to be valid SPDX license expressions. Until then I will have to have a mapping and special detector for [1] to properly collect normalized SPDX licenses from recipes. And FYI while I have your attention: We are adding support to handle Yocto recipes in ScanCode-toolkit [1] and [2] for license and origin detection. This involves parsing and "resolving" recipes which is not trivial without running bitbake. This is done thanks to Konrad Weihmann (in CC:) who kindly extracted his excellent linting-focused recipe parser in a separate library [3]. [1] https://github.com/nexB/scancode-toolkit/issues/1243 [2] https://github.com/nexB/scancode-toolkit/pull/2443 [3] https://github.com/priv-kweihmann/oelint-parser -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2914): https://lists.spdx.org/g/Spdx-legal/message/2914 Mute This Topic: https://lists.spdx.org/mt/81426493/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: How to start using only SDPX-License-Identifier tags
tribution notices are usually more than just a copyright + a license notice, but often contain extra notices such as: - This code is derived from software contributed to Berkeley by John Doe. - This code was contributed to The NetBSD Foundation by Jane Doe. - or [8]: "Created by: Warner Losh " You should document what you would want to do with these. 9. BSD historical licenses comes with many small variants of BSD and MIT licenses (even in some case your own making [9] ;)) You should document what to do with these cases and in particular: - should ALL the original name be kept when the text meets SPDX matching-style guidelines? MO no - define a process to resolve cases that are borderline and fall outside the strict guidelines - when should original authors be contacted, and what to do if they are AWOL? - when to submit a new license to SPDX? I suspect you will find a large number of licenses that are unknown to SPDX. I would suggest to use first a LicenseRef namespace like I do in [10] either scancode's or to create your own first then funnel these as needed to SPDX. In my Linux Kernel scans, I "discovered" several new and weird license variants (several being franken-BSD and franken-MIT hybrids and mods). Many were eventually added to the SPDX license list. It would be great to have the same outcome for your FreeBSD effort! 10. When doing large commits to fix many files, Thomas Gleixner and Kate Stewart enrolled several volunteers from this list -- several of them legally trained -- to help review and sign-off on the changes. This was helpful on so many levels. IMHO you should do the same for FreeBSD. 11. What would be your strategy? A trickle a few files at a time over time, possibly grouped by package or authors/licenses? Or a few larger tree-wide changes? The latter approach was used for Linux and we started with grouping things based on the licensing documentation clarity. It was large to swallow but once we were over the hump I think it made things easier afterwards. 12. What's your plan for files with no explicit license and copyright? I hope this long list of comments may help ... I did not have the time to make them shorter! [1] https://reuse.software/ [2] https://www.python.org/dev/peps/pep-0639/#appendix-3-surveying-how-other-package-formats-document-licenses [3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/process/license-rules.rst [4] https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/pref-license.html [5] https://docs.freebsd.org/internal/software-license.html [6] https://github.com/nexB/scancode-toolkit [7] https://github.com/nexB/scancode-toolkit/blob/833-espedexify/src/scancode/plugin_espedexify.py [8] https://github.com/freebsd/freebsd-ports-kde/blob/68a0222b674a77c456b45e3784ad24447e1eba52/devel/p5-Acme-Damn/Makefile#L1 [9] https://github.com/freebsd/freebsd-src/blob/ba7ede0b9b3d0c3a64e6e7d8cbfe26b6f882f39f/UPDATING#L2434 [10] https://scancode-licensedb.aboutcode.org/ -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2912): https://lists.spdx.org/g/Spdx-legal/message/2912 Mute This Topic: https://lists.spdx.org/mt/81416066/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Using SPDX for Python packages license documentation
Dear Special People Doing eXceptional things: FYI, I have been working with the Python community to specify how Python package distributions can use SPDX license expressions for their Core metadata. The draft of this spec (called a PEP for Python Enhancement Proposal) is at: https://www.python.org/dev/peps/pep-0639/ Comments and feedback are welcomed at: https://discuss.python.org/t/2154 -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2870): https://lists.spdx.org/g/Spdx-legal/message/2870 Mute This Topic: https://lists.spdx.org/mt/77195584/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: License of an open source license text
Hi Richard: On Thu, Jun 18, 2020 at 2:57 PM Richard Purdie wrote: > Just to be really clear, the license ID of a given specific > package *is* correct and definitive. What is unclear is the license of > the license information. > > The challenge is that one software project can be split into multiple > binary packages and those binary packages can have finer grained > licenses. > > For example, gcc which contains libgcc. gcc is GPL-3.0 and libgcc is > the under the runtime license exception. We specifically mark the > binary packages with the correct license. > > This isn't enough for some legal departments and some licenses, we have > to have the full license text somewhere. We have options: > > a) Include the full license text in every binary package > b) Have a licence package per test and require each binary package to > depend on that license package > c) As per b) but have the package management or tools figure out the > dependencies if requested > d) Have a license package per piece of software containing all the > licensing texts for that piece of software. > > There are pros and cons for all of these, some of the issues are very > significant, particularly in a constrained embedded system. Rightly or > wrongly, we have d) implemented today and this is consistent with what > other distros like Debian do (although they merge docs and license > info, we split them). > > Also, this assumes the licenses can be split into specific individual > chunks. I suspect in some cases this is not possible. > > The question is what license is that package in d) under. Then in this case you can take the same approach as Debian's packaging: your package in d) can be under its own license unrelated to the license of the things it contains. You could state that the license of the packaging of these license data is under a CC0-1.0. You are not making any assertion about the license of the licenses which are under whatever license they may be; and whatever these may be are self-contained in their own license texts. This is the approach I take in scancode. I bundle thousand license texts and I am not reporting any specific license for these license texts.. Instead I am only declaring that the license data set is under CC0-1.0 As an aside, this might make scancode's [1] processing a little more complicated ... but this could be fixed if we know we are looking at the license of Yocto packages somehow. -- Cordially Philippe Ombredanne [1] https://github.com/openembedded/meta-openembedded/blob/612128b46d183934bda7d0c7e224a313fc54d227/meta-oe/classes/scancode.bbclass -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2834): https://lists.spdx.org/g/Spdx-legal/message/2834 Mute This Topic: https://lists.spdx.org/mt/74485307/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: License of an open source license text
Hi Richard: On Thu, Jun 18, 2020 at 12:37 AM Richard Purdie wrote: > If we set the license of the licence text package to include GPL-3.0, > the legal department blocks the release since they said "no GPL-3.0". > If you tell them its only the license text, they tell you the license > is not GPL-3.0 and the license is incorrect. What should the license > be though? I think there may be a different perspective to consider: Why include the GPL text if it does not apply (or for that matter for any license)? A license id that is trying to convey more or less that "we included this license text in this package but it really does not apply to anything, so please ignore it" may not be the best approach. Instead, what about correcting the Yocto packaging and include only the licenses that apply to this package? You also wrote: > > We also put the license texts into its own package. Right now that > > package is licensed as "LGPL-2.1 and GPL-3 and GPL-2", the same as > > the overall license. IMHO that's the root of the problem, you are including and mixing licenses that may not apply and trying to convey with some id that these included licenses may not apply. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2831): https://lists.spdx.org/g/Spdx-legal/message/2831 Mute This Topic: https://lists.spdx.org/mt/74485307/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: SPDX License List license inclusion guidelines
Hi Jilayne: On Thu, Mar 12, 2020 at 12:59 PM J Lovejoy wrote: > I’m sending this to both the legal and general mailing lists to ensure > greatest visibility. The legal team has come up with a final draft of the > license inclusion guidelines based on various conversations and feedback > over the past 8 months of intermittent discussion. > The pull request representing this draft is located here: > https://github.com/spdx/license-list-XML/pull/990 On January 31st a compliance tooling meeting and hackathon took place in Brussels before FOSDEM [1]. One of the session topics was SPDX. Everyone there agreed that SPDX license inclusion criteria should be relaxed. Adding more restrictions and filters is IMHO counterproductive in several ways: - it requires more work to apply these restrictions and filters - more work means fewer licenses are added - as a shared "vocabulary" the utility function of the license list is directly related to the number of "words" we can use. Restricting the number of words in the license vocabulary only means that these words cannot be used in shared conversation about licenses. But these licenses still exist, so the restrictions impact mostly the usefulness and expressiveness of SPDX, especially in the more common cases where license expressions are used without an SPDX document. This could increasingly make the SPDX License list irrelevant if it is missing important license vocabulary. The existing and proposed license inclusion criteria seem counterproductive and likely to subtract value from SPDX. The community does not need SPDX to police or enforce OSS license "purity" via the license list. Instead there should be fewer barriers to adding new licenses to the list in order to optimize the utility of the SPDX license list and the number of common licenses SPDX expressions can deal with. Since SPDX does not interpret license conditions, the inclusion guidelines should be loosened to include commonly-used and public licenses without an OSS litmus test (e.g. free proprietary licenses). This will become more important for SPDX as more organizations become more focused on compliance and are looking for a way to account for all licenses detected from scans or other analysis. [1] https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit# -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2757): https://lists.spdx.org/g/Spdx-legal/message/2757 Mute This Topic: https://lists.spdx.org/mt/71910791/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Tagging of UNCOPYRIGHTABLE material
Dear David: David A. Wheeler wrote: > So for example, > https://creativecommons.org/choose/mark/results?work_title=WORK_NAME_title=AUTHOR_NAME_href=AUTHOR_URL_title=INDIVIDUAL_NAME_href=INDIVIDUAL_URL=en_US=continue > ends up being displayed as: > This work (WORK_NAME, by AUTHOR_NAME), identified by INDIVIDUAL_NAME, is free > of known copyright restrictions. > While just retrieving https://creativecommons.org/choose/mark/results reports: > This work is free of known copyright restrictions. > It’s pretty obvious how this works. I suspect the Creative Commons folks > would be happy to reveal the full template, they probably have just never > been asked. I think these are generated by this fine Python code [1] [1] https://github.com/creativecommons/cc.license/blob/a134299fdb0e882b84a2c181afc5588e13ae32df/cc/license/formatters/classes.py#L324 -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2738): https://lists.spdx.org/g/Spdx-legal/message/2738 Mute This Topic: https://lists.spdx.org/mt/71831424/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: SPDX meeting Friday March 13th
Jilayne: On Thu, Feb 27, 2020 at 3:53 PM J Lovejoy wrote: > There is an SPDX room available co-located and after the event for the LF > Member > Summit in Lake Tahoe. The SPDX meeting will be Friday afternoon, the 13th - > 1pm - 6pm > > I was wondering: > - who else will be there from the legal team? > - assuming we can work out sufficient sound going for a call - > who would be inclined to join via phone? I would have loved to join but my travel plans are already set and I am leaving Friday. A bit more of an advance notice would have been needed. Phone would be nice. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2731): https://lists.spdx.org/g/Spdx-legal/message/2731 Mute This Topic: https://lists.spdx.org/mt/71598711/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[ANNOUNCE] Open source license compliance tooling meeting and hackathon on January 31st 2020 pre-FOSDEM fringe event in Bruxelles, Belgium
If you care about open source compliance automation and if you are going to FOSDEM there is a one day hackathon and meeting taking place the day before FOSDEM on Friday January 31st as "fringe" event, in Bruxelles, Belgium. The topic is open source compliance tooling and automation... the format is an unconference. I expect several open source projects in that space to be represented there including ORT, Fossology, ClearlyDefined, SPDX tools, Scancode and many more. I am co-organizing this with Michael Jaeger from Fossology. See https://docs.google.com/document/d/1UphruKKAlsoUEidPCwTF2LCcHFnQkvQCQ9luTXfDupw/edit#heading=h.p2d7mni4lrcu for details. To "register", just add you name to this document! (alternatively you can reply to me off list too) I look forward to seeing you there! -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2714): https://lists.spdx.org/g/Spdx-legal/message/2714 Mute This Topic: https://lists.spdx.org/mt/69718205/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Request for adding Eclipse Distribution License - v 1.0
Hi Aurelien: On Tue, Dec 10, 2019 at 6:36 PM CARLIER Aurelien wrote: > I would like to request addition of the Eclipse Distribution License in the > SPDX license list. > The EDL-1.0 is a variation of the New BSD License As far as I can remember, since this is the same as the BSD-3-Clause license text (using the matching guidelines), it was never added as its own license id. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2702): https://lists.spdx.org/g/Spdx-legal/message/2702 Mute This Topic: https://lists.spdx.org/mt/67981884/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Request for new Apache-2.0 runtime license exception
Hi Thomas! On Tue, Jun 4, 2019 at 11:17 AM Thomas Steenbergen wrote: > I would like to request below license exception to be added to the SPDX > specification. > This exception is popping up in open source project related the Swift > programming language maintained by Apple. > Its text is close in intention to the LLVM-exception but lack the whole > GPL-2.0 text found in LLVM. > License Full Name: Apache 2.0 Runtime Library Exception > Short Identifier: Apache-Runtime-exception-2.0 > Source/URL: > https://swift.org/LICENSE.txt > https://github.com/apple/swift-package-manager/blob/master/LICENSE.txt > https://github.com/JetBrains/jediterm/blob/64e461c932fb0aac0e05c4546a0002fef47711e7/LICENSE-APACHE-2.0.txt FWIW, I agree this is rather common in the wild. It has been tracked and detected as "apple-runtime-library-exception" in the scancode-toolkit since April 2018. https://github.com/nexB/scancode-toolkit/commits/develop/src/licensedcode/data/licenses/apple-runtime-library-exception.yml -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2611): https://lists.spdx.org/g/Spdx-legal/message/2611 Mute This Topic: https://lists.spdx.org/mt/31924662/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
GPL-CC and Kernel enforcement statement
Dear legal eagles: I just saw that the request to have a proper SPDX license id for the Kernel enforcement statement has been closed [1]. I guess I should have followed the discussion that happened late last year since I started this on list way back when [2]... I am looking at all the non-SPDX licenses detected in the kernel to submit them for addition and I am not clear why this would be rejected: this text is detected alright when you scan the kernel and has been for a long while (at least by ScanCode). And the same applies to the GPL-CC [3]. IMHO as a license compliance toolsmith, if this is something licensing-related, then it should be detected. It it is detected and is in common enough, then it should have a name/id. 1. Do such statements/commitments texts are worthy of detection by a license scanner? I think so. Otherwise, why would they exist? 2. Are they common enough? Beyond the kernel, there is a growing number of projects and companies adopting these [4] [5] and is even suggested by GitHub's choosealicence [6], so I would say yes. What is wrong with this reasoning? Could someone explain to me in simple terms why not including these in the list? Thank you ++ for your help! [1] https://github.com/spdx/license-list-XML/issues/655 [2] https://lists.spdx.org/g/Spdx-legal/message/2083 [3] https://github.com/spdx/license-list-XML/issues/714 [4] https://github.com/PHPMailer/PHPMailer#license [5] https://github.com/jboss-set/eap-additional-testsuite/blob/99571420357fe1353f3f2bc994986f03f5661751/Runtimes/ACTIVEMQ/README.md#license [6] https://github.com/github/choosealicense.com/blob/gh-pages/_includes/sidebar.html#L29 -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2570): https://lists.spdx.org/g/Spdx-legal/message/2570 Mute This Topic: https://lists.spdx.org/mt/30439307/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: An example of a super simple SPDX licenses registry, for discussion
Kyle: On Wed, Mar 13, 2019 at 6:54 PM Kyle Mitchell wrote: > How will you handle name disputes? How will you deal with > complaints (to SPDX/LF) about the identifiers being used by > private parties under their assigned namespaces? > > Prior art: https://www.npmjs.com/policies/disputes Thankyou: that's all valuable things to consider indeed and hard earned from the leftpad issues. Though I doubt mere licenses will ever be as successful as npm! -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2569): https://lists.spdx.org/g/Spdx-legal/message/2569 Mute This Topic: https://lists.spdx.org/mt/30299819/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Richard: On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana wrote: > This sounds appealing to me (if I'm understanding it correctly). From > Red Hat's perspective one of the great impracticalities of SPDX has > been that, after many years of SPDX's existence, its adopted > identifiers still represent only a small portion of the licenses > encountered in much of the the software we encounter in our product > and project development. Let me recap my understanding: I think everyone agrees that we want want more licenses in SPDX. Anyone against this, please voice your concerns now. The review of new licenses for list is an all-volunteers process with a certain level of ceremony explained here https://spdx.org/spdx-license-list/license-list-overview and therefore it takes time. But it takes too much time. Why do I want an id for stable/well-defined licenses? This would make it easier to talk about and exchange licenses and it does not require the reproduction of the license text at all times. Why not using a LicenseRef for these? This would still require reproducing always the license text in every SPDX document, which does not help when there is no document (e.g. in a package manifest such as an npm or an RPM). NOASSERTION as used for now in ClearlyDefined is also fraught with problems as highlighted by Richard earlier. There are two main use cases for more licenses: private or public licenses. The main concern is to ensure that these license ids are unique enough in both cases, and that there is minimum or no duplication of license texts across ids. - For private licenses, the only concern is to ensure that names are unique enough. Mark suggested using a reverse domain name prefix for this. I suggested a lightweight registration of a prefix that would not require one to own/buy a DNS domain name. The two can likely work together (e.g. you could use a domain name or anything and still do a one time registration). In anycase, I become the master of the license texts and ids in my namespace. - For public licenses one could use a prefix/namespace plus the optional registration of actual license id/name/texts. A content-defined fingerprint id may not help in practice as I explained in a previous email as too brittle. In light of all this, here is my suggestion: 1. Establish a lightweight, easy and fast registration process for SPDX license id prefix (aka namespace). As simple as a quick PR in a Git repo. This prefix can be made of any character that would be a valid license identifier. This is used to prefix ids (and not in LicenseRef). This way you can use both DNS and non-DNS names alright. This can be used for both public and private namespaces. 2. Establish a lightweight, easy and fast registration process for prefixed SPDX license ids in an existing namespace. As simple as a quick PR in a Git repo. Submissions are very lightly moderated (we want to register licenses but not cooking recipes). There is no need for any markup or other annotations at this stage: only basic id, name, text and possibly URLs. When submitted, there is an automated deduplication triggered (e.g. we run a license scan on this license text) and if a submission is the same or mostly the same as any existing SPDX licenses, the check fails. (This is a CI script). The submitter can then reuse instead a pre-existing license id. 4. We add a status for licenses records such that they are either reviewed/approved by the SPDX legal team or not. The submissions of namespaced ids would NOT be in the approved status. 5. From that point on, the SPDX legal team can use not only direct requests for license additions but also can funnel selected public registrations as candidates for inclusion in the main SPDX non-namespaced License List. Done. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2568): https://lists.spdx.org/g/Spdx-legal/message/2568 Mute This Topic: https://lists.spdx.org/mt/30394607/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion
Richard, Jeff: On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana wrote: > Use of "LicenseRef" (not to mention something like > NOASSERTION) is a nonstarter for the use cases we are most interested > in. What we've actually done in some cases is use the nonstandard > identifiers created by nexB. Agreed. What I am trying to achieve here is to make these become "standard" and known at SPDX. I think this is possible. On Sun, Mar 10, 2019 at 12:44 PM Jeff McAffer wrote: >> IMO the "ideal" here is that there is some automated way of >> "fingerprinting" license texts such that two parties, given more or less >> the same text, can independently come up with the same id. At that point >> you would not need a registry, just a shared algorithm. When/if eventually >> SPDX does recognize a given license and gives it a formal id, there could >> be a relatively simple aliasing step where SPDX id "SomeCoolLicense-1.0" >> is AKA "LicenseRef-43bdf298" This ideal works in theory but for several reasons I outline below would be too brittle in practice as you would have different fingerprints too often for this to be working. Instead running a full license detection is a better way to dedupe things. And this requires some form of centralization but could be fully automated alright. The other thing is that IMO giving a name/id does matter a lot: the license named 43bdf298 is not really human friendly. Now even if license-text-fingerprint-as-id were to work out, the difficult part is not so much the algorithm for computing these, but the content you feed for fingerprinting. And that part is not easily to automate: - For instance, is a copyright part of the license or not (I think not, but YMMV)? - Or what about statements around a license? For instance these two SPDX licenses may not really deserve a different id yet they have one: https://spdx.org/licenses/bzip2-1.0.6.html and https://spdx.org/licenses/bzip2-1.0.5.html The LICENSE file in the original code archives does not have a patent disclaimer statement footer seen in bzip2-1.0.5's SPDX license text. That footer is present on the archive.org website only. I would not treat this as part of the license, but this was treated as part of it here. This is a judgment call. - Or for instance, there are 6+ version of the text of the GPL-2.0 which are really the same but would fingerprint differently. Therefore a fingerprint algorithm would be hard to generalize as there would be many exceptions or a simple one would be too brittle in too many cases. Deduping is best achieved by license detection with a full diff (which is what scancode does FWIW). Let me follow up with my suggestion. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2566): https://lists.spdx.org/g/Spdx-legal/message/2566 Mute This Topic: https://lists.spdx.org/mt/30394607/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: An example of a super simple SPDX licenses registry, for discussion
Hi Jilayne: On Sat, Mar 9, 2019 at 6:40 PM J Lovejoy wrote: > Hi Philippe, > I’m a bit lost on what the goal of this is. Can you provide a bit more > context. > > I looked at a couple entries and noticed, for example, this one: > https://github.com/nexB/spdx-license-namespaces-registry/blob/master/scancode/licenseref-scancode-bsd-innosys.spdx > > which then points to this: > https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/bsd-innosys.yml > > which notes that this is common in the Linux kernel. > > Weren’t we going to add to the SPDX License List some of the other common > licenses you all were finding in the kernel? > > > and https://github.com/nexB/spdx-license-namespaces-registry/pull/1 > > I sent it quickly during the legal team call on Thursday and sorry for not providing much background then. Here it is: There has been a recent discussion initiated by Mark Atwood to create stable, yet private SDPX identifiers. And there is a similar need for ScanCode licenses too (See https://github.com/nexB/scancode-toolkit/issues/532 and has been requested by several users too. Through the discussions, Kate and Gary suggested that we could reuse LicenseRef and create an SPDX document for each license. The example repository and example pull request that I linked above are to provide an example of what this would look like if we were to have such a system where there could be two level of registrations: simple namespace and namespace + licenses ... all using LicenseRef The benefit is that there would be no change to the spec required at all and could be used today. Now, the actual content of the repo I linked is based on a completely random subset of non-SPDX-listed licenses that exists in ScanCode, so their actual content is not relevant here. I reckon that I still owe you to submit all the licenses that we found in the kernel that are not yet in SPDX I am terribly late on that part. The two are not directly related... yet I could see the submission of namespaced licenses as being a funnel for actual additions to the SPDX list proper. Some may be worthy of that addition while some may not make the cut. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2561): https://lists.spdx.org/g/Spdx-legal/message/2561 Mute This Topic: https://lists.spdx.org/mt/30299819/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
An example of a super simple SPDX licenses registry, for discussion
See https://github.com/nexB/spdx-license-namespaces-registry/ and https://github.com/nexB/spdx-license-namespaces-registry/pull/1 -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2554): https://lists.spdx.org/g/Spdx-legal/message/2554 Mute This Topic: https://lists.spdx.org/mt/30299819/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: A proposal for SPDX Private License Identifiers. Example: .com.amazon.-.ASL-2.0
Hi Mark: On Mon, Feb 4, 2019 at 9:57 PM Mark Atwood wrote: > Just following up, does anyone have any comments or suggestions for my > proposal for SPDX Private License Identifiers? We surely could use a way to have namespaces of sorts for extra, non SPDX-listed license identifiers. This is something that I could use alright for ScanCode where we track roughly an extra 1000 licenses and exceptions more than in the SPDX list (ScanCode has 1456 licenses and exceptions and there are 415 in the SPDX list) ScanCode handles this today by returning a well defined LicenseRef-xxx in SPDX documents for non SPDX-listed licenses . And a recent contribution by Tobias Furuholm created a "namespace"-like convention to use this for ids for such licenses: License-Ref-scancode- The project guarantees the to be stable overtime (e.g. they can be deprecated if needed but never deleted) . See https://github.com/nexB/scancode-toolkit/issues/532 for some discussions > SPDX-License-Identifier: .com.amazon.-.ASL-2.0 > https://aws.amazon.com/doc/ASL-2.0 [...] > In a SPDX-License-identifier declaration, a Private License Identifier can > optionally be followed by a URI pointing to the canonical license text. > This URI should be under the control of the entity that controls the DNS > namespace of the Private License Identifier. SPDX-License-Identifier is not declaring an id, but instead using ids in an expression so I think this would break the license expression syntax may be? Otherwise how would express something such as: my-private-license1 AND my-private-license2 As a recap I think that: 1. having some kind of namespacing is a great idea 2. I find reverse DNS and dots hard to read and I would likely make many typos when writing/typing these down. 3. an SPDX-License-identifier is a whole expression so changes should not break license expressions. 4. it might be clearer to distinguish naming (giving an id) and documenting that id separately (providing extra information about this id such as at a URL to a text or other data) and not try to put them all in one place. 5. LicenseRef (and possibly some specified or conventional way to structure them) may be a way to consider -- Cordially Philippe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2536): https://lists.spdx.org/g/Spdx-legal/message/2536 Mute This Topic: https://lists.spdx.org/mt/29528568/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: the freenode.net/#spdx channel seems to be dead, is there an official SPDX chat venue?
Hi Marc: We use https://gitter.im/spdx-org/Lobby (which is also accessible by IRC) on the tech side. Should be easy enough to have a legal channel there -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2516): https://lists.spdx.org/g/Spdx-legal/message/2516 Mute This Topic: https://lists.spdx.org/mt/28998265/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: New License/Exception Request: Python Imaging Library License
Hi Mark: On Thu, Dec 13, 2018 at 8:42 PM Mark Atwood via Lists.Spdx.Org wrote: > Provide a proposed Full Name for the license or exception. > Python Imaging Library License It looks to me as a proper historical permission (HPND https://spdx.org/licenses/HPND.html ) This has been detected by the ScanCode toolkit as an HPND alright and this is within the "matching guidelines" too IMHO... unless this additional "prefix" is considered as creating something entirely new: "By obtaining, using, and/or copying this software and/or its associated documentation, you agree that you have read, understood, and will comply with the following terms and conditions:" ... -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2505): https://lists.spdx.org/g/Spdx-legal/message/2505 Mute This Topic: https://lists.spdx.org/mt/28745782/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: GPL Cooperation Commitment variations
If this can help, we have tracked in ScanCode all the 15 known text variations to date: https://github.com/nexB/scancode-toolkit/search?p=1=%22this+Commitment+to+be+irrevocable%22_q=%22this+Commitment+to+be+irrevocable%22 -- Philippe On Thu, Nov 29, 2018 at 7:54 PM J Lovejoy wrote: > > Hi all, > > I know I just wrote in the minutes that this task was on Richard F, but I was > too curious not to have a cursory look myself! > > Attached is a compare of the project to corporate variant; and of the > individual to project variant. The main difference seem to be: > - in the use of pronouns (I, We, name of coroporation) - easily accommodated > with markup. > - likewise, the associated definition of We or the corporation name, or the > absence of a definition for individual at the end > - likewise, lead-in text for the individual version clarifying it only > applies to their sole copyright > - there is also an additional term that the corporate variant has about the > ability to modify the commitment by posting a new edition - this is not > included at all in the project or individual variants. I think this could be > omitable in some way? if a cooperation did make a modified version, then it > would not match > > > Interested to hear other thoughts. This will still need some expert markup > attention!! > > > Jilayne > > > > -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2450): https://lists.spdx.org/g/Spdx-legal/message/2450 Mute This Topic: https://lists.spdx.org/mt/28502129/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Removing the Appendix from the canonical Apache 2.0 license
On Sun, Oct 7, 2018 at 9:15 PM Hen wrote: > Hi SPDX folk, > Over at Apache, I'm looking to remove the "How to apply" Appendix from the > canonical Apache 2.0 text and instead move that content to a FAQ. > I see this came up a few years ago ( > https://bugs.linuxfoundation.org/show_bug.cgi?id=1302 ) and it sounds like > this won't affect SPDX, but I wanted to let you know first before charging on > and making the change. > My thinking is to change the primary text, then send a note around to Apache > projects to encourage them to do the same over time. I imagine it will take > years before it's the norm not to have it, but that doesn't stop it being a > good thing to do. This section of the reference text is often enough customized by projects (including Apache's own projects) leading to quite a few too many variants of full license text in the wild so I am all for it. Would this shortened text then be called an Apache 2.1 license? ;) -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2396): https://lists.spdx.org/g/Spdx-legal/message/2396 Mute This Topic: https://lists.spdx.org/mt/26867657/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: CC NC/ND licenses and "general attributes of an 'open source' license"?
Mike: On Sat, Sep 29, 2018 at 9:45 PM Mike Linksvayer wrote: > I did not know license list candidates must have the general attributes of an > "open source" license, but I'm glad to learn of the requirement. > I wonder how the CC NC and ND licenses made it through (I searched the list > archives a bit and didn't come up with anything, probably due to my own lack > of search savvy or persistence), and whether those identifiers should be > deprecated? > Mostly this is idle curiosity on my part, please ignore if annoying. I can > live with incongruity. :) If I recall correctly: when we started we did add wholesale all the CC licenses without much discrimination. That's an incongruity that I can live with alright. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2386): https://lists.spdx.org/g/Spdx-legal/message/2386 Mute This Topic: https://lists.spdx.org/mt/26425511/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: explanation for ensuring no duplicate identifiers
On Fri, Jun 15, 2018 at 7:51 PM, Kate Stewart wrote: > > > On Fri, Jun 15, 2018 at 12:25 PM, Philippe Ombredanne > wrote: >> >> Alexios: >> good catch, though even printable may be too generous. A colon is >> printable and not a supported in a Windows file name for instance. >> >> Jilayne: >> We could/should more simply list the allowed characters and be very >> specific. >> Here is my suggestion: >> >> Allowed characters are ASCII: >> - Lower and upper case letters from A to Z. >> - Numbers from 0 to 9 >> - Dash '-', underscore '_', period '.' and plus '+' > > > need to be a little careful here Philippe... > > "+" is reserved for license expressions. I listed this because SPDX has issued ids that contained a + in the past. But that's minor alright! > Best to stick with what's in Appendix IV of the spec today > > idstring = 1*(ALPHA / DIGIT / "-" / "." ) > > where ALPHA and DIGIT are per definition in > https://tools.ietf.org/html/rfc5234 > > ALPHA = %x41-5A / %x61-7A ; A-Z / a-z > > DIGIT = %x30-39 ; 0-9 > > > > If you want to see "_" added, then probably should open an issue > against the spec for 2.2 and get it consistent tthroughout. I do not care much for the underscore. Good catch! -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2323): https://lists.spdx.org/g/Spdx-legal/message/2323 Mute This Topic: https://lists.spdx.org/mt/22189887/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: Google "Additional IP Rights Grant (Patents)"
Hi Kai:
On Mon, May 14, 2018 at 2:53 PM, Kai Koehne <kai.koe...@qt.io> wrote:
> Google uses a standard "Additional IP Rights Grant (Patents)" text in a lot
> of projects they've been publishing - {} sections are mine:
[...]
>
> Sources: https://webrtc.org/license/additional-ip-grant/,
> https://www.webmproject.org/license/additional/,
> https://github.com/ImageMagick/webp/blob/master/PATENTS,
> https://golang.org/PATENTS
>
> Does it make sense to add this to the list of Exceptions?
This makes a lot of sense to me.
We have been tracking these (see three variants below) in ScanCode and
DejaCode for quite a while:
-
https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/google-patent-license.LICENSE
-
https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/google-patent-license-webm.LICENSE
-
https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/google-patent-license-fuschia.LICENSE
The variants for Go and WebRTC look mostly the same.
However I do not think of these as exceptions, but rather as plain license(s).
--
Cordially
Philippe Ombredanne
+1 650 799 0949 | pombreda...@nexb.com
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: 3.1 release
Gary, On Fri, Mar 23, 2018 at 3:22 PM, <g...@sourceauditor.com> wrote: > It turns out we do maintain archived license lists, it just isn't very > well documented or publicized. > > There are also some formatting issues since older versions reference > some content which either isn't included in the archive or is not > longer in the same location online. > > Archived versions can be found at: > https://spdx.org/licenses/archive/archived_ll_v[version]/ > > Example: https://spdx.org/licenses/archive/archived_ll_v1.17/ > > We also produce a preview website before publication at > https://spdx.org/licenses/preview The preview availability is > typically published to the SPDX legal distribution list. As usual, you rock! So may be one small thing that would go a very long way would be to: 1. create a page that has links to the older versions of the LL page 2. link this "archives" page from the current LL version 3. link the previous version too 4. as a bonus possibly link the preview next when this is published and mostly ready before we switch over to final These links could be on the same line as the line that says: "Version: 3.0 28 December 2017" Something like : Current Version: 3.0 28 December 2017 - (previous version, versions archive, next version preview, ) What do you think? -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: 3.1 release
On Thu, Mar 22, 2018 at 12:22 PM, J Lovejoy <opensou...@jilayne.com> wrote: > I’m trying to get things nailed down for Gary to do the 3.1 release by end > of next week. > A few outstanding things that could go either way (resolved now via email > and included / or pushed to 3.2) - can I please get some input on these: One important thing (to me) that I am not sure I brought up yet: We are pushing new versions of the license lists but we are NOT keeping online the previous versions. They are only in git repos. I think it would help a lot adopters to have all the versions (at least starting with 2.6 and up) available online on the license list web page(s). This way users can point to the proper version of the list and licenses and update to use new versions of the list at their own pace. This would alleviate a lot of confusion or frustration that the V3.0 list did generate in the community when the A/L/GPL-X.X ids became deprecated. It could also make sense as a further refinement to publish a preview of a new version list for comments/heads up before it becomes the latest. All these would be to help users avoid surprises and possible confusion. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License Request: Linux-OpenIB
On Thu, Mar 22, 2018 at 11:47 AM, J Lovejoy <opensou...@jilayne.com> wrote: > ok, great, that’s what we merged already. done :) > > On Mar 22, 2018, at 12:21 PM, Dennis Clark <dmcl...@nexb.com> wrote: > > I think Linux-OpenIB is a perfect short identifier for this license. > > On Thu, Mar 22, 2018 at 11:15 AM, J Lovejoy <opensou...@jilayne.com> wrote: >> >> oh crikey, naming is so hard! The name is fine by me alright. Thank you all for pushing this through so quickly! And I updated ScanCode accordingly FWIW https://github.com/nexB/scancode-toolkit/tree/998-linux-openib-license -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License Request: Linux-OpenIB
Kate: Thank you for this excellent background and research! On Thu, Mar 22, 2018 at 8:50 AM, Kate Stewart <kstew...@linuxfoundation.org> wrote: > Provide a proposed Full Name for the license or exception > > Linux Kernel Variant of OpenIB.org license > > Provide a proposed Short Identifier. > > Linux-OpenIB > > Provide a functioning url reference to the license or exception text, either > from the author or a community recognized source. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/infiniband/core/sa.h FWIW, here is some extra information on usage of this license in these user-space packages beyond the kernel: - 470 occurences in libfabric https://github.com/ofiwg/libfabric - 246 occurences in rdma-core https://github.com/linux-rdma/rdma-core/ These may be better references than the kernel. Based on that, there could be an argument to have a different name / id than Linux-OpenIB as this is not entirely Linux-specific. The license is called BSD (MIT) at libfabric which is likely not a happy name. May be something like openfabrics-bsd may be a better name? NB: I feel very weakly about which name to pick, so feel free to ignore this entirely. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: GPL
Hi Till, On Tue, Feb 20, 2018 at 4:51 PM, Till Jaeger via Spdx-legal <spdx-legal@lists.spdx.org> wrote: > Hello! > > I had a look into the new version of the SPDX license list and I think it is > a good idea to distinguish GPL-2.0-only and GPL-2.0-or-later. > > However, I have not found the variant for: > > "If the Program does not specify a version number of this License, you may > choose any version ever published by the Free Software Foundation. " > > Shouldn't be an identifier (e.g. "GPL") for this situation? > > I did not follow your mailing list. I apologize if this issues has already > been discussed. IMHO the correct way to handle this is with a GPL-1.0-or-later: this means the same thing to me. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: EDL - Eclipse Distribution License
Wayne, Simon, On Thu, Dec 21, 2017 at 3:41 AM, Wayne Beaton <wayne.bea...@eclipse-foundation.org> wrote: > +1 > > How can I help make this happen? > > Wayne > > On Thu, Nov 23, 2017 at 6:04 AM, Simon Bernard <cont...@simonbernard.eu> > wrote: >> >> Hi, >> >> I would like to now if this could make sense to add the "EDL - Eclipse >> Distribution License" to spdx ? >> I ask the question because it seems this is a >> https://opensource.org/licenses/BSD-3-Clause. >> See : https://eclipse.org/org/documents/edl-v10.php >> But many eclipse projects use it and this could help to identify it >> quickly with tools like spdx. The problem with the EDL is that its text is strictly the BSD-3-Clause. The only differences would be: 1. an extra name that may not be present 2. possibly an Eclipse copyright holder IMHO these two are not sufficient to warrant a new license in SPDX. On the detection side, I used to have EDL as a "named" license in Scancode, but I removed it [1] a while back to use it as a plain detection rule instead: this was creating too many detection ambiguities as both the EDL and BSD would be detected exactly, because they are one and the same text-wise. So some questions: 1. Why would be using BSD-3-Clause a problem to you? 2. How can you distinguish at all times a BSD-3-Clause from and EDL? I would be happy to bring back a specialized detection in ScanCode if you can provide me with some non-ambiguous rules in which case you would have a license ref but not an official SPDX id. This may be good enough? [1] https://github.com/nexB/scancode-toolkit/commit/685a8b38b1f156793307a737e003ee5726a81c62 -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: CRYPTOGAMS
On Mon, Dec 4, 2017 at 11:01 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Hi Philippe, > > Thanks for your response. > > On Mon, Dec 4, 2017 at 10:58 PM, Philippe Ombredanne > <pombreda...@nexb.com> wrote: >> The way this is typically worded in OpenSSL and CRYPTOGRAMS would calls >> for this expression IMHO: >> OpenSSL OR (BSD-3-Clause OR GPL-2.0) > > That sounds fine to me. I'm further wondering - am I allowed to then > take the most restrictive of the three for my derivative work? That > is, in my own code, am I allowed to just write "GPL-2.0" and remove > references to the other two? Or do I still need the full expression > there in order to reference the original licenses which (maybe?) > require they be referenced? I am not sure what is your use case: for me I tend to always propagate the choices... so my knee jerk reaction would be to say: do not change anything! Here, this is clearly a choice of any of the three (rather than a choice that must be conveyed downstream) though it depends on "where you got the code from" ...so you might be able to pick anyone you like best but the details and specifics do matter a lot though! FWIW, if you elect to go "GPL-2.0" only that would be what we call a "concluded license" in SPDX -speak ;) -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: CRYPTOGAMS
Jason: On Mon, Dec 4, 2017 at 8:25 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Hey SPDX, > > A lot of older OpenSSL code is under the OpenSSL license, but the > author also provides it under GPLv2. Great. The SPDX identifier for > this is obvious. > > Faced with the multitude of requests for adding this GPLv2 exception > in the various interesting reusable files of OpenSSL, it appears that > the OpenSSL assembly pinball wizard, Andy Polyakov, wound up coming up > with CRYPTOGAMS. That looks like this: > > In the header of a particular OpenSSL file there is this text: > > # > # Written by Andy Polyakov <ap...@openssl.org> for the OpenSSL > # project. The module is, however, dual licensed under OpenSSL and > # CRYPTOGAMS licenses depending on where you obtain it. For further > # details see http://www.openssl.org/~appro/cryptogams/. > # > > Following the link to read the CRYPTOGAMS license leads to a 3-clause > BSD license with this text added on: > >> ALTERNATIVELY, provided that this notice is retained in full, this >> product may be distributed under the terms of the GNU General Public >> License (GPL), in which case the provisions of the GPL apply INSTEAD OF >> those given above. > > So, for using one of these files, how would I specify this in SPDX? > > Perhaps this: "OpenSSL OR GPL-2.0 OR BSD-3-Clause"? > > Or do we need to import the CRYPTOGAMS license and then specify: > "OpenSSL OR CRYPTOGAMS"? > > And then in the case of kernel code, take advantage of the GPLv2 > compatibility to write: > > "OpenSSL OR CRYPTOGAMS OR GPL-2.0"? > > Please do let me know what's best. The way I have treated the CRYPTOGRAMS licensing proper in the ScanCode toolkit is a set of rules for a choice of (BSD-3-Clause or GPL-1.0+) or (BSD-3-Clause or GPL-2.0) depending how this formulated in CRYPTOGRAMS. I am not sure this warrant a new license id. And with OpenSSL when used in combo with OpenSSL. > Perhaps this: "OpenSSL OR GPL-2.0 OR BSD-3-Clause"? The way this is typically worded in OpenSSL and CRYPTOGRAMSwould calls for this expression IMHO: OpenSSL OR (BSD-3-Clause OR GPL-2.0) -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: EDL - Eclipse Distribution License
On Tue, Nov 28, 2017 at 3:32 PM, Simon Bernard <cont...@simonbernard.eu> wrote: > Hi, > > I would like to now if this could make sense to add the "EDL - Eclipse > Distribution License" to spdx ? > I ask the question because it seems this is a > https://opensource.org/licenses/BSD-3-Clause. > See : https://eclipse.org/org/documents/edl-v10.php > But many eclipse projects use it and this could help to identify it > quickly with tools like spdx. Simon: I think this has been discussed in the past: this is exactly a BSD-3-Clause. The only difference is that Eclipse gave it a name. Since this is the same it did not need to have its own ID. For instance in the scancode-toolkit (which the Eclipse Foundation uses for IP due diligence BTW) I used to have an entry for EDL separate from the BSD. This was leading to randomly returning one or the other at times and looking really ugly because again they are not distinguishable. I dropped the EDL then. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode - What's in your code?! - http://www.dejacode.com AboutCode - Open source for open source - https://www.aboutcode.org nexB Inc. - http://www.nexb.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: update on only/or later etc.
On Mon, Nov 27, 2017 at 5:55 PM, Wheeler, David A <dwhee...@ida.org> wrote: > No tool can guarantee that always determines if "or any later version" > applies. > Certainly not licensee, which is the tool used automatically by GitHub. > Indeed, licensee generally only looks at the LICENSE file - it doesn't even > *try* > to parse the README file (which it could only do imperfectly anyway). > > Oh, and for many developers, the license output from licensee is the *only* > SPDX data they'll see, because GitHub does that analysis automatically for > them > when they view a project (they don't have to run a tool). I'd love to see > licensee improved, but most developers have ZERO interest in all the details > of a SPDX file anyway; they just want the license expression, and that's it. > In many places, the *developers* choose the libraries that will be used; > there are no lawyers to double-check anything. OK, so GH licensee does not even make a serious attempt at providing accurate information and instead returns half-baked partial license information. Despite all the good intentions, I find it quite irresponsible to then promote this tool globally on a site with such a viewership. If this were a C compiler this would akin to say: I will ignore the function definitions from your header .h files. Once in a while I will compile a program that may run, though it may not run as you expected. Often I will crash and now and then I will just destroy your hard drive. But bear with me and use me anyway, I am "good enough". I just hope none would use such a tool to further propagate this half-baked misinformation when better tools exist out there. I am all for "good enough" but good enough is only good enough when there is at least __enough of the good__: otherwise this is counterproductive and dangerous especially when widely promoted. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: this likely calls for a new L/GPL "exception"?
On Mon, Nov 27, 2017 at 9:56 PM, Bradley M. Kuhn <bk...@ebb.org> wrote: > Michael Dolan wrote: >> +1, I would also add that these are external and unilateral declarations >> of additional permissions. > > I agree that declarations of additional permissions made outside of a > codebase are a different issue for SPDX, in large part because SPDX's most > common use case is source code scanners that only look at codebases. Bradley, FWIW, as a tool smith, I have no technical issue with combining the license and copyright holder scans and therefore returning a GPL + rider license if the holder is offering such a rider. It can even be one rider per holder. That's a very easy one and that would likely be the only clues needed for such determination. A similar logic applies to the infamous BSD-4-Clause: if the copyright is from the UC Regent, then the 4th clause has be rescinded and this is equivalent to a 3 clause aka. a BSD-4-Clause-UC. Otherwise, it is a regular 4 clause. The only different between the two is the copyright holder. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: this likely calls for a new L/GPL "exception"?
On Mon, Nov 27, 2017 at 8:37 PM, Richard Fontana <rfont...@redhat.com> wrote: > On Mon, Nov 27, 2017 at 11:04:15AM -0800, Bradley M. Kuhn wrote: >> As I understand Richard's reasons, they relate to license documents that >> *don't* appear in a source code repository, which is the case for the Google >> and Red Hat statements today. > > Right. I can't really see a justification for creating SPDX > identifiers to represent purely external statements. Richard, say I am a user of 5,000 packages. Some of which come with this L/GPL rider, some not: I could see some value there. But then again, it may be a point minor enough that this may not be worth tracking in SPDX. And of course very few reuse 5,000 packages, right? Yet in fact several small to mid-size container-based deployment reach this number very quickly. Add a few npm/node-based apps in the mix and you top that number even faster in practice. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: update on only/or later etc.
David: You are bringing good points. Here are my counter points: On Fri, Nov 24, 2017 at 5:15 PM, Wheeler, David A <dwhee...@ida.org> wrote: > Philippe Ombredanne: >> I think there is no contention there at all. > > Respectfully: There *IS* contention. I'm contending. > >> A summary (e.g. a license expression) cannot ever capture all the nuances >> of the details This is a lossy "compression" by construction... > > Sure, but all summaries, and all models, omit something. Indeed, > a SPDX license file *also* cannot capture all the nuances. > > The correct question is, "is this model adequate for its uses?" > In most cases people want to know, "is this package legal to use?". You are making assumption about what the common use case might be. To me the common use case is more simply: what's the license? Whether this is "legal" or not is something you or your legal adviser can decide based on this. And practically, "legal" is more often than not a policy choice instead, whether you are a FLOSS project author or a consumer of FLOSS code. > To answer that question, "it's at least GPL-2.0, and might be more" > s important information, and I think it's information that the SPDX > license expression should include. Is this really important to know this fact in the general case? In my own experience the cases where I need hyper precision on GPL-2.0 vs GPL-2.0+ are rather limited: 1. I am combining GPL 2 and GPL 3 code 2. OR I want to use a GPL 3 for GPL 2-licensed code These cases are extremely rare for consumers of FLOSS code based on my reasonably wide and many of experience in this space... So rare in fact that they account for a handful across thousand+ products and billions of LOC. So rare that I cannot recall of any OTH. In each cases they require careful legal review before making a decision. Making this careful decision solely on the few characters of a license expression would be insanely foolish IMHO. I am not sure SPDX needs to worry or cater about this. In every other case, the GPL2 vs GPL2+ debate does not matter much as this is still the same GPL terms that apply: same permissions and same obligations. >> Speaking as the author of a fine license detection engine, I think this is a >> red herring. >> A license detection result can be: "I am 95% sure this is GPL-2.0-only but it >> could be GPL-2.0+: please review me to fill in your conclusion." > > This inability to indicate the "in-between" state within a license expression > greatly increases the number of cases where an unnecessary review must occur. > Every unnecessary review is a significant increase in time and money. > In many cases, it's *NOT* necessary to make a decision, but in some cases it > is. > If organizations can do the analysis *ONLY* when they need to, > they'd save a lot of time and money... and that is greatly aided by > having SPDX license expressions able to indicate this information. Again, the cases where you need precision vs. good enough accuracy in the GPL2/GPL2+ debate are rare. 99% of the time, you do not need this precision at all. Now, I could not agree more with you: inaccurate and clear licensing information means that a user will need to review this to ensure this is clear. But this is NOT a problem for SPDX to solve in the license expression spec. This is something that needs to fixed by working with every project author such that there is clarity such as the work Kate and I have and are doing with Linux maintainers to make the kernel licensing hyper clear. Or the tickets I routinely file with projects that lack a clear license. That's solving the problem IMHO: e.g. let's react to the symptoms, but attack the root cause instead. And there SPDX and license expression are a great way to make things clear upstream once reviewed. There are not a substitute to a review. FWIW, having an initiative to systematically help projects authors clarify licensing is something that I have had in mind for quite a while. I may do something about it eventually. >> So detection does not have to be binary as in either 100% right or 100% >> wrong. If a tool can only report red or blue binary results, that's a >> possibly >> fine but weak tool. > > But that's what I'm saying. Most tools CAN provide more than 2 answers. > The problem is that the SPDX license expressions don't allow tools to report > more than the 2 answers within a license expression. So the tool doesn't have > to give a binary answer, but SPDX forces the tools to do so when they output > SDPX license expressions. I can output more than one expression then, can I? >> For instance scancode-toolkit can cope with ambiguity alright and surface >> this for review when it cannot come with a definitive detection
Re: "unclear version" and OR-MAYBE operators (was: update on only/or later etc.)
On Wed, Nov 22, 2017 at 6:51 AM, W. Trevor King <wk...@tremily.us> wrote: > On Tue, Nov 21, 2017 at 08:10:02AM -0700, J Lovejoy wrote: >> Just a reminder to all: when someone places a copy of the GPL, >> version 2 alongside source code files this does not make the >> licensing ambiguous; clearly there is a valid license… >> [...] > So I think > there is likely to be a substantial set of license-expression authors > who are unwilling to claim a complete conclusion. Is this point still > under contention? I think there is no contention there at all. A summary (e.g. a license expression) cannot ever capture all the nuances of the details This is a lossy "compression" by construction... > If we accept a substantial set of partial-concluders, the SPDX needs > to decide what to suggest to them. Folks using SPDX documents can > already use comment sections, but those are unstructured [3]. And > folks using bare license expressions obviously don't have access to > the SPDX-document comment field. ... therefore your input is valuable and well thought out but none of this extra complexity is needed. An expression can be in some case not fully conclusive: when this happens this information can be provided in an SPDX doc elsewhere such as notes or else as you rightly noted. Folks using only license expression are typically using them in another context which is to document their own code or package license: there is no ambiguity there and therefore no need to add extra complexity to capture something that does not exist. In some cases such as here, perfect is the enemy of the good. Please, let's try to keep this spec simple! -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/
On Fri, Oct 20, 2017 at 9:20 AM, Fendt, Oliver <oliver.fe...@siemens.com> wrote:
> great to see this direction of development.
> This will are least clarify all the files which carry nothing expect the Marko
> MODUL_LICENSE("GPL");
> Because one of the interesting questions is "is this a legally binding
> expression
> of licensing?"
The MODULE_LICENSE macro used in the kernel is a clear license statement.
And better than a terse "Copyright (c) John Doe, GPL" that is seen in
the kernel
since there is a clear documentation of its meaning in the kernel's
module.h [0] :
* The following license idents are currently accepted as indicating free
* software modules
*
* "GPL" [GNU Public License v2 or later]
* "GPL v2" [GNU Public License v2]
* "GPL and additional rights" [GNU Public License v2 rights and more]
* "Dual BSD/GPL" [GNU Public License v2
* or BSD license choice]
* "Dual MIT/GPL" [GNU Public License v2
* or MIT license choice]
* "Dual MPL/GPL" [GNU Public License v2
* or Mozilla license choice]
*
* The following other idents are available
*
* "Proprietary" [Non free products]
[...]
So MODULE_LICENSE("GPL") means clearly "GNU Public License v2 or later"
and nothing else. I cannot comment on whether such a license statement would
be legally binding or not, but at least there is no ambiguity about
what this means.
And IMHO this is as good as an SPDX license identifier and as good as it gets
short of any other licensing indications.
Since the MODULE_LICENSE is only for kernel modules, there was a need
for something that could be applied elsewhere, hence the use of SPDX
identifiers. Note that there were talks to use a macro instead of a comment.
It may come back in the future as it would have the added benefit to inject
license ids in the built binaries (the same way a MODULE_LICENSE ends
up in a built LKM)
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n172
--
Cordially
Philippe Ombredanne
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal
Fwd: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/
FYI: In case you missed it: SPDX identifiers have landed in kernel land... Read the whole thread at https://patchwork.kernel.org/patch/10016189/ And as a side effect, some new patches elsewhere are coming in with SPDX identifiers right in! -- Cordially Philippe Ombredanne -- Forwarded message -- From: Greg Kroah-Hartman <gre...@linuxfoundation.org> Date: Thu, Oct 19, 2017 at 10:38 AM Subject: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/ To: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org, Thomas Gleixner <t...@linutronix.de>, Kate Stewart <kstew...@linuxfoundation.org>, Philippe Ombredanne <pombreda...@nexb.com> It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. This patch adds these identifiers to all files in drivers/usb/ based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner <t...@linutronix.de> Cc: Kate Stewart <kstew...@linuxfoundation.org> Cc: Philippe Ombredanne <pombreda...@nexb.com> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- Unless someone really complains, I'm going to add this to my tree for 4.15-rc1. diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 9650b351c26c..cb8d902b801d 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -1,6 +1,7 @@ # # Makefile for the kernel USB device drivers. # +# SPDX-License-Identifier: GPL-2.0 # Object files in subdirectories [] long diff of 600 files removed for brevity... ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: OpenJ9 license
On Thu, Oct 12, 2017 at 11:32 AM, Wayne Beaton <wayne.bea...@eclipse-foundation.org> wrote: > My understanding is that the Secondary Licensing provision in the EPL-2.0 is > not the same as dual licensing using an OR. From our FAQ (which we're still > working on): > >> The notion of Secondary Licenses is intended to permit combining content >> licensed under the EPL-2.0 with an otherwise incompatible license, >> specifically the GNU General Public License, v2.0 or greater. This means >> that the content that includes a Secondary License clause may be combined >> with content distributed under the terms of that Secondary License, and the >> combined content can be then be collectively distributed under the terms of >> that Secondary License. > > Further, > >> Is EPL-2.0 with the Secondary License clause considered dual licensing? >> It is extremely close to dual licensing. The EPL-2.0 is the only license, >> until such time as it is combined and distributed with a work under the >> Secondary License. After such time, any recipient of the combined work can >> consider the content licensed under the Secondary License. The original work >> remains under the EPL-2.0 and is never really dual-licensed. Once a >> downstream adopter has received the content under the Secondary License, >> they can modify and further distribute it solely under the terms of the >> Secondary License. > > Does this help? > > I hope to make our FAQ public later today or earlier tomorrow. That may > provide further context. Wayne: This helps a lot to better understand the EPL terms. My understanding: I cannot use EPL 2.0-licensed code under a Secondary license unless I combine it with some other code using that Secondary license. And only its is only when I combine that the Secondary license terms may apply to the combo. Otherwise, only the the EPL-2.0 applies. My take is that a license expression can never replace nor capture all the specific details of licensing. This what the license texts are for. The license expression is just a concise, imperfect but mightily handy summary of the licensing. Therefore, even though this may not be it exactly, I still think we can use existing license expressions OR constructs for this case and with no change needed. An expression such as EPL-2.0 OR GPL-2.0 is enough to tell me there is some choice. Then when I read the actual text and notice, I get the details and specific terms. If I elect the GPL-2.0 choice without reading the licensing first then I am foolish at best. We cannot prevent foolishness. If I build a tool that automates such a choice, I can easily have a special case where the EPL-2.0 shows up as a choice with another license and process this as a special case. Be it here or in the much-talked-about case of FSF or-later-or-only-or-may-be licensing nuances, an expression can never entirely replace the actual license texts and notices. I think this is just fine this way: a name alone can never capture nor convey all the nuances and attributes of a thing. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: [v2] New license proposal: GNUVerbatim
On Tue, Sep 26, 2017 at 2:22 PM, W. Trevor King <wk...@tremily.us> wrote: > Discussion spawned by my v1 Verbatim proposal [1] seems to have died > down, so here's a v2. Changes since v1: > > * Renamed from ‘Verbatim’ to ‘GNUVerbatim’ to allow for other verbatim > names in the future (e.g. if someone wants to register [2] as > GNUVerbatimWeb [3] or wants to register non-GNU verbatim license). > * Suggested tags to match the wording used by the GNU CC General > Public License [4,5] or non-license documents. > > # Motivation > > The GPL family of licenses (e.g. [6]) and some other documents > (e.g. [7]) are licensed under a verbatim license (canonical text > attached). The GNU CC General Public License (1988) was also released > under very similar language [4]. I propose we add this license with > markup like: > > …copies of this license document, but … > > so we can express all of those closely related licenses with the > GNUVerbatim short ID without resorting to custom LicenseRef-*. Trevor: Is this a joke or are you seriously suggesting that you want to track the license of licenses? Would there not be a risk of infinite recursion!? e.g. your GNUVerbatim license license should be what then? GNUVerbatimVerbatim? or would it instead self-reference itself in some strange loop? -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: EPL-2.0
On Tue, Aug 22, 2017 at 2:52 AM, Wayne Beaton <wayne.bea...@eclipse-foundation.org> wrote: > The EPL-2.0 has been approved by the OSI and the Eclipse Board of Directors. [...] > The wrinkle, I think, is that there is a provision in the license for > "secondary license" support. A project team may opt to declare that their > project code is GPL compatible. I believe that this means that GPL > compatibility is an exception; this is compounded by the ability to include > various exceptions to the GPL. > > The OpenJ9 project, for example, will be EPL-2.0 with GPL-2.0+CPE+AE. I > think that this would manifest something like this: > > EPL-2.0 WITH (GPL-2.0 WITH Classpath-exception-2.0 WITH > Assembly-exception-2.0) > > I'm a little concerned that I don't see Assembly-exception-2.0 on the > exceptions list. I assume that this means that I'll have to shepherd this > exception through as well. > > Is this syntax even supported? Hi Wayne! This syntax is not supported but I do not think this is what you want nor need exactly. Reading the EPL 2.0 I see: > Exhibit A – Form of Secondary Licenses Notice > "This Source Code is also Distributed under one or more Secondary Licenses, So what this mean is that the EPL 2.0 allows an explicit choice of licenses. The syntax for choices is an "OR". When this happens and such an Exhibit A offer this choice, you can use instead something like: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0 Assuming you want two exceptions, this is not yet supported but this could be easily supported IMHO when several exceptions are used: EPL-2.0 OR (GPL-2.0 WITH (Classpath-exception-2.0 AND Assembly-exception-2.0)) Or if you always use these two exceptions as a combo it could be best to either create a license ref or a new exception combo of the two: EPL-2.0 OR GPL-2.0 WITH OpenJDK-exceptions In any case this would never be EPL-2.0 WITH GPL-2.0 IMHO as we have a choice. As for this http://openjdk.java.net/legal/assembly-exception.html we likely need a new license id. The other thing is the Classpath-exception-2.0 and Assembly exception seem to be very closely related. When I read this http://openjdk.java.net/legal/exception-modules-2007-05-08.html the Assembly Exception references the Classpath exception profusely just to muddy things a bit more: so they seem intimately tied at the hip. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: License checking tool available
On Fri, Aug 4, 2017 at 7:14 PM, Alan Tse <alan@wdc.com> wrote: > Will there be an option to use fuzzy matching showing the differences? > While it’d be nice if licenses exactly matched, the concern would be if we > had something that almost completely matched. You mentioned other tools > that report close matches, but I wasn’t aware of any that did that for the > SPDX license list. The scancode-toolkit reports exact and approximate matches for all SPDX licenses (and a few more licenses). It also can collects the matched texts and report the scans either as SPDX or JSON. See https://github.com/nexB/scancode-toolkit Note: I am its maintainer. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: License checking tool available
On Fri, Aug 4, 2017 at 6:46 PM, <g...@sourceauditor.com> wrote: > An online tool for checking license text against the SPDX license list is > now available at https://spdx.org/spdxweb The URL redirects to a server > generously provided by the Openchain project team. > > The tool basically compares the text to all SPDX listed licenses using the > license matching guidelines. If a license does not completely match per the > guidelines, it will not e displayed. This is quite different from many > other tools that report close matches where only a few words may be > different. > > There are a few limitations. The software uses the templates in the listed > license for the currently published version. In the currently published > version, there are several licenses with limited or no template markup (e.g. > the MIT license). For these licenses, the text will only match if all of > the text is present. If you believe text should match the license, take a > look at the license list web page for that license and review for red text > (replaceable) and blue text (omitable). > Gary: I tried to paste the verbatim text of https://www.gnu.org/licenses/agpl.txt and its is not matched Do you think this a code or a matching guidelines issue? -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New OSI approved license (BSD+Patent)
On Thu, Jun 1, 2017 at 11:34 PM, Smith, McCoy <mccoy.sm...@intel.com> wrote: > The text for this license is BSD 2-clause, plus a patent grant. > The patent grant is based primarily on the Apache 2.0 patent grant, > with some language from the Eclipse patent grant, and some relatively > slight modifications for clarity and to make it all fit together. Thank you. Out of curiosity would you have a pointer to actual usage of this license in the wild? -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
The problem with the Sleepycat license is that its not one, but three licenses.
Dear legal eagles [1]: I think that the text for the Sleepycat license [2] is not correct. The text is rather historical version of the BerkeleyDB aggregated licensing (which is now AGPL-licensed FWIW) with three licenses : - Sleepycat proper, and - Two "BSD-3-Clause" licenses. I suggest to trim the Sleepycat text to Sleepycat proper only. When the three licenses are found, a proper license expression can be used alright. Alternatively another "Spleepycat-only" kind of license could be created just for the Sleepycat text proper. [1] http://www.urbandictionary.com/define.php?term=Legal%20Eagle [2] https://spdx.org/licenses/Sleepycat.html -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request
> On Mon, Sep 19, 2016 at 8:14 PM, Sébastien Règne <reg...@gmail.com> wrote: >> I propose to add the license Rien À Branler, that is the official French >> translation of WTFLP v2. >> Full Name : Licence Publique Rien À Branler >> Short Identifier : LPRAB >> Website : http://sam.zoy.org/lprab/ >> OSI-approved : No >> Program that uses this license : https://github.com/regseb/scronpt On Tue, Sep 27, 2016 at 4:14 PM, Sam Ellis <sam.el...@arm.com> wrote: > My initial question is, is this really a different license that requires > different identification, or is it just a variant of the existing WTFPL and > should be identified the same? This seems a grey area, since it may depend > on the quality of the translation and how official the translation is. > > However, I think there is a reasonable case to make this a separate license. > For instance, the website already uses the identifier LPRAB and it also has > a different version number from the original. > > What do other people think? Sam: I have several issues with this "notice": 1- this is not a license: the way I read this text in contrast with its English counterpart the terms would apply **only to its own license text** and not to any software that would include this text: software using such a notice would be about the same as not being licensed at all and no right would be granted beyond modifying the license text: I cannot see this as having the general attributes of an "open source" license and I would at best treat this as a problematic proprietary notice. 2- I do not see it as notable and significant. This is not "in common use" in my book. For instance the only NPM packages using this are Sébastien's own. I think this group should neither condone nor endorse vanity or prank licenses explicitly or implicitly. 3- the profanity used has a different meaning and I would not consider it as gender neutral (in contrast with its English counterpart) which makes it more offensive. I think this group should neither condone nor endorse offensive licenses explicitly or implicitly. In addition, several package managers now use the SPDX list to validate the license of an uploaded package and either reject the package or issue a warning if the license is not in the SPDX list: I think issuing a warning in this case is a good thing as I interpret this text as granting no software usage right whatsoever. Therefore I think this group should reject adding this notice to the SPDX list. And if this is really an official translation, then there is nothing to do here anyway. And finally: Sébastien: if you have "RAB", why should this group GAF [1] ? My 2 cents: you should consider seriously using some common licensing that actually grants some usage rights unless --as your license choice may suggest-- you do not care at all that none would be allowed to use your code. [1] http://www.urbandictionary.com/define.php?term=GAF -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Software Package Data Exchange (SPDX) specification for Public Domain, Government Works? Possible New License/Exception Request
On Fri, Apr 15, 2016 at 4:23 PM, Wheeler, David A <dwhee...@ida.org> wrote: > Gisi, Mark: >> The absence of Public Domain from the license list was not an oversight. A >> fair amount of discussion took place to decide how to handle a public domain >> designation. The current practice is to create a LicenseRef (a user defined >> license reference that is local to an SPDX file). > > I think that public domain designations should be handled *exactly* the same > way by SPDX as all other common licenses - just create SPDX license > identifiers for common ones. +1 -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Software Package Data Exchange (SPDX) specification for Public Domain, Government Works? Possible New License/Exception Request
On Thu, Apr 14, 2016 at 11:12 PM, Robinson, Norman <robins...@state.gov> wrote: [...] > While it could be argued UPL or public domain or CC0 1.0 > (creativecommons.org/publicdomain/zero/1.0/) (SPDX CC0-1.0) does that, I > believe citing the reasoning it is public domain, because it is a US > Government work, will be most important to agencies who are also trying to > communicate they deliberately and with intent placed it is the public > domain, versus someone making the claim they were working on the project, > had a copy, or assert it wasn’t work for hire, or covered by contract > agreement on a government contract. I think that the US Government public domain dedication is rather unique. Are there any other countries doing it? Having a standard license reference to encourage its normalization would be awesome. -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode : What's in your code?! at http://www.dejacode.com nexB Inc. at http://www.nexb.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Software Package Data Exchange (SPDX) specification for Public Domain, Government Works? Possible New License/Exception Request
On Tue, Apr 12, 2016 at 7:19 PM, Robinson, Norman <robins...@state.gov> wrote: > Greetings! > > In review of SPDX specification (spdx.org/), I’m not seeing a clear > annotation for U.S. Public Domain. Could you please clarify if such a > license currently exists and I have failed to understand or find it? Any > links or clarification appreciated! > > As a federal government employee involved with open source projects, I would > like to understand if we can have a SPDX license for public domain or > government works to better enable federal agencies to contribute code and > make the licensing and copyright clear. There is currently an efforts to > renew support for custom software code (sourcecode.cio.gov/)to ensure all > government produced works are clearly promoted and licensing is required to > be open source. Having a license targeted at public domain, or specifically > referencing government contribution, might promote and encourage open source > licensing. > > As you may be aware, for federal employees and most government agencies, the > copyright is simply “This is a work of the U.S. Government and is not > subject to copyright protection in the United States. Foreign rights may > apply.” that falls into the public domain. In terms of operational > knowledge, that is also affected by the government contract with vendors, > and how the rights are asserted and assumed. Reference: > www.cendi.gov/publications/04-8copyright.html; > www.acq.osd.mil/dpap/dars/dfars/html/current/252227.htm. It seems this new > initiative – although one could simply state it is related to government > failing to clearly mark contracted works as public domain – is to > specifically assign an open source license approach, to assert specific > copyright as the law allows agencies to do for specific needs. In this case, > I pull that rationale from the linked sites as the need to “enables Federal > employees to work together—both within and across agencies—to reduce costs, > streamline development, apply uniform standards, and ensure consistency in > creating and delivering information.6 Enhanced reuse of custom-developed > code across the Federal Government can have significant benefits for > American taxpayers, such as reducing Federal vendor lock-in,7 decreasing > duplicative costs for the same code, increasing transparency across the > Federal Government, and minimizing the challenges associated with > integrating large blocks of code from multiple sources.” This is awesome! > I’m happy to make a recommendation on the SPDX format, if you care to > respond and let me know if there have been additional discussions on this > topic to be considered, if an existing license is recommended, or if in > review you agree there is a need for such a specification. This would be great and makes a lot of sense to me. Getting this as a license in the list would mean consistency and simplicity both for the agencies releasing code and for their recipients. I have seen various ways Federal agencies handle this such as the NIST in [1] (ignoring the funny Untied States typo). At the minimum I would in much favor to have a license identifier for a generic dedication to the public domain beyond the existing Creative Commons CC0. Alternatively I have seen projects use a choice of a custom dedication or CC0 such as in [2]. This helps deal with some countries (Germany? ) that do not recognize public domain and is not incompatible with having an id. Legal mavens, what's your take? [1] https://java.net/projects/jsip/sources/svn/content/trunk/src/gov/nist/javax/sdp/MediaDescriptionImpl.java?rev=2364 [2] https://github.com/search?q=cc0+public+domain+jurisdiction=Code -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: SPDX License List v2.4 released
On Tue, Apr 5, 2016 at 11:08 PM, Gary O'Neall <g...@sourceauditor.com> wrote: > Greetings all - The site has now been updated with conforming HTML. Thank you Gary. That was quick! -- Cordially Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode : What's in your code?! at http://www.dejacode.com nexB Inc. at http://www.nexb.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: BSD-3-Clause-NoNuclear
On Thu, Mar 31, 2016 at 2:07 PM, dmg <d...@uvic.ca> wrote: > > On Thu, Mar 31, 2016 at 7:55 PM, Tom Incorvia <tom.incor...@microfocus.com> > wrote: >> I see this license all the time. Let’s put it on the list. > > What about we start with some empirical evidence, rather than anecdotal. > Can you quantify what "all the time" means? How about ~ 6000+ pages on Google [1] and ~ 90.000+ files in Github [2]? [1] https://www.google.com/search?q="intended for use in the design%2C construction%2Coperation or maintenance of any nuclear facility" [2] https://github.com/search?q="intended+for+use+in+the+design%2C+construction%2Coperation+or+maintenance+of+any+nuclear+facility"=Code -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: New License/Exception Request: BSD-3-Clause-NoNuclear
On Thu, Mar 31, 2016 at 12:55 PM, Tom Incorvia <tom.incor...@microfocus.com> wrote: > I see this license all the time. Let’s put it on the list. Agreed for me: this should be in either as a license or an exception > There are many licenses on the SPDX list that do not strictly meet the FOSS > rules – if we restrict to pure FOSS licenses, we limit the value of the SPDX > list. > It’s about value, not FOSS purity. I agree ++ and practicality beats purity. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Is "+" a valid character of a LicenseRef idstring?
On Tue, Nov 3, 2015 at 3:45 AM, Wheeler, David A <dwhee...@ida.org> wrote: > Philippe Ombredanne wrote: [...] >> You say: >> GPL-2.0 ==> implies GPL 2.0 only >> GPL-2.0+ ==> implies GPL 2.0 or later > That's not just what I say. That's what the spec says, and has > clearly stated since circa 2010. > This would have been a useful argument to raise in 2010 (when SPDX was > drafted). But this group doesn't exist to create a new spec where > none has existed. For more than 5 years SPDX has consistently stated > that "GPL-2.0" means ONLY GPL-2.0 and nothing else. This builds on > previous history of Fedora and Debian, who also use "+" this way, > e.g., see: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing David: I know this as I was part of it and that does not make it more right ... FWIW, I have been around SPDX for quite a while ;). See "A Short History of SPDX": https://spdx.org/about-spdx/what-is-spdx > While I know you're focusing on the GPL, there are many other > licenses, and most licenses do NOT have a "this or later version" > clause; The focus is not only on the GPL: well over 25% of the SPDX licenses DO HAVE a "this or later version" clause. Here are some examples: - Most of the FSF licenses: The GPL and LGPL and all their versions. But also the AGPL, the GFDL, etc. - all the Mozilla-like license: NPLs, MPLs and all the MPL derivatives such as SPL, CPAL, Erlang, RPL, APSL, Gsoap, ZIMBRA, SISL, etc. - most of the Creative Common licenses, - The Eclipse licenses and the CPLs, - the CDDLs, - the PHP license, - OpenLDAP, Latex/LPPL, LPL, Condor, CATOSL, RPSL, CECILL, etc. For all SPDX licenses allowing other versions, the bare identifier means "or later version", except for the L/GPL where this means "only the current version" unless you create an expression with a "+". So the decision procedure to use a plus or not is roughly like this: If licensing allows to use "other license versions": - If and only if GPL or LGPL, add a + to the license identifier. "other license versions" is NOT implied. - Otherwise, if this not GPL or LGPL, do NOT add a +. "other license versions" is implied if the license allows such thing. Do this ONLY for any versions of these two licenses. Do not apply this approach to other FSF licenses such AGPL, GFDL and others. - Except if you are a Linux packager for Debian or Fedora and their derivatives, because then you may use the + for other FSF licenses beyond the L/GPL. The + is already used with GFDL, AGPL, etc. Do not use a plus for non-FSF licenses that have an "or later" clause. If licensing does NOT allow to use "other license versions": - If and only if LGPL or LGPL, use the bare license identifier. "no other license version" is implied by a bare id. - Except if you are a Linux packager because you apply the same approach for other FSF licenses. - If this is another license, then? "other license version" IS implied in a bare id here. SPDX does not help you there, and you could create an exception.This is a rare case anyway. > having the default be what's common in MOST licenses is > actually sensible. This is exactly my point. The common sense and default usage for L/GPL is ". And Linux distros and SPDX have made the default "or later" exceptional and the less common "only" exception the default. So how to resolve this situation? In the grand scheme of things, "only" and "or later" are minute technicalities that the large majority of software users do not care for. The licenses requirements are essentially the same and "later or not later" is not the question. Only a few licensing mavens care about this and they know how to deal with it. But SPDX is likely stuck with this inconsistent legacy and yes this is hard to escape without creating more mess. It does not mean that we cannot try to clarify and improve things. First we need to distinguish two types of licenses allowing "other versions": a. FSF licenses such as the A/L/GPL. These are the only licenses were a plus + convention has been used by Linux distros and SPDX with some consistency. b. Non-FSF licenses. I cannot find cases where the plus + convention has been used in the wild or with SPDX for these. Some ways out could include: Option 1. Do mostly nothing. - Keep the status quo and clarify the current ambiguities: We document the procedure I described above and move on. We accept this is a mess and make it a documented mess. This is an OK option. And requires little or no work. Option 2. Change the meaning of every bare license id that allow "or later" to mean "this version only". FSF or not FSF. No change of
Re: Is "+" a valid character of a LicenseRef idstring?
>> On Wed, Oct 28, 2015 at 10:28 AM, Schuberth, Sebastian wrote: >>> when debugging an issue in the spdx-tools verifier, I noticed the >>> SPDX 2.0 specs seem to be inconsistent on whether "+" is a >>> valid character in a LicenseRef's idstring, like in LicenseRef-[idstring]. > I wrote: >> I not see any reason why a + would not be allowed in a reference, and >> there is no ambiguity since the + always something attached to an id or >> ref string, not some free standing symbol. On Mon, Nov 2, 2015 at 7:02 PM, Gary O'Neall <g...@sourceauditor.com> wrote: > In the 2.0 spec, the + is a unary operator with a specific meaning > (see Appendix IV of the 2.0 spec "Simple License Expressions" subsection > page 82). If we are to use it as an operator with License Ref's, it would > be difficult for a parser to determine when it is part of a reference string > and when it is intended as an operator. This + is a suffix and not a freestanding character, right? So "GPL-2.0+" is valid but "GPL-2.0+" would not be valid? In this case there would be no issue to have a plus as part of a licenseref: there is no possible ambiguity. Then again we would be better off to get rid of the plus entirely! -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Is "+" a valid character of a LicenseRef idstring?
On Wed, Oct 28, 2015 at 10:28 AM, Schuberth, Sebastian <sebastian.schube...@here.com> wrote: > when debugging an issue in the spdx-tools verifier, I noticed the SPDX 2.0 > specs seem to be inconsistent on whether "+" is a valid character in a > LicenseRef's idstring, like in LicenseRef-[idstring]. I not see any reason why a + would not be allowed in a reference, and there is no ambiguity since the + always something attached to an id or ref string, not some free standing symbol. But this raises a larger question which I am sure has been debated in the past: Using a + is a whart. Licenses that allow the use of other versions do so explicitly in their texts, the GPL being the most prominent but the EPL comes to mind too. So there is no such thing as GPL-2.0 or another version: these are the plain default GPL terms. If I do nothing special, the GPL version I picked or any other later version can apply. I need to go the extra mile to state that only this version applies and no other version. I need to add a specific statement to that effect. Actually if I only state my code is GPL-licensed without indicating a version the GPL says that a recipient can pick *any current or future version* So to me it is an exception to the GPL-2.0 (or 3) to disallow the use of other versions. A fairly common exception because it is used in the kernel and that likely led to this flawed but widely spread approach to be adopted by Linux distros. And later adopted by SPDX. Essentially GPL-2.0 and GPL-2.0+ mean exactly the same the thing. The plus is redundant and confusing. To be truly correct, every single occurrence of the GPL that does not disallow later versions should have a plus. It does not make sense to treat the non-default exceptional case as the default. Fixing this in SPDX would mean to deprecate + entirely, and add an exception that would disallow other or future versions such as "only". Or change the meaning and the text of the GPL-2.0 to be some notice that states this means the GPL-2.0 applies only and no other version. And replace the GPL-2.0 id by a GPL-2.0+ id where the text is the actual full text. Any thoughts? PS: I am cross-posting to the legal list as this is ultimately there that it should be resolved IMHO. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Is "+" a valid character of a LicenseRef idstring?
On Mon, Nov 2, 2015 at 9:12 PM, Wheeler, David A <dwhee...@ida.org> wrote: > Philippe Ombredanne: >> This + is a suffix and not a freestanding character, right? >> Then again we would be better off to get rid of the plus entirely! > You may be confusing a SPDX "license identifier" and a SPDX "license > expression". It's a subtle point. I am not confusing these at all. The gist of what I am saying is that the plus is a legacy that should not be there. It does not make sense to add to the large majority of GPL in the wild a + just to deal with a few exceptions that do not allow other versions. Exceptions should be dealt with an exception not with an extra + in an expression. > The purpose of a "license identifier" is to identify a specific text > of a specific license text, using a short name. In SPDX 2.0 there is > no "+" in a standard license identifier. In particular, "GPL-2.0" is > a license identifier, and "GPL-2.0+" is *NOT*. If all you want to do > is identify a particular license text, use a license identifier. No > "+"exists at the end of a license identifier. > > However, a "license identifier" is often inadequate for describing > the licensing requirements imposed on users and later developers. > Many packages have different subcomponents with different licenses. > Many packages include the text of some license (such as the GPL > version 2.0), but there are often two possible cases: > - You must use this particular version of the license. > - You may use this or any later version of the license. > Thus, SPDX 2.0 defines a "license expression" for describing how > license texts apply to software packages,. A license expression is > built out of license identifiers but adds ways to describe how the > license texts are used. A "+" appended after the name of a license > identifier means "or any later version may also be used". E.G., the > license expressions "(GPL-2.0+ WITH Classpath-Exception-2.0)" and > "(MIT AND BSD-3-CLAUSE)" express how the license text requirements > are imposed on recipients (users and developers). License expressions > use the long-standing convention is that if software is licensed > using "this or any later version" you add a "+" to the name of the > license. You can argue that the "+" should be the default, > but standards typically work best if they build on pre-existing > conventions, and that was certainly the case here. David: What you saying in substance is that every time I want state that code is licensed under the GPL 2.0 or any other version (which is the default), you want me to craft a special license expression with a plus. And If do not craft that expression, then the SPDX meaning is that only the current version applies and not any later version. I am saying this instead: Since the default for the GPL is to allow later versions, we should by default state the opposite: The few times that "only the current version" should be used, state this explicitly with an exception. You say: GPL-2.0 ==> implies GPL 2.0 only GPL-2.0+ ==> implies GPL 2.0 or later I say: GPL-2.0 ==> implies GPL 2.0 with its defaults (including later versions) GPL-2.0 with no-other-version ==> implies GPL 2.0 and no other version Explicit is better than implicit. My rationale: Practically the use of a GPL version "only" is much less frequent than the default "or later" and therefore forcing me to add a plus is a source of confusion. The most common use case should be the default and should not require a special addition of a character in an expression. "only" should be an exception and not the default, because it is not the default, nor the prevalent usage of the GPL: it is exceptional. The fact that the + convention has been used by Linux distros package maintainers and neither always strictly nor consistently does not make this right and something that should be endorsed blindly. So to recap: I am NOT arguing about the syntax to express this. I am arguing about the essence of the meaning of the plain GPL-2.0 license key in a simple expression. The mere use of a GPL-2.0 identifier should convey that the license is GPL-2.0 or any other version. We should have an exception to convey the rarer cases when only the stated version applies. The benefits are: 1. no ambiguity about the meaning of widely used licenses such as the GPL. 2. simpler spec 2. simpler expressions in most cases, more verbose and more explicit expressions when needed in some rarer cases. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Is "+" a valid character of a LicenseRef idstring?
On Mon, Nov 2, 2015 at 10:36 PM, Gary O'Neall <g...@sourceauditor.com> wrote: >> This + is a suffix and not a freestanding character, right? >> So "GPL-2.0+" is valid but "GPL-2.0+" would not be valid? > My interpretation of the spec "GPL-2.0+" and "GPL-2.0+" are both > syntactically > valid (as well as MIT+, LicenseRef-21+ and any other listed license ID or > licenseRef). This is not any statement on the interpretation, just the > license > expression syntax (I'll leave the interpretation discussions to a separate > thread). > In general, I would prefer any operator character(s) to be excluded from the > allowed characters for a license reference to keep the parsing clear and > easier to implement. Gary, I cannot envision a simpler implementation than splitting on spaces. A plus sign specified as a suffix that is not attached to a license key would no longer be a suffix to me, but something entirely different. My interpretation of the spec is that the + sign must be attached to the license key and all examples provided in the spec support this interpretation. If that part is not clear, let's fix the spec. This is not something frozen. Now that said, I do not like the plus at all and we should remove entirely from the spec. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: license list markup (was: meeting minutes)
On Fri, Aug 28, 2015 at 10:52 AM, J Lovejoy opensou...@jilayne.com wrote: HI All, Just going through some old threads. Philippe - do the subsequent comments clear up your concerns? If not, can you explain further? It’d be great to get some follow-up thoughts. Thanks, Jilayne Jilayne: The subsequent comments are fine indeed. I still think that markup for detection and reference texts would be best handled separately in the long run, yet the volume is still rather low and Gary and you seem to be ready to handle the coordination alright. -- Cordially Philippe Ombredanne On Aug 7, 2015, at 4:44 PM, Gary O'Neall g...@sourceauditor.com wrote: Hi Kris, Philippe and all, The markup language for the templates was crafted in a way that retains the original text. The optional tags surround the original text and the replaceable text has an original property which retains the original text. There is actually an opensource tool (source located at https://github.com/spdx/tools/blob/master/src/org/spdx/tools/LicenseRDFAGenerator.java) which generates the web pages for spdx.org/licenses precisely in the manner Kris proposes below (barring an bugs which is always possible ;). Note that if you go to the website, there are RDFa tags which will allow you to pull either the original text or the template from the website directly for those who would rather parse RDFa than download the raw templates (either approach is OK, of course). These tags are described in the pdf document Accessing SPDX Licenses (https://spdx.org/sites/spdx/files/publications/SPDX-TR-2014-2%20v1%200.pdf). There is also quite a bit of interest to make the same facility available using JSON - but I should probably take that discussion over to the tech mailing list... Gary -Original Message- From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal- boun...@lists.spdx.org] On Behalf Of Kris.re Sent: Friday, August 7, 2015 11:42 AM To: J Lovejoy; Philippe Ombredanne Cc: SPDX-legal Subject: RE: meeting minutes There are two purposes at odds here and, I suspect, responsible for the markup vs no markup debate. One is: a repository of data that can be used to identify license names/ids from content. The other is: a repository of data that can be used to produce content given a license name/id. Luckily, the people utilizing either use-case are, I should think, doing it with different interfaces. If you want to use SPDX data to look up the BSD 2 Clause license text, you are not likely to go about it by cloning the repository, finding the file, and reading the raw content. Similarly, if you want to use the SPDX data to identify a license from text, you are not likely going to go about it by scraping the website, processing the html, and doing a bunch of extra work. The simple solution that presents itself is this: Mark up all the data as much as needed. Generate the website from the marked up data. Ensure that the original reference text can be produced from the marked up text, and you're good to go (for whatever that's worth, since the markup is, of course, there to cover *variance* in the reference text. Deciding which version will be the official version is beyond this discussion...) This solves everyone's needs. Kris -Original Message- From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal- boun...@lists.spdx.org] On Behalf Of J Lovejoy Sent: Friday, August 07, 2015 11:29 To: Philippe Ombredanne pombreda...@nexb.com Cc: SPDX-legal spdx-legal@lists.spdx.org Subject: Re: meeting minutes Hi Philippe, Comments below: For the last two calls: http://wiki.spdx.org/view/Legal_Team/Minutes/2015-07-23 [...] 3) Mark-up bug raised on tech team call- bug filed requesting that the mark-up be done to facilitate automation vs. human readable. Good goal that tech team will look to see if it can be prioritized for next year. Gary will also talk with Jilayne about the possibility of making mark-up changes something that others can do and then submit as a patch [...] http://wiki.spdx.org/view/Legal_Team/Minutes/2015-08-06 [...] 2) Kris had raised request via tech list regarding markup on licenses and matching rules and joined to discuss some issues matching guidelines that are programmatically difficult to implement, wanted to be able to make suggestions global review or make small improvements examples: ISC License - now default license for NPM, has reference to ISC in text (needs markup); one link broken on SPDX list and one goes to link with slightly different text (generic v. specific to ISC) [...] Adding matching markup inside the reference license texts will eventually lead to un-resolvable conflicts: There is already markup in about 15% of the licenses, as per our in depth discussions a couple years ago. The conversation on the call was about improving some of the existing markup, adding markup that should have
Re: call tomorrow, agenda
J Lovejoy wrote: The issue identified on the call today (and Mark will correct me if I've misstated) is that when AND is used at the file level (Section 4), it's clear that both licenses apply to the given file. However, when AND is used at the package level (Section 3), it could mean, for example: 1) both licenses apply to some files 2) both licenses apply to all the files 3) one license applies to some files and the other license applies to other files On Fri, May 15, 2015 at 12:57 AM, Alan Tse alan@wdc.com wrote: And just to confirm, does OR have the same 3 interpretation problem at the package level? IMHO yes. This is really left to the SPDX authors to provide the level of details they want to provide. More is better but not mandated. Here's another thought I had for real world practice. When a package takes in other sub packages, are they leaving the original licenses intact or converting them to the project license (ignoring potentially compatibility issues)? I always assumed it's the former but it's not always clear to me if there's an industry practice to fall back on. I have seen it done both ways. And quite often this is a combination of both. Taking Apache as an open source example, you see quite often an aggregated composite notice and license texts listing every licenses of non-Apache and Apache components embedded in a given package (Tomcat is a good example). You also see each individual original notice and licenses left as-is further down the tree. When translated to SPDX it would be likely redundant to repeat things ... But it is convenient to have things in one place summarized. In practice having a summary report produced from lower level could be a tool-provided solution IMHO. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Should LGPL-3.0 be an exception rather than a main license?
On Thu, Mar 26, 2015 at 9:10 PM, J Lovejoy opensou...@jilayne.com wrote: Hi All, Let me sum this up, to make sure we are all on the same page. LGPLv3 will be on the license list - there is no question there. The question is, now that we have the exceptions listed on their own, should it be there (http://spdx.org/licenses/preview/exceptions-index.html) or remain as a standalone license on the main list (http://spdx.org/licenses/preview/) I don't think there is a right answer here... we can be consistent in how other exceptions are represented or not (ostensibly due to external considerations). As much as I do prefer consistency, we have already seen before that trying to apply rules in a consistent manner to open source licenses and how they are represented is almost impossible. I believe that historically speaking, LGPLv3 was very intentionally drafted this way with a goal of making it easier to apply and understand (given the confusion over LGPLv2.1), which sort of cuts towards treating it as a true exception (Alan's theory very interesting, though!) So, let's take a look at the two option: 1) To be consistent, it would seem that LGPLv3 is an exception in the same way as these other exceptions. This would mean it would be listed with the exceptions and to represent LGPLv3 using the License Expression Syntax would look like this: GPL-3.0 WITH LGPL-3.0 (this feels a bit odd, but it would be accurate technically speaking...) This would indeed be accurate but both odd and confusing. Or, 2) We could simply leave LGPLv3 on the main license list (as if it was a standalone license) and thus it would be represented as its standalone short identifier: LGPL-3.0 (This would be technically inconsistent with how the other exceptions are represented, but results in an arguably more expected identification via the short identifier.) This is IMHO the only sane thing to do. Practically beast purity. I don't know-- as much as I like consistency and accuracy (#1) - the resultant license expression syntax of GPL-3.0 WITH LGPL-3.0 feels... wrong. I'd also be afraid that if we went that route it would be confusing, because it's not what you'd expect and that the community would, well, freak out (possibly justifiably). As to the latter concern, I just sent Bradley Kuhn an email about this to gain his thoughts, since I have spoken to him a bit about the efforts to improve our list of exceptions. Thus, #2 just feels more appropriate.*sigh* In the meantime, I'd be curious to hear thoughts what with the syntax staring at you. #2 aka LGPL-3.0 is the only thing that makes sense to me. -- Cordially Philippe Ombredanne ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Revisiting the SPDX license representation syntax
On Tue, Oct 29, 2013 at 7:26 AM, Wolfgang Denk w...@denx.de wrote: In message caofm3uedjbvgywltsp0xmxe1vrefomaapenzkhekdx6+-xv...@mail.gmail.com you wrote: Here are the basic examples updated to SPDX: Thanks - I mostly like this, but I would like to suggest a few minor changes to make life easier especially to developers who are used to standard operators in programming languages: Guten Tag Wolfgang! and thanks for your feedback. * mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0. A choice must be made. (CHOICE, EXCLUSIVE OR, DISJUNCTION) In C and some other programming languages, the EXCLUSIVE OR operator is '^', so please make this mit ^ gpl-2.0. * gpl-2.0 ^ classpath : a license exception or supplemental terms: here, the classpath exception to the gpl-2.0. nb: here we have a slight change with the SPDX license list, where the exception would be just the exception and not the whole gpl-and-classpath taken together as one license.(EXTRA TERMS, EXCEPTION) Please use a different operator t mark an exception, as '^' is kind of reserved for XOR. You are absolutely right there and being a programmer I had hesitated a little about the implications then, and thought that it would be OK to forego programming conventions. Expressing disjunctions with a caret ^ makes perfect sense. In this case, and this would be a good simplification the explicit ampersand or the implicit space AND separator could be used for a license exception or supplemental terms which is really all that is needed. For instance: gpl-2.0 + classpath: I am licensed under the GPL 2.0 or any later version with the Classpath expection which could rephrased also as something more or less equivalent for such as this, because the classpath exception states that it can be removed: (gpl-2.0 + classpath) ^ gpl-2.0 + : you must select the GPL 2.0 or 3.0 with or without the Classpath exception Note that FWIW this little language of mine was buried in notes I wrote down four years ago, and has never been in use practically I just adapted it in this email thread to use SPDX license keys. -- Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Revisiting the SPDX license representation syntax (Package vs. Program license)
On Tue, Oct 29, 2013 at 5:39 PM, RUFFIN, MICHEL (MICHEL)
michel.ruf...@alcatel-lucent.com wrote:
I just want to point out that we are mostly dealing with package level system
If I take the example of JBoss in our FOSS DB you get the following (see
below)
So the concluded license is just LGPL-2.1 AND(+) a lot of dependencies
Michel:
My 2 cents, I would possibly express this either:
* as lplg-2.1+ {mit bsd-3-clause and a long list of licenses }
using my 'little language'
OR
* I would create a new license internally which I would call the
something like the JBossAS-4.2.1 license. This would be a 'composite'
of all the licenses contained in this large component, abstracting the
details. AFAIK, there is nothing in SPDX that would prohibit you from
creating your own licenses for this purpose.
You could even provide both the long list of SPDX ids AND the composite text.
On lundi 28 octobre 2013 23:23 Gisi, Mark [mailto:mark.g...@windriver.com]
wrote:
All in all, Boolean expressions provide an effective way to describe
licensing of
programs, libraries and source files (linkable distributable components).
Package licensing is an ill defined concept. Often a package can be viewed
as a box containing a collection of components each *potentially* subject to
different licensing terms. We will need to address these differences in the
upcoming licensing breakout session.
Mark and Michel:
IMHO, you guys are coming from two different points of view but are
talking the same language.
As a Linux distro vendor (or a JBoss distro provider) I may want to
express the obligations of the packages I distribute (be they mine or
from upstream) at a finer level of granularity, which would be
possible unit of discrete consumption. This would then be helpful to
downstream consumers such they could make informed decisions when they
consume, use, build or link with components I provide in my distro.
As a component consumer, I may want to treat these upstream
obligations at a more coarse level, and treat larger things possibly
as big as a Linux distro or a JBoss as one aggregate component, and
may or may not care about finer-grained details passed to me from
upstream.
Because in the end, somehow, your product (that you may see as several
fine-grained components) may be one of the many components for my own
product or application and I may see as just one single component.
I think that SPDX does and should in spirit and letter support both approaches.
--
Philippe Ombredanne
+1 650 799 0949 | pombreda...@nexb.com
DejaCode Enterprise at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: Revisiting the SPDX license representation syntax
On Tue, Oct 22, 2013 at 6:01 PM, Gisi, Mark mark.g...@windriver.com wrote:
In the last SPDX Legal meeting we discussed whether the current SPDX license
representation syntax is sufficient to represent the licensing terms of most
files (e.g., source, library and binary programs). For example, is the
combination of the SPDX license list + current binary operands (AND and OR)
sufficient to describe the licensing of most programs derived from multiple
source and library files, where each is potentially under a different
license.
Let me bring my 2 cents to the discussion. A while back I wrote down
this little language to compose licenses. The point was to :
- make this easy enough for humans and machines to read, write and understand.
- have a terse yet expressive way to represent actual licensing in one
statement, eventually expressing the complex licenses composition of
whole packages.
- support factual licenses statements as well as interpretations such
as selection from a choice, the fact that some license may apply that
were not asserted originally, etc.
PS: For most of it there is nothing new there, SPDX does it alright.
PPS: Some of this may not mesh entirely well with the current SPDX
licenses list state (such as expressing or later versions
generically or how we deal with exceptions).
Here are the basic examples updated to SPDX:
* lgpl-2.0 : a single license applies.
* apache-2.0 lgpl-2.0 : All the licenses listed apply,
space-separated list. (AND is implied as the default operator,
CONJUNCTION)
* mit lgpl-2.0 : All licenses listed apply, ampersand-separated
list. (explicit AND, CONJUNCTION)
* mit | gpl-2.0 : a license choice: either one of the licenses can
apply, the choice does not have to be made and can be passed
downstream. (CHOICE, OR)
* mit ? gpl-2.0 : a disjunctive license choice of mit or gpl-2.0.
A choice must be made. (CHOICE, EXCLUSIVE OR, DISJUNCTION)
* gpl-2.0 ^ classpath : a license exception or supplemental terms:
here, the classpath exception to the gpl-2.0. nb: here we have a
slight change with the SPDX license list, where the exception would be
just the exception and not the whole gpl-and-classpath taken together
as one license.(EXTRA TERMS, EXCEPTION)
* gpl-1.0 + : this license version or a later version applies:
i.e. gpl-1.0 or later. nb: here the plus sign is not part of the
license id, but part of the syntax which is also different from SPDX
(OR LATER version)
* (apache-1.1 mit gpl-2.0) : a grouping of licenses. This is
useful for explicit grouping in complex statements, rather than
relying only on eventual operators precedence (GROUP)
* ftl [ftl ? gpl-2.0]: a license selection expressed with
brackets: here I picked ftl from the disjunctive choice of ftl or gpl.
(SELECTION using brackets)
* apache-2.0 {mit bsd-3-clause lgpl-3.0} : I think that the
primary license is overall apache-2.0 and that other secondary license
apply. This is handy to express composite licenses at a package level.
(PRIMARY and SECONDARY using braces)
* gpl-2.0 mit: I think that the license that applies here is
gpl-2.0, despite being asserted originally as MIT-licensed (possibly
because of linking, dependencies, code reuse or else).
(INTERPRETATION, INTERACTION)
* gpl-2.0 ! commercial : I think that the gpl applies and that the
commercial the license id CANNOT apply. Negations are usually
aberrations with conflicting terms but I see vendors releasing dual
GPL/proprietary making this type of interpretation in supplemental
terms often enough. Some proprietary licenses state the opposite
explicitly too: this is commercial and cannot be gpl. This rarely of a
practical use but may be needed for completeness (NOT, NEGATION)
And more complex examples:
* apache-1.1 ( mit | gpl-2.0) : apache AND mit or gpl using a
grouping of licenses choice.
* mpl-1.1 [gpl-2.0 | lgpl-2.1 | mpl-1.1 ]: I picked mpl-1.1 from
the choice of mpl, lgpl or gpl.
* gpl-2.0 (mpl-1.1 [gpl-2.0 ? lgpl-2.1 ? mpl-1.1 ]): I think
gpl-2.0 applies here despite a selection of mpl-1.1 from a disjunctive
choice.
* apache 1.1 bsd-3-clause (openssl ^ gpl-exception) : apache
AND bsd AND (openssl with a gpl-exception taken together) apply.
* gpl-2.0 [gpl-2.0 ^ gpl-2.0-with-classpath-exception | cddl-1.0]
: I picked gpl-2.0 from a choice of gpl with classpath exception or
cddl.
* proprietary {mit bsd-3-clause apache-2.0
gpl-2.0-with-bison-exception}: My primary license is proprietary with
MIT, BSD, GPL with bison exception and Apache-licensed code as
secondary
* lgpl-2.0 [lgpl +] : I picked the v2 of the lgpl out of a choice
of any LGPL versions.
* gpl-2.0 (gpl-2.0 | mpl-1.1): I think that the license that
applies here is only gpl-2.0, despite being asserted originally as
choice of gpl or mpl may be because this code is running in kernel
space.
I hope this helps fueling the discussion.
Cheers
--
Philippe Ombredanne
+1 650 799 0949
