|
Re: Today's Agenda Legal WorkStream
kate.stewart@...
--- On Wed, 3/23/11, dmg <dmg@...> wrote:
|
|||||
|
|
|||||
|
SPDX: license equivalence rules
Peterson, Scott K (HP Legal) <scott.k.peterson@...>
Ths comment is NOT about what the normalization should be or what equivalences should be permitted. Rather, I suggest a different approach to how we represent the result of the agreed upon normalization/equivalence rules.
I suggest reconceiving "templatization" as defining "match rules".
Templatization seems to me to be a process of partially applying the match rules to take a step toward comparison. It is not apparent to me what the value is of giving that particular intermediate document special status.
I see a danger in two versions. Which contains the authoritative information? Whenever there are two, there is danger of them becoming misaligned.
There should be a single, canonical text. Applying the match rules against that canonical text and a candidate text would yield the authoritative answer to the question of whether the candidate text corresponds to the license represented by the canonical text.
Given the rules, anyone would be free to pre-process the canonical texts into whatever sorts of intermediate versions they thought would facilitate performance of their comparison tool. Choosing a particular intermediate version seems to add unnecessary complexity.
-- Scott
|
|||||
|
|
|||||
|
Re: Today's Agenda Legal WorkStream
Jilayne Lovejoy <jilayne.lovejoy@...>
I believe we already discussed this to some degree and decided that we would not enter the arena of word equivalents with the exception of spelling variations for known American-British English. Although there are certainly plenty of words that seem “safe” to equate, that begins to feel like a slippery slope in terms of the potential for different meanings or the license author’s intent getting altered. More specifically, many licenses have definitions for such words. Past and present tense can also be tricky, both from deciding how and when it’s okay to use either tense. All in all, I think it’s best to take a very conservative approach to what we will “replace” in terms of templatizing the licenses. We can always expand, but it would be very hard to roll it back later on. Just my two cents.
Certainly the BSD and Apache 1.1 licenses are problematic, because they are often verbatim with the exception of the author’s name in the third clause (BSD) and the third, fourth, and fifth clause (Apache 1.1) as well as the disclaimer sections for both. We are working through how/where to capture this, as well as copyright notices in general, though. Jilayne On 3/23/11 10:11 AM, "Kate Stewart" <kate.stewart@...> wrote:
Jilayne Lovejoy | Corporate Counsel jlovejoy@... 720 240 4545 | phone 720 240 4556 | fax 1 888 OpenLogic | toll free www.openlogic.com OpenLogic, Inc. 10910 W 120th Ave, Suite 450 Broomfield, Colorado 80021
|
|||||
|
|
|||||
|
Re: Today's Agenda Legal WorkStream
dmg
On Wed, Mar 23, 2011 at 9:48 AM, Jilayne Lovejoy <Jlovejoy@...> wrote: I believe we already discussed this to some degree and decided that we would not enter the arena of word equivalents with the exception of spelling variations for known American-British English. Although there are certainly plenty of words that seem “safe” to equate, that begins to feel like a slippery slope in terms of the potential for different meanings or the license author’s intent getting altered. More specifically, many licenses have definitions for such words. Past and present tense can also be tricky, both from deciding how and when it’s okay to use either tense. All in all, I think it’s best to take a very conservative approach to what we will “replace” in terms of templatizing the licenses. We can always expand, but it would be very hard to roll it back later on. Just my two cents. I agree. I wonder if a solution is to allow the specification of "variant" of a license. Perhaps a way to say: the closest license is this one, with a text similarity metric of X, and where the differences are such and such. Otherwise a lot of BSD and MIT licensed files will be listed as unknown/other. --dmg Certainly the BSD and Apache 1.1 licenses are problematic, because they are often verbatim with the exception of the author’s name in the third clause (BSD) and the third, fourth, and fifth clause (Apache 1.1) as well as the disclaimer sections for both. We are working through how/where to capture this, as well as copyright notices in general, though. -- --dmg --- Daniel M. German http://turingmachine.org
|
|||||
|
|
|||||
|
Re: SPDX: license equivalence rules
Kate Stewart <kate.stewart@...>
Hi Scott,
On Wed, 2011-03-23 at 16:33 +0000, Peterson, Scott K (HP Legal) wrote: Ths comment is NOT about what the normalization should be or whatThe problem is that the today the various tools have nothing to check against to make sure that they are applying the rules correctly. The templatized version is intended as a tool checker, that the right substitutions can be recognized rather than as an alternate human readable reference. The golden reference should always be whats on the official public web site of a license - which is human readable. The official authoritative version will be copied onto the SPDX web site verbatim. The proposal is to have the processed version there as well, and marked as such, so that when there are disagreements between various tools doing license recognition and asserting the short form, they have a common comparison point. Its intended more like an answer sheet for a teacher administering a test to students to know what answers are ok, and which aren't. For instance, I believe that Daniel German (Ninka tool) and Bob Gobeille (FOSSology tool) get together from time to time (or intended to last I talked to them about it, last year) to talk about why their tools don't recognize same licenses. Having a templatized license text would aid future tool creators (open source as well as commercial vendors) to check that they are able to recognize a license accurately before asserting the short form. It is meant to illustrates what should happen when the match rules are applied. As a check for the tools, and to build confidence that the match rules the spdx-legal team is comfortable, are applied consistently. The authoritative version is the version on the project's public web site. In some cases the OSI site has a copy and is used as the authoritative version though. We copy that version onto the SPDX web page for convenience, as well as, the link to the authoritative public site we get this from. On the SPDX web page, we'll also be adding the "templatized" version as a convenience, after the rules have been applied to the original authorized version, so folks can see what the results of applying the match rules yields ("the answer sheet" for the test to continue with my earlier analogy). The single canonical text will be copied verbatim (spaces, capitalization, etc. ) intact from the authorative web site for that license. The templatized version is just the result of applying the match rules to the authorative version. We should definitely take care to make this VERY clear on the web site. see comments above. Kate
|
|||||
|
|
|||||
|
Re: SPDX: license equivalence rules
Peter Williams <peter.williams@...>
I think having some examples of text with the normalization rules applied is a good idea. However those examples should be in the spec. Having to go to the registry to see examples will make it harder to implement the normalization algorithm. If the only use of the normalized text for standard licenses is for example purposes, I don't think we really need to do all the licenses. Not having the normalized text in the registry would make its design easier. (The versioning issues are particularly non-trivial.) Peter On Mar 23, 2011 10:21 AM, "Kate Stewart" <kate.stewart@...> wrote: > Hi Scott, > > On Wed, 2011-03-23 at 16:33 +0000, Peterson, Scott K (HP Legal) wrote: >> Ths comment is NOT about what the normalization should be or what >> equivalences should be permitted. Rather, I suggest a different >> approach to how we represent the result of the agreed upon >> normalization/equivalence rules. >> >> >> >> I suggest reconceiving "templatization" as defining "match rules". >> > > The problem is that the today the various tools have nothing to check > against to make sure that they are applying the rules correctly. > > The templatized version is intended as a tool checker, that the right > substitutions can be recognized rather than as an alternate human > readable reference. The golden reference should always be whats on the > official public web site of a license - which is human readable. The > official authoritative version will be copied onto the SPDX web site > verbatim. The proposal is to have the processed version there as well, > and marked as such, so that when there are disagreements between various > tools doing license recognition and asserting the short form, they have > a common comparison point. > > Its intended more like an answer sheet for a teacher administering a > test to students to know what answers are ok, and which aren't. > > For instance, I believe that Daniel German (Ninka tool) and Bob > Gobeille (FOSSology tool) get together from time to time (or intended to > last I talked to them about it, last year) to talk about why their tools > don't recognize same licenses. Having a templatized license text would > aid future tool creators (open source as well as commercial vendors) to > check that they are able to recognize a license accurately before > asserting the short form. > > It is meant to illustrates what should happen when the match rules are > applied. > >> >> Templatization seems to me to be a process of partially applying the >> match rules to take a step toward comparison. It is not apparent to me >> what the value is of giving that particular intermediate document >> special status. >> > > As a check for the tools, and to build confidence that the match rules > the spdx-legal team is comfortable, are applied consistently. > >> >> I see a danger in two versions. Which contains the authoritative >> information? Whenever there are two, there is danger of them becoming >> misaligned. >> > The authoritative version is the version on the project's public web > site. In some cases the OSI site has a copy and is used as the > authoritative version though. > > We copy that version onto the SPDX web page for convenience, as well as, > the link to the authoritative public site we get this from. > > On the SPDX web page, we'll also be adding the "templatized" version as > a convenience, after the rules have been applied to the original > authorized version, so folks can see what the results of applying the > match rules yields ("the answer sheet" for the test to continue with my > earlier analogy). > >> >> There should be a single, canonical text. Applying the match rules >> against that canonical text and a candidate text would yield the >> authoritative answer to the question of whether the candidate text >> corresponds to the license represented by the canonical text. >> > > The single canonical text will be copied verbatim (spaces, > capitalization, etc. ) intact from the authorative web site for that > license. > > The templatized version is just the result of applying the match rules > to the authorative version. > > We should definitely take care to make this VERY clear on the web site. > >> >> Given the rules, anyone would be free to pre-process the canonical >> texts into whatever sorts of intermediate versions they thought would >> facilitate performance of their comparison tool. Choosing a particular >> intermediate version seems to add unnecessary complexity. >> > > see comments above. > > Kate > > > > > _______________________________________________ > Spdx-legal mailing list > Spdx-legal@... > https://fossbazaar.org/mailman/listinfo/spdx-legal
|
|||||
|
|
|||||
|
Re: Today's Agenda Legal WorkStream
Jilayne Lovejoy <jilayne.lovejoy@...>
These variant licenses would simply end up needing to be added as a “nonstandard” license, meaning the SPDX generator would not be able to use the standardized SPDX license list shortname for that license, but it wouldn’t (shouldn’t) be tagged as unknown in such a case.
On 3/23/11 10:54 AM, "dmg" <dmg@...> wrote:
Jilayne Lovejoy | Corporate Counsel jlovejoy@... 720 240 4545 | phone 720 240 4556 | fax 1 888 OpenLogic | toll free www.openlogic.com OpenLogic, Inc. 10910 W 120th Ave, Suite 450 Broomfield, Colorado 80021
|
|||||
|
|
|||||
|
Re: Today's Agenda Legal WorkStream
Philip Odence
Yes, and let's not forget this same point when we are talking about the process of adding new license to the standard list. The discussion is never whether the license can be included in an SPDX file—it always can be—the only issue from the SPDX file creator's perspective is whether it matches a license on the standard list with a predefined short name, or whether they have to go the one extra step of including the license text in Section 4. Licensing Info and create their own local short name. From: Jilayne Lovejoy <jilayne.lovejoy@...> Date: Thu, 24 Mar 2011 17:26:20 -0400 To: dmg <dmg@...>, Jilayne Lovejoy <Jlovejoy@...> Cc: Kate Stewart <kate.stewart@...>, "spdx-legal@..." <spdx-legal@...>, "spdx@..." <spdx@...>, Esteban Rockett <mgia3940@...> Subject: Re: Today's Agenda Legal WorkStream These variant licenses would simply end up needing to be added as a “nonstandard” license, meaning the SPDX generator would not be able to use the standardized SPDX license list shortname for that license, but it wouldn’t (shouldn’t) be tagged as unknown in such a case. On 3/23/11 10:54 AM, "dmg" <dmg@...> wrote:
Jilayne Lovejoy | Corporate Counsel jlovejoy@... 720 240 4545 | phone 720 240 4556 | fax 1 888 OpenLogic | toll free www.openlogic.com OpenLogic, Inc. 10910 W 120th Ave, Suite 450 Broomfield, Colorado 80021
|
|||||
|
|
|||||
|
Re: Today's Agenda Legal WorkStream
dmg
Philip Odence twisted the bytes to say:
Philip> Yes, and let's not forget this same point when we are talking about the process of adding new license to the standard list. The discussion is never Philip> whether the license can be included in an SPDX file—it always can be—the only issue from the SPDX file creator's perspective is whether it matches a Philip> license on the standard list with a predefined short name, or whether they have to go the one extra step of including the license text in Section 4. Philip> Licensing Info and create their own local short name. One interesting aspect of licenses that are "almost" a match is that, if they are only listed as "unknown", the knowledge/analysis performed by the SPDX-file's author might be lost (why is such license unknown). Perhaps a "comment" field attached to any attribute (file, package, etc) that can have a license would be very useful to include a rational. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with .
|
|||||
|
|
|||||
|
License List v1.7 uploaded to wiki (finally)
Jilayne Lovejoy <jilayne.lovejoy@...>
With a few minor changes and the ‘.0’ put back in the short names. This should be (close to?) the final first version...
Find it here: http://spdx.org/wiki/working-version-license-list I also uploaded a new “guidelines” document that has links to the template issues and British-American word substitution pages on the wiki. Once all this information gets finalized, it would be good to turn this into a page unto itself, perhaps? Jilayne Lovejoy | Corporate Counsel jlovejoy@... 720 240 4545 | phone 720 240 4556 | fax 1 888 OpenLogic | toll free www.openlogic.com OpenLogic, Inc. 10910 W 120th Ave, Suite 450 Broomfield, Colorado 80021
|
|||||
|
|
|||||
|
license html files for the license repository
Gary O'Neall
Hi Martin,
In the SPDX tech face to face meeting we discussed adding the license information to the spdx website at spdx.org/licenses. Attached is the output of a tool that converts the license spreadsheet to a set of html files.
This uses the latest version 1.7 of the spreadsheet which I believe is final for Beta.
The file index.html contains a table. We would like to add this to the website. If you want to modify the look and feel of any of the pages, feel free to change – if you email me back an example of the index html file and one of the license files and any modified .css files, I’ll update the tool to produce that style (I’m hoping you just need to change the .css files ;)
Note: I did need to modify the format of the spreadsheet slightly to make it through the tool. I change the name of sheet1 to “Licenses” and removed the leading space from cell A1 “ Full name of License”. Attached is an updated spreadsheet (version 1.7g).
I also noticed that there are 4 licenses which do not have any text:
Let me know if you have any questions.
Thanks,
|
|||||
|
|
|||||
|
Re: license html files for the license repository
Jilayne Lovejoy <jilayne.lovejoy@...>
Hi Gary and everyone,
I could not open the spreadsheet you said, as I got a corrupted message, but in any case, I made the changes/additions you mentioned below and re-uploaded a “v1.8” to the SPDX site at http://spdx.org/wiki/working-version-license-list (in both Excel and OpenOffice formats – finally... :) I don’t know what happened to those license texts – one of them I had a “not found” note, yet I found it this time looking. In any case, the license text for the license you list below has been added to this newest version. As for your html files – looks great! My only feedback is that where it lists the url it just shows “www” as the hot link. Is there anyway for that to show the actual url address? Two other license list related things – is there anyway to change the link for the License List that is on Specification page (here: http://spdx.org/node/2456 ) to the link above? Also, the license list page has ALL the uploads of each version – this seems a bit messy and potentiall confusing. Would it be better to delete the older versions, so only the current one is listed? Or do we want to keep all the prior versions for transparency/archival purposes? Cheers, Jilayne On 4/8/11 11:06 AM, "Gary O'Neall" <gary@...> wrote: Hi Martin, Jilayne Lovejoy | Corporate Counsel jlovejoy@... 720 240 4545 | phone 720 240 4556 | fax 1 888 OpenLogic | toll free www.openlogic.com OpenLogic, Inc. 10910 W 120th Ave, Suite 450 Broomfield, Colorado 80021
|
|||||
|
|
|||||
|
Re: license html files for the license repository
Gary O'Neall
Thanks Jilayne for the updates and review. I just downloaded the 1.8 version of the spreadsheet and I can not open it in excel (the open office version worked fine). It turns out that the application, however, does not have any problems with it.
I removed the license text referenced below and I was able to convert. Other than that, the new license spreadsheet works fine.
I fixed the bug with the bad name for the external license links – they are now the entire URL.
I’ll leave the site link questions to Martin.
Attached is an updated set of HTML pages.
From: Jilayne Lovejoy [mailto:jilayne.lovejoy@...]
Sent: Monday, April 11, 2011 1:48 PM To: Gary O'Neall; Martin Michlmayr Cc: spdx-tech@...; spdx-legal@...; spdx-biz@... Subject: Re: license html files for the license repository
Hi Gary and everyone, Hi Martin, _______________________________________________
|
|||||
|
|
|||||
|
Open Data License
Esteban Rockett <mgia3940@...>
All:
As discussed during yesterday's call, below please find links for your review. Many thanks, Rockett ---------- Forwarded message ---------- From: Copenhaver, Karen <kcopenhaver@...> Date: Wed, Apr 13, 2011 at 8:33 AM Subject: Open Data License To: "E. A. Rockett (rockett@...)" <rockett@...> And because I think we have decided that we do not want to require any attribution, I was focused on this:
If the SPDX does not have any identifying information, this may be appropriate.
If the SPDX does have identifying information, then this may appear to be inconsistent with a company providing for confidentiality (although see 2.2) and may cause concern. But if the SPDX
that is covered by this "license" is entirely anonymous, I think there is a lot of work here and it would be great is we could leverage it.
For some context:
|
|||||
|
|
|||||
|
SPDX and Support
Esteban Rockett <mgia3940@...>
FYI all ...
toggle quoted messageShow quoted text
Begin forwarded message: From: "Copenhaver, Karen" <kcopenhaver@...> Date: April 14, 2011 6:32:19 AM PDT To: "E. A. Rockett (rockett@...)" <rockett@...> Subject: FW: SPDX and Support More information to distribute to the group. Dan is one of the original Samba team.
-----Original Message----- From: Dan Shearer [mailto:dan@...] Sent: Thursday, April 14, 2011 7:36 AM To: Copenhaver, Karen Subject: SPDX and Support Karen, Eben makes a powerful point about SPDX and solving compliance problems with embedded devices, but there is another angle. Compliance is at best a neutral and often negative point; the contribution SPDX could make to support operations is very positive. A lot of wasted time and financial overhead on both ends of a support desk call relates to finding SPDX information, or information one logical hop away from SPDX data. So if an SPDX or collection of them can be supplied in the initial query: 1. The respondant has a good idea of what the alleged fault relates to, including having a list of known issues. 2. Much support relates to *interactions* of software rather than a piece of software in isolation. So having SPDXs for the software that is in the same environment as the software in question could be very useful. Of course SPDX says nothing about how software is configured or used, but still, it is valuable information that is often incomplete, wrong or missing in support requests. 3. It opens up the idea of another automated step in the support process, a conversation around exchanging lists of SPDX records. 4. As far as I am aware SPDX is commonly thought of as a here-and-now facility. But in the context of support requests it would be extremely helpful to know the history over time. 5. Depending (techies always say that :) the SPDX(es) could be used to create a virtual machine containing all the software at issue in the initial support request ready for the technician to use as required. And, in the case of (4) above, multiple virtual machines to help determine when a problem may have been introduced. -- Dan Shearer dan@... Confidentiality Statement: This Message is transmitted to you by the law firm of Choate, Hall & Stewart LLP. The substance of this message, along with any attachments, may be confidential and legally privileged. If you are not the designated recipient of this message, please destroy it and notify the sender of the error by return e-mail or by calling 1-800-520-2427. Under regulations of the Treasury Department, we are required to include the following statement in this message: Any advice contained herein (or in any attachment hereto) regarding federal tax matters was not intended or written by the sender to be used, and it cannot be used by any taxpayer, for the purpose of avoiding penalties that may be imposed on the taxpayer. For more information about Choate, Hall & Stewart LLP, please visit us at choate.com
|
|||||
|
|
|||||
|
Agenda for today's meeting ...
Esteban Rockett <mgia3940@...>
All:
For today's meeting I propose we: (1) focus on the "meta-data confidentiality/licensing" issue, and any feedback/reaction from your independent review of Open Data Commons PDDL 1.0 (http://www.opendatacommons.org/licenses/pddl/1.0/); AND (2) focus on how to handle the "confidential" marking field. If we can conquer and conclude the above today, that will be fantastic. Many thanks, Rockett
|
|||||
|
|
|||||
|
Re: Open Data License
Benjamin Jean <mjeanb@...>
Hi all,
toggle quoted messageShow quoted text
Concerning the license, did you discuss about the ODbL (which can be use without requiring any attribution)? It should be a good license too, but I don't know if it fits the needs: * it's a copyleft database dedicated license -- for instance used for OSM (I also recommended its use for the Open Data in Paris) ; * a more permissive license might facilitate the SPDX adoption -- but do we focus on the users or the project? http://www.opendatacommons.org/licenses/odbl/ Best, Benjamin
Le jeudi 14 avril 2011 à 06:48 -0700, Esteban Rockett a écrit :
All:
|
|||||
|
|
|||||
|
Re: Open Data License
Benjamin Jean <mjeanb@...>
Hi all,
toggle quoted messageShow quoted text
Concerning the license, did you discuss about the ODbL (which can be use without requiring any attribution)? It should be a good license too, but I don't know if it fits the needs: * it's a copyleft database dedicated license -- for instance used for OSM (I also recommended its use for the Open Data in Paris) ; * a more permissive license might facilitate the SPDX adoption -- but do we focus on the users or the project? http://www.opendatacommons.org/licenses/odbl/ Best, Benjamin
Le jeudi 14 avril 2011 à 06:48 -0700, Esteban Rockett a écrit :
All:
|
|||||
|
|
|||||
|
Revisting proposed terminology definitions
Kirsten Newcomer <knewcomer@...>
Hi all,
In reviewing the SPDX Specification at the Linux Collab Summit face-to-face, the team noticed that there was some inconsistency regarding the use of the terms UNKNOWN, UNDETERMINED, NONE, etc. After a detailed review of the occurrences of these terms, and much discussion, the SPDX Technical group has proposed the following replacement terminology. We'd like to get sign-off from the Legal team before we finalize. Bill Schineller has volunteered to attend the Legal team meeting this week to review the proposal and collect feedback. Note that we need to finalize the terms we plan to use for beta. Definitions:
Occurrences/Use:
Kirsten Kirsten Newcomer Senior Product Manager Black Duck Software, Inc. knewcomer@... Office: +1.781.810.1839 Mobile: +1.781-710-2184
|
|||||
|
|
|||||
|
Re: Revisting proposed terminology definitions
Peterson, Scott K (HP Legal) <scott.k.peterson@...>
Unfortunately, I will not be able to attend the legal meeting this week.
But, I would like to offer a comment on the proposed 3 no-value values:
I see terms for: - determined - no attempt to determine
What value does someone use if, after analysis, they concluded that they were unable to determine the value for this parameter?
I don’t think it is important whether something was subjected to analysis or not. What is important is whether a determination was made.
Thus, I suggest that the description for the third value might be better described as follows:
“Indicates that the preparer of the SPDX document did not determine the value of this field.”
Since ‘analysis’ isn’t key, the name for the value might be changed to something like: NOTDETERMINED
-- Scott
From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Kirsten Newcomer
Sent: Monday, May 02, 2011 3:34 PM To: spdx-legal@... Cc: spdx-tech@... Subject: Fwd: Revisting proposed terminology definitions
Hi all,
In reviewing the SPDX Specification at the Linux Collab Summit face-to-face, the team noticed that there was some inconsistency regarding the use of the terms UNKNOWN, UNDETERMINED, NONE, etc. After a detailed review of the occurrences of these terms, and much discussion, the SPDX Technical group has proposed the following replacement terminology.
We'd like to get sign-off from the Legal team before we finalize. Bill Schineller has volunteered to attend the Legal team meeting this week to review the proposal and collect feedback. Note that we need to finalize the terms we plan to use for beta.
Definitions:
Occurrences/Use:
Thanks!
Kirsten
Kirsten Newcomer
|
|||||
|
|