Add new annex on license namespaces #681
Conversation
|
Oh, and the PR uses |
Signed-off-by: Alexios Zavras <github@zvr.gr>
|
There has been some interest in having a "private" repository of external license texts. Should we change the text to encourage registering the license texts, but not require it? |
After thinking about this a bit more, the non-DNS style namespaces need to be registered to avoid name conflicts. Perhaps, we could change the wording where non-DNS style "must" register while the DNS-style "should" register. |
|
@goneall The issue is that SPDX v2 is definitely oriented towards exchange of information. If I get a valid SPDX Document but it refers to something that is not available, it would be considered an error. We do not to facilitate the creation of such documents. Put in another way: The point of this change is to allow some licenses not in the SPDX License List that can be used by anyone, not only their creators. I expect that in SPDX v3 we will add the case you're talking about, with namespaces be able to point to locations outside the SPDX project. But it will probably necessitate some additional syntax. |
@zvr Completely agree. I just recall other members of the SPDX community discussing this possibility - but I agree SPDX 2.0 documents are intended for interchange. I didn't see any other issues with the PR - thanks for creating it! |
There was a problem hiding this comment.
I think we should refine the mechanism, and processes for registering namespaces before 2.3 comes out (rather than saying at a later date), but agree it doesn't need to be defined to get this merged in here, and start this off. As suggested a github repo, makes sense. What needs to be part of the "registration" also needs to be defined.
|
@zvr Could you please go ahead and update this to use next Annex letter, and add in your signed off. Would like to get this merged in our meeting next week, if possible. |
There was a problem hiding this comment.
Hi @zvr and others, thanks for this! I'm strongly in favor of including the license namespace concept in SPDX 2.3, as I think it solves a number of pain points that folks have encountered.
That said, I have a few changes to request. There are some typo / nitpicky edits and questions inline below, but there are two significant overarching changes I would like to see addressed:
- Have the namespace controller register with the SPDX project a URL to the SPDX document defining the LicenseRef-'s, rather than registering the document itself
- Omit the organization name format
For item 1, I think it is far easier for us to manage registration of a URL rather than registering the document itself. That puts the responsibility on the namespace controller to handle the maintenance of the document, without putting anyone from the SPDX project in the middle of being responsible for e.g. vetting requested changes to namespace documents, trying to figure out whether or not it's appropriate to merge a PR, etc.
For item 2, relatedly, I don't think we want to be in the business of deciding who has rights to register a particular organizational namespace. DNS registration is an existing mechanism with well-defined processes for determining who owns a particular domain name, and we can leverage that with minimal effort. But creating our own additional "organizational name" registry puts the SPDX project in the middle of trying to decide, for example, whether someone claiming to be registering on behalf of Intel or Amazon or ExampleCorp is really authorized to do so.
Furthermore, by limiting this to both items 1 and 2, there's an easy synergy to determine whether a registration is acceptable. If it's a registration for the DNS namespace example.com, and the requested URL to register is within the https://example.com/... URL format, then it's likely fine to merge. If it's for a URL to register that's outside that domain name, then it shouldn't be merged.
Finally, although I'm not sure it needs to be explicitly stated here, as a matter of SPDX project processes I do want to be really clear that the SPDX Legal Team won't be involved in any way with vetting or reviewing requests for license namespaces. I think we have an appropriate role to play in defining the structure and operation of license namespaces in this Annex; but it is not within the scope of the Legal Team to review and weigh in on whether any particular license namespace is appropriate. @zvr's writeup of this Annex does a great job of describing a clear delineation between the actual SPDX License List, with the reliability expectations that the community has; and license namespaces, which properly have no reliability for stability at all. I don't want folks to think that the SPDX Legal Team is providing any review or guarantees of stability for anything outside the SPDX License List itself.
| 2. the namespace maintainer creates | ||
| an SPDX document defining license texts | ||
| and corresponding identifiers | ||
| which include the namespave, |
There was a problem hiding this comment.
typo: "namespave" => "namespace"
| and corresponding identifiers | ||
| which include the namespave, | ||
| as described below; | ||
| 3. the namespace and the SPDX document |
There was a problem hiding this comment.
See my main comments about whether the SPDX document should itself be registered with the SPDX project (in the sense of having the document itself checked into a repo within the SPDX GitHub org), vs. having them register a creator-controlled URL with the SPDX project.
| * `LicenseRef-.example.com.-EULA-v3.1` | ||
| * `LicenseRef-.example.com.-anything` | ||
|
|
||
| ## Z.3.2 Organization name format |
There was a problem hiding this comment.
See my main comments about whether we should include the organization name format. I would lean in favor of excluding it, or at least excluding it from the first iteration of the namespace setup for SPDX 2.3.
| must only use characters permitted by the license expression syntax | ||
| (i.e., letters, digits, "-" and "."). | ||
| It must not contain a double hyphen, | ||
| as that denotes the end of the namespace. |
There was a problem hiding this comment.
Does this lead to confusion if someone decides to implement a domain name in the organization name format, which I think would be permissible given the way this is drafted?
E.g. LicenseRef-.example.com.-ABC-1.0 is a DNS name format, while LicenseRef--example.com--ABC-1.0 is an organization name format -- but this may lead to confusion.
What if the organization name format were only to permit letters and digits for the namespace itself?
| it must be registered with the SPDX project. | ||
| The registration request must provide | ||
| the namespace and | ||
| the SPDX document defining the licenses. |
There was a problem hiding this comment.
See my main comments about registering the document itself, vs. a URL to the document.
| However, it should be noted that the stability | ||
| will always be subject to the namespace maintainer's control. | ||
| In other words, | ||
| although maintainers should not modify a defined license text |
There was a problem hiding this comment.
I'm not certain how the standards-world all-caps words work, but should this be "SHOULD NOT" instead of "should not"?
|
@zvr @swinslow A couple of inputs on Steve's comments:
I agree. We actually have a registration mechanism in place - it's not really being used, but it does register the URL's, not the actual documents which is consistent with Steve's comment above. If you want to check out the tool - here's the URL: https://tools.spdx.org/app/submit_new_license_namespace/ Registration requests go into a Github repo: https://github.com/spdx/license-namespace It looks like the tool submits issues in the same way license requests are done. I'm sure we'll want to implement a process and improve the tool, but at least we have a starting point.
This was a request from @MarkAtwood from the legal team a couple years ago. If I recall, he proposed the mechanism as a way to avoid name collisions and not requiring any registration. If we have a position that registration is required, there may not be a need for this format. @MarkAtwood - feel free to correct anything I miss-stated. If there is disagreement on this specific format, perhaps we should postpone it until a future release so that we can get the other format going. |
|
Thanks @goneall! And thanks for the reminder on the existing namespace registration tool. I may put together and host a sample document myself and go through the registration process with it, to make sure I understand how it works. For the organization name format, yes -- I think I'm inclined to suggest that we omit it for now. We can always add it later if it turns out that the DNS format is insufficient, but I assume once we add it then it would be difficult or impossible to remove it. So I'd lean towards starting with the DNS format since I think we can more easily think through its implications. |
|
@goneall and @swinslow, many thanks for the comments. I personally disagree with the two major changes proposed by @swinslow, but I'll obviously follow the majority opinion. As I wrote above, I see the value of this in SPDX actually hosting the license definitions. If we only register external locations where the licenses definitions are, how is it different than an ExternalDoc reference? Let me expand on this: Of course, the SPDX project (and Legal Team in particular) will not be involved in any curation or reviewing of the licenses -- except an automated check that the SPDX Document defining the licenses is valid. Another question / discussions point: Is the idea that SPDX will be publishing the list of "registered license namespaces", like we do with the License List? I assume we'll have discussion on the tech call on Tuesday. |
The main advantage I see is that location information would be available (as well as contact information).
I was thinking we would maintain a github repo with the information published in a github.io page. This would be easier to maintain compared to an spdx.org/license-namespace site and would provide a bit more distance between the legal team and the licenses (my main interest is the easier to maintain). To do this, we would need to add a Github action and possibly modify the registration utility. |
Agreed. I see the whole "license namespace" proposal essentially as establishing a mapping from a specially-formatted LicenseRef- ID, to be able to find the corresponding document that defines that LicenseRef's text. Someone could avoid all of this by including in their project repo an SPDX Document defining the LicenseRef, perhaps in a manner such as described by REUSE. But I gather others are wanting a way to define a stable LicenseRef-to-actual-text mapping that doesn't require an SPDX Document sitting alongside the place where the LicenseRef is being used. So the DNS namespace format, coupled with a mapping to a URL where the namespace's SPDX Document is located, enables this while also putting a minimal amount of effort on the SPDX project. Moving more into the SPDX project's scope (e.g. hosting the Document, or hosting an org-name registry, etc.) puts more burden and responsibility on the SPDX project community to have to coordinate those matters, when frankly the DNS-format-to-URL mapping gets to the same end purpose for downstream users while minimizing what the SPDX project is responsible for hosting. Or from a different angle: if it's DNS-format-driven and the namespace owner hosts the Document, then it properly reflects that the SPDX project makes minimal guarantees as to the stability of these namespaced LicenseRef's. If by contrast SPDX is hosting the documents, or hosting an org-name registry, then the SPDX project is more in the middle of at least implying that those things will be maintained and made stable / available. |
@goneall This all sounds good to me. I haven't looked at the guts of the registration utility program yet, but yes, it seems like if it's published to a simple website then it should give the downstream users an easy way to access the details for all namespaces. If it's as simple as a DNS-namespace-to-URL mapping, then perhaps it could even be offered as a single JSON file with just those mappings. That could make it trivial for consumers to grab the JSON file, find the namespace they want and go get the Document from the corresponding URL. |
|
ScanCode and all the tools that include ScanCode and use its LicenseDB such as ORT, Tern, Fosslight, Barrista, and countless others are all using and relying on a simple "scancode" namespace using this prefix "LicenseRef-scancode-" as used for all the non-SPDX-listed licenses found in the LicenseDB https://scancode-licensedb.aboutcode.org/ . This has been used in practice for over five years (and registered with the SPDX online tools). So please let's not introduce a spec that is not compatible with ScanCode and would create havoc for all its users for no good reason. We will not be able to rename the thousand+ SPDX Scancode license references using the "scancode" namespace that are used in the wild. And if the changes proposed here are adopted as-is they will make all ScanCode users drift away from SPDX compliance. Instead let's also accept that there are registered namespaces and that there is no need for a complex syntax when this is the case. I can provide spec text along these lines. On a side note that when it comes to non-public, non-shared namespaces, I do not see a big need to standardize anything: private things will not be shared or else they are not private anymore. A registration is simple and good enough in all public sharing cases I can fathom. And based on the handful of registration requests that the SPDX Online tools received over the last couple years I feel like specifying anything else is not a pressing need: https://tools.spdx.org/app/archive_namespace_requests/ |
|
From a tool provider and integrator perspective I would like to
I would regard this is not in conflict with Philippe's current use ( being scancode). I'd limit registration in a way that
Beyond this general concept, I would hope that the procedure/policy would retrofit my request from the 10th of February this year: https://tools.spdx.org/app/license_requests/143/ Thanks Alexios for bringing this aspect up again... Regards, |
The challenge with the current format is being able to differentiate between license text we expect to find within the SPDX document and license namespaces. Currently, the spec and the validator tools look for license text for any LicenseRef- license ID's. If this PR is accepted, we would not look for license text for any licenses matching a specific pattern. I can think of 2 alternatives which would be compatible with the existing Scancode LicenseRef's:
The first is simpler, but would allow situations where the license text could not be obtained. The latter would be computationally intensive and possibly require access to the internet for the latest namespace registrations. Note that per this PR, there would still be a requirement to publish an SPDX document with all known license ref's. I still think the approach of using the patterns described in the PR is the simplest for tools providers to validate, but I can understand the concern on compatibility. |
|
Thanks @karsten-klein @pombredanne and @swinslow for your comments on the proposal and PR. One thing all commenters seem to agree on is we do need to include this in the spec since many of us are using this feature. We definitely should take into account compatibility with existing implementations, but I don't think we should let that stop us from getting this added to the spec in 2.3 (even if it causes some compatibility problems). |
I agree with the first two points. For the third, I think this is inherent in the existing limits for SPDX LicenseRef- IDs. This aligns to what you described, except with the permitted addition of dashes and periods. If we're talking domain names, I think this generally works as intended, and with the proposal in this PR the "namespace" portion would be prefixed with For the fourth point, I absolutely disagree. The SPDX Legal Team maintains the SPDX License List, and has a role in defining the licensing-related aspects of the SPDX spec, including how license namespaces are defined. But the Legal Team has no role in "approving" a namespace registration. I'm not sure what such approval would mean (by the Legal Team or anyone else) or on what criteria it would be based -- which is partly why I'm wanting the "registration" aspect to be as minimal and limited as possible. |
|
@goneall One clarification, because I might have been unclear from my earlier comments: I don't think that the license namespace concept has any relevance from an SPDX Document parsing perspective. At least for SPDX 2.x, I would not want to change the existing rules requiring all From my perspective, the only relevance for the license namespace concept we're discussing is to make it easier for people to add This is a long-winded way of saying, I don't think this means that anything needs to change in the libraries for the SPDX tools that parse SPDX Documents. I'd assume that those libraries should still expect that |
|
OK, it seems we have a number of topics to discuss:
|
|
Update after the tech call on 2022-05-24, where we spent almost 40 minutes discussing this:
Still open (among others): whether a special format is needed to denote namespace. |
|
Using @zvr list of open issues as a basis, and having read the PR, this thread, and Steve's email the legal-mailing list (plus memory of @MarkAtwood original description and discussion):
Lastly, I'm still concerned about this being used as a lazy way to bypass getting more licenses that should be on the SPDX License List. I know that @MarkAtwood's original proposal focused on licenses that would never nor should never be on the SPDX License List. |
|
Quick couple of comments to @jlovejoy reply above: Starting from the end, yes, the idea for these private lists is that they cover licenses not in SPDX License List. But I assume people might also want to use them for licenses not currently in the SPDX License List. On the publishing point (3), you are correct in understanding the problem: given an identifier The two alternatives we have are: In both cases, the SPDX project will not be checking content like "someone using a license text that matches a license already on the SPDX License List" or anything like this. Yes, it would be "bad", but this can also happen today: someone defining their own The SPDX project registers namespaces, not what goes within them. Related to checks during registration process (point 4), I believe everyone until now only talks about automated checks, no human decision involved. Things like:
|
|
Hi all, Tuesday’s session left me a little bewildered and puzzled. The interesting observation is that all participants on the discussion have good arguments. However, (in my view) only from a certain and not a holistic perspective. The related fears (such as identifier collisions (e.g., two parties using the same LicenseRef-scancode- referring to different licenses); a party introducing a LicenseRef for a License already on the SPDX License List) appear quite artificial to me and mix syntactic, semantic, and integrity validation aspects, which rather should be disentangled. As I also can only contribute a perspective and would leave the holistic assessment to the group, I would like to make some observations: SPDX Format:
License Ids:
License Texts:
License Namespaces:
As indicated earlier I will not propose any solution. Some aspects may be rather revolutionary, and I can currently not foresee whether these thoughts resonate with the group. Just some highlight showing the idea: […] […] […] […] I’d also argue that you could define a default license namespace for an SPDX document. In this case you could omit the default namespace short-name prefix. The default would be spdx. This even doesn’t break LicenseRef compatibility. LicenseRef is just a special case (no namespace available). This can compensate the compatibility concern raised by Philippe and enable a transition once namespaces are available. Regards, |
|
(responding via email so I can add spdx-legal mailing list; not sure
what mess this will make in Github, so apologies in advance)
On 5/26/22 12:00 AM, Alexios Zavras (zvr) wrote:
Quick couple of comments to @jlovejoy <https://github.com/jlovejoy>
reply above:
Starting from the end, yes, the idea for these private lists is that
they cover licenses not in SPDX License List. But I assume people
might also want to use them for licenses not /currently/ in the SPDX
License List.
that is my understanding too
On the publishing point (3), you are correct in understanding the
problem: given an identifier
|LicenseRef-.mynamespace.com.-LicenseABC|, there has to be an SPDX
Document that uses the "other license info detected" section to say
"hey, for this |LicenseRef-.mynamespace.com.-LicenseABC| the
corresponding text is this".
The two alternatives we have are:
a) people submit this document and we store it in a repo; or
b) people submit the /location/ of this document and we store (the
location) in a repo.
There are obvious pros and cons to both approaches. But I think we just
need to be realistic that (a) may end up requiring some "curation" of
some kind if it's in an SPDX repo.
On that note, it appears that the current submission tool is really just
(b)?
In both cases, the SPDX project will /not/ be checking content like
"someone using a license text that matches a license already on the
SPDX License List" or anything like this. Yes, it would be "bad", but
this can also happen today: someone defining their own |LicenseRef-MIT|.
while you are correct that this could happen today, I still think that
by not checking the content, we almost give greater license.
Look at Philippe's submission, for example, it links to the entire
database of licenses ScanCode has found, which presumably includes all
that are already on the SPDX License List. So already we are not
differentiating well b/w SPDX License List and the point of LicenseRef
(not on SPDX License List).
The SPDX project registers /namespaces/, not what goes within them.
but what goes within them - which I take to mean the specific, full
LicenseRef with namespace and license, plus text of license has to go
somewhere (see above)
Related to checks during registration process (point 4), I believe
everyone until now only talks about automated checks, no human
decision involved. Things like:
* checking whether the namespace is not already registered;
* checking whether the format of the namespace is correct;
* checking whether the URL is valid;
* checking whether the URL resolves to a document;
* checking whether the document is a syntactically correct SPDX
document;
* etc.
do we currently have all the tooling to do all these things? If not, who
is going to develop for the gaps?
… —
Reply to this email directly, view it on GitHub
<#681 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGQSU77N2IZTKI5YKTUXITVL4HRPANCNFSM5WEHR7FQ>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
(responding via email so I can add spdx-legal mailing list)
On May 26, 2022, at 5:44 AM, Karsten Klein ***@***.***> wrote:
Hi all,
Tuesday’s session left me a little bewildered and puzzled. The interesting observation is that all participants on the discussion have good arguments. However, (in my view) only from a certain and not a holistic perspective. The related fears (such as identifier collisions (e.g., two parties using the same LicenseRef-scancode- referring to different licenses); a party introducing a LicenseRef for a License already on the SPDX License List) appear quite artificial to me and mix syntactic, semantic, and integrity validation aspects, which rather should be disentangled.
As I also can only contribute a perspective and would leave the holistic assessment to the group, I would like to make some observations:
SPDX Format:
SPDX is primarily about the exchange of software package information. That is information on software conveying structural, relational facts associated with metadata on different aspects; primarily – but not limited to – licensing information
As such the format requires to reference licenses by id and provide (rather optional in my view) license texts associated with the id; concerns below
As a reminder of the original intent for the SPDX License List was to create a shorthand, reliable way to refer to licenses such that an SPDX Document would not get bloated with repeating the same licenses over and over (imagine, in contrast, if every license used the Other Licensing Info part of the spec). At the same time, recognizing the SPDX License List would never represent every license found in s/w, there is the Other Licensing Info. I think it’s important to keep in mind the context of the SPDX Document because that is the starting point. And also acknowledge other contexts.
License Ids:
When exchanging software licensing information, we need to make sure that we refer unambiguously to licenses. Using consolidated ids for licenses is key.
The SPDX License List – due to scope (limited to open/public licenses) and the policies set forth in the matching guidelines – will not (and never) cover all licenses that can be used for software.
When producing SPDX documents we cannot limit the scope of licenses to open (or publicly available) licenses only
I’d argue that SPDX-Legal Team is an authority managing the SPDX License List (the work being highly appreciated!!); however, it would be only expectable that there may be other Authorities that manage Licenses Lists (i.e., OSI included in this considerations).
While this is true, different “Authorities” have different goals, processes, etc. So we need to be careful to not conflate. The SPDX License identifiers were certainly aimed to be cross-functional. E.g., OSI uses them and does not need to have its own set of “ids”. The hope/idea is that would be true widely.
Scancode Toolkit – for me – is a community managed license list authority. Scancode has not invented these licenses; Scancode organizes them according to the Scancode policies. The rules may not be the same as the SPDX matching guidelines, but scan
Agreed and has always been acknowledged from the beginning. (side note: Just keep in mind that the SPDX License List inclusion guidelines were broadened, so there are more licenses that are potentially eligible to be included than was originally the case.
code is of value to the people using it and provides a most pragmatic entry into the domain; why should these not – unambiguously – reference a Scancode license from an SPDX document leveraging SPDX as a format.
My company does SCA and license identification in customer projects. In this respect we permanently run into licenses that are not on the SPDX License List and sometimes even not in Scancode. We therefore developed an extended identification concept and published is as {metæffekt} Universe <https://github.com/org-metaeffekt/metaeffekt-universe/blob/main/src/main/resources/ae-universe/%5Bb%5D/README.md>. We would like to – unambiguously – reference licenses using this “extended namespace” within SPDX documents; again, leveraging SPDX as standardized exchange format. Customers with access to the licenses database, can use the ids to resolve the license texts.
Great - this sounds consistent with the original goal as I understand it.
Please take the time and have a look on the license table for letter B <https://github.com/org-metaeffekt/metaeffekt-universe/blob/main/src/main/resources/ae-universe/%5Bb%5D/README.md>. You can see the SPDX and Scancode coverage there.
Based on a quick look I see one license that does not have an SPDX license id, but is now on the SPDX License List. I also see “BSD-1-Clause” (on SPDX License List), but then see you have “BSD-1-Clause-copyright” - but according to SPDX matching guidelines, this is the same as BSD-1-Clause. The only difference is “author” instead of “copyright holders” in the disclaimer paragraph. The SPDX legal team has already determined this is not legally substantively different. By treating this as a different license, you are not leveraging a major benefit of the SPDX License List overall and effectively creating your own criteria. How is this helpful?
The point of the Other Licensing Info (LicenseRef) was to augment the SPDX License List, where the SPDX License List as the starting point. This example seems to reverse or ignore that.
Please also be aware that license ids may refer to a unique license text OR they may refer to a license templates. The instances of https://spdx.org/licenses/BSD-3-Clause.html <https://spdx.org/licenses/BSD-3-Clause.html> may have different text in case the copyright holder modified the variable parts of the template. Putting the default text of the license template in an SPDX document is not appropriate and not in the sense of the license.
This is where we diverge and we have discussed this together recently. "Putting the default text of the license template in an SPDX document is not appropriate and not in the sense of the license.” is YOUR interpretation. The intent of the SPDX License List and ids within an SPDX Document is to not have to repeat the same license text with definitions of what is the same. You are effectively disagreeing with those matching guidelines (in this case based merely on a different name versus a more template-like “authors” or “copyright holders” language) and then making a legal interpretation as to whether the license intends for such a strict interpretation, and a risk profile assessment as to whether someone is going to bring a non-compliance action due to replicating the BSD-3-Clause text using just “copyright holder” rather than “My Name” specifically. We need to be clear about 1) when we are making such interpretations; and 2) not incorporating such interpretations within SPDX. :)
License Texts:
I regard putting license texts in the SPDX document as problematic; especially in the way it currently done.
you are referring to Other Licensing Info, yes? How would it change, then?
A software package may reference a license (id is sufficient to capture this fact) or may include a license text (which may not be 100% the same as stored in the SPDX License Data). The license texts may be mixed with other information or refer to list of third-party licenses. SPDX trying to segregate this into different parts adds an artificial layer of information that often does not align with the facts. Example: https://github.com/spring-projects/spring-framework/blob/main/src/docs/dist/license.txt <https://github.com/spring-projects/spring-framework/blob/main/src/docs/dist/license.txt>I’m a little lost as to what your point is here. Looking at your example, which looks to me to be a pretty nice summary of licensing for a specific package that incorporates other open source licensed components. I’d imagine the license information (roughly) in an SPDX Document might look something like (using SPDX fields, but not listing everything here, of course)
- PackageLicenseDeclared: Apache-2.0 AND BSD-3-Clause
- PackageLicenseConcluded: Apache-2.0
- PackageLicenseInfoFromFiles: Apache-2.0, BSD-3-Clause
- PackageLicenseComments: This package is Apache-2.0 with some included components that are also under Apache-2.0 and BSD-3-Clause as noted here LINK
Then at the file level, you’d have the breakdown of what files are under which license.
Note - someone else might put Apache-2.0 AND BSD-3-Clause as Concluded License field.
(Note2 - For simplicity of this example, I’m intentionally ignoring the weird NOTICE under Apache-2.0 4(d) in actual example that seems to use the Apache NOTICE file in a way not anticipated and imply there may be other licenses in there.)
For us It is important that
an SPDX document consumer is able to resolve a license by Id (as approved general representation of the license);
it already can
this can be done by an internal or external link to a license database (e.g end on the SPDX license list, OSI, Scancode, {metæffekt} Universe or any other party web site that provides consolidated license ids and information).
the package specific license files (copyright, LICENSE, NOTICE, …) can be accessed by the consumer and are preserved in format and content
I’m not sure this is as important or where you mean that this would be accessed - it is always in the source code in any case.
Please note that different authorities for licenses may model licenses differently to match their specific policies and guidelines. This means that the same license or license aggregate is represented differently by the different authorities. I don’t regard this as bad; I regard this as opportunity. Such cases may trigger exchange and discussion.
Licenses / contracts may be confidential. While the id is not critical the license/contract content is. Therefore:
Licenses can be public / shared
Licenses can be private and shared only within parties under contract or NDA
Licenses can contain conditions that do not allow to distribute the license text
We must anticipate that we are never only talking open source (!)
License Namespaces:
I would argue from an SPDX Format perspective that License Authorities should be treated equivalently.
I don’t think so… they are not equivalent so they cannot be treated equivalently.
Currently the SPDX License List is treated unique and special (work highly appreciated) making it ultimately hard for others to contribute their work and with all the caveats listed above. This means that SPDX License List is a namespace definition itself.
Registering a namespace means just to register the namespace definition. I’d still argue (as this is content) that the SPDX Legal Team could approve a namespace registration to make sure the namespace is unique and follows given guidelines with respect to naming. A namespace definition includes at least:
Short Id
Namespace domain (could also be used for owner verification)
URL where to find details on the namespace
Contact Address (legal entity or person owning the namespace)
Latest version
note: there is still time and effort involved in this check, and probably more than it seems at face value!
I do not see that SPDX needs to care about the licenses managed in the namespace. The management and rules of the licenses in the namespace is up to namespace owner. If (s)he plays not to the rules, the namespace reputation will suffer. People will not use it.
Validation of LicenseRef in the SPDX document is limited; but here I see opportunities for tool providers to add further levels of integrity validation.
As indicated earlier I will not propose any solution. Some aspects may be rather revolutionary, and I can currently not foresee whether these thoughts resonate with the group. Just some highlight showing the idea:
[…]
LicenseConcluded: spdx:MIT
[…]
LicenseConcluded: scancode:bittorrent-eula
[…]
LicenseConcluded: ae:BSD-3-Clause-copyright-holder-variant
[…]
LicenseConcluded: spdx:MIT AND ae:BSD-3-Clause-copyright-holder-variant
I’d also argue that you could define a default license namespace for an SPDX document. In this case you could omit the default namespace short-name prefix. The default would be spdx.
Isn’t it already the default. I don’t think we should have to specify that in a new way. This feels like a dilution of the SPDX License List.
… This even doesn’t break LicenseRef compatibility. LicenseRef is just a special case (no namespace available). This can compensate the compatibility concern raised by Philippe and enable a transition once namespaces are available.
Regards,
Karsten
—
Reply to this email directly, view it on GitHub <#681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGQSUYNODVZAQZHEK5VJZLVL5P3LANCNFSM5WEHR7FQ>.
You are receiving this because you were mentioned.
|
|
Proposal that we agree to use a syntax where the namespace is in the Reasoning:
|
|
Based on discussion with Alexios on 7/20, it doesn't look like we're going to resolve this for 2.3. Moving milestone to 3.0 |
|
Let's close this until we're more aligned on how to deal with the issue. |
Resurrecting the topic on license namespaces for late addition to 2.3.
I've re-worked the text that @swinslow had proposed back in #209, changing a few points to make the integration easier.
Things to note:
LicenseRef-.example.com.-EULA-v3.1andLicenseRef--ExampleCorp--EULA-v3.1Things left out, on purpose:
ExampleCorp:EULA-1.0or any other variant discussedLicenseNamespaceor other variantsAll these, and more, are essentially breaking changes and should be included in SPDX v3.x.
This change is essentially a description change to explain license namespaces and introduce an initial convention for their naming. It does not introduce much not already present in the way that licenses can be defined and used in external documents.
However, I think it's important that it is incorporated in v2.3, so that we have a way forward should v3 gets delayed for whatever reason.