Re: Import and export function of SPDX
|
RUFFIN MICHEL
For the definition of FOSS (free and/or open source software (free is for free of cost here)) that we provide it is of course in the context of a contract negotiation. It is everything that do not go through a procurement department, i.e. coming with an implicit license: a click to accept EULA, an OSI compliant license or similar, + shareware and of course public domain. This definition is now accepted without discussion by most of our suppliers because it is quite clear (we had a lot of revisions before coming to this definition). Note that we use this definition internally in ALU for our FOSS governance process.
A comment on licenses, what I find confusing in the SPDX standard is the numbering of BSD licenses for instance the BSD 4 clause is in fact the original BSD license and I would have call it BSD1. But that’s not very important. What is important is to stabilize this taxonomy because we cannot change every year the content of our FOSS database, our internal FOSs governance process documents (around 80 pages), our internal tutorials (170 slides), our requests to suppliers, an update of the knowledge of our FOSs experts, etc.
Michel.Ruffin@..., PhD Software Coordination Manager, Bell Labs, Corporate CTO Dpt Distinguished Member of Technical Staff Tel +33 (0) 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux Route De Villejust, 91620 Nozay, France
-----Message d'origine-----
De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] Envoyé : vendredi 22 juin 2012 01:33 À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams Cc : spdx-tech@...; spdx@... Objet : Re: Import and export function of SPDX
(Apologies for falling off this exchange - had some other things come up and am now getting caught up with various responses - lots of great discussion, though!)
On 6/13/12 9:34 AM, "RUFFIN, MICHEL (MICHEL)" <michel.ruffin@...> wrote:
>So far our FOSS clauses are not aligned on the SPDX standard (we are >already happy when suppliers can comply to our requirements without too >much discussion so we did not formalize things too much)
One thing I noticed immediately about your clauses is the definition of FOSS - which is quite broad. While I can understand why it might make sense to use a broad definition for contracts, it includes some categories of software (e.g. (ii) and (iii) in your definition) that other people/parties might not consider "FOSS." In terms of the SPDX License List, for example, I believe (if memory serves) that we discussed to what "kinds" of licenses should be included on the list and an argument against including, what I would refer to as "freeware" licenses (usually under some kind of click-through EULA that more resembles a more traditional, restrictive IP license, than open source) should not be on the list. I don't know if this definition's breadth would necessarily create a conflict in practical reality or not, but thought I'd at least point it out...
> >What we request is the name of FOSS, the name of the license if it is OSI >compliant, or a copy of the license if it is not, the nature of the FOSS: >is it a library, a standalone software, an interpreter, ... in order to >determine if there is some potential contamination as with GPL. > >Now we have already aligned our database on the SPDX taxonomy for naming >licenses, we will soon ask our suppliers to align on this taxonomy. I >have already prepared a document (in copy) to distribute to our suppliers >and partners on SPDX.
Thanks for sharing this. Really great to hear that you have adopted the SPDX License List already. I'm not sure if you or anyone from your team is on the legal work group mailing list, but that may be helpful to stay on top of issues/updates/discussion there. (for example, a new version of the license list was just uploaded this week :)
Jilayne
Jilayne Lovejoy | Corporate Counsel OpenLogic, Inc.
jlovejoy@... <applewebdata://EAA1F861-B11E-4827-976F-55756901A796/jlovejoy@... > | 720 240 4545
> > >-----Message d'origine----- >De : Jilayne Lovejoy [mailto:jilayne.lovejoy@...] >Envoyé : mercredi 13 juin 2012 16:08 >À : RUFFIN, MICHEL (MICHEL); Gary O'Neall; Peter Williams >Cc : spdx-tech@...; spdx@... >Objet : Re: Import and export function of SPDX > >Hi Michel, > >Thanks again for sharing your information. In regards to your posting (to >both this group and the FSF legal network) about the legal clauses, I have >noticed this and apologize as well for not responding sooner (it's still >in my inbox as a to-do item, sadly). In any case, a couple thoughts. It >is my understanding from your previous email(s), that you'd like to see >some kind of FOSS-related legal clause resource, is that correct? At the >moment, this is not within the scope of SPDX (albeit a great idea >generally!). This is probably something that could be discussed further >in terms of something to consider tackling in the longer-term road map. > >More specifically, your "list of FOSS" clause (a)(ii), you require the >name of the license, license text, and whether it is OSI certified or not. > This is all information capture in the SPDX License List. Do you have an >internal list as well? If so, it would be great to discuss aligning any >licenses on your list for potential inclusion on the SPDX License List, if >not already included there and otherwise coordinating. > >Cheers, > >Jilayne Lovejoy | Corporate Counsel >jlovejoy@... | 720 240 4545 >Twitter @jilaynelovejoy > >OpenLogic, Inc. >10910 W 120th Ave, Suite 450 >Broomfield, Colorado 80021 >www.openlogic.com >Twitter @openlogic @cloudswing > > > > >On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)" ><michel.ruffin@...> wrote: > >>Gary, I think in my previous mail I expressed our use case: >>1) getting information from our suppliers on FOSS included in their >>products in order to respect license obligations and to provide this to >>our customers >>2) automate the work of ALU for accepting this FOSS in our products >>3) being able to provide the same information to our customers. >> >>I think it is covered by actual use cases, if not I can do a new one. >> >>Now I would like to attract your attention on a document that I sent few >>months ago to this mailing list and also to the FSF legal network group. >>Which are the clauses that we put in the contracts with our suppliers and >>their rationnal. The goal is to standardize these clauses and I receive >>no feedback from anybody on this. >> >>This should illustrate the use case. And I understand that I should use >>the FSF legal network to discuss this. But I am very surprised that there >>is no reaction/interest in this. It has been a huge ALU effort to shape >>these conditions in order to reach acceptance to these conditions by most >>companies. >> >>Michel.Ruffin@..., PhD >>Software Coordination Manager, Bell Labs, Corporate CTO Dpt >>Distinguished Member of Technical Staff >>Tel +33 (0) 6 75 25 21 94 >>Alcatel-Lucent International, Centre de Villarceaux >>Route De Villejust, 91620 Nozay, France >> >> >>-----Message d'origine----- >>De : Gary O'Neall [mailto:gary@...] >>Envoyé : mardi 12 juin 2012 19:29 >>À : 'Peter Williams'; RUFFIN, MICHEL (MICHEL) >>Cc : spdx-tech@...; spdx@... >>Objet : RE: Import and export function of SPDX >> >>I believe the current SPDX tools will treat both RDF and Tag/Value in the >>same manner - the documents will be readable by the tools but it will >>fail a >>validation (missing required field). For the command line tools, the >>conversions or pretty printing will still work but you will get warning. >> >>In terms of making the fields optional - I can see this as a valuable >>change >>for some of the use cases where that information is not available. There >>is >>need to make sure the components described in the SPDX file match the >>actual >>file artifacts, but that need can be filled by the per-file information. >> >>Michel - Which use case best describes your use of SPDX >>(http://spdx.org/wiki/spdx-20-use-cases). If there isn't a good >>representation of your use case(s), could you provide a brief >>description? >>I want to make sure we cover this when working on SPDX 2.0. >> >>Thanks, >>Gary >> >>-----Original Message----- >>From: spdx-tech-bounces@... >>[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams >>Sent: Tuesday, June 12, 2012 9:27 AM >>To: RUFFIN, MICHEL (MICHEL) >>Cc: spdx-tech@...; spdx@... >>Subject: Re: Import and export function of SPDX >> >>On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote: >>> We have an issue with 2 fields that do not exist in our database.: the >>> name of the archive file and the checksum. In the SPDX standard they >>> are mandatory and I do not see why would it be possibly to make them >>> optional? >> >>I think making those fields optional would be advantageous. Would you >>mind >>filing a bug[1] so that we don't forget to look into the issue for the >>next >>version. >> >>As for your immediate issues of not having data for those fields, if you >>are >>using RDF i'd just skip them altogether in the SPDX file. While your file >>will technically be invalid all reasonable SPDX consumers will not have a >>problem with that information being absent unless they need it to >>accomplish >>their goal. (In which case they cannot use your SPDX files, anyway.) If >>you >>are using the tag-value format skipping the fields altogether will, i >>think, >>prove problematic due to that format's stricter syntactic constraints. >>(Kate >>or Gary, can you confirm this?) >> >>[1]: >>https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spe >>c >> >>Peter >> >>PS: I am cc-ing the technical working group because it's participants are >>best suited to answer these sorts of issues. >> >>_______________________________________________ >>Spdx-tech mailing list >>Spdx-tech@... >>https://lists.spdx.org/mailman/listinfo/spdx-tech >> >> > >
|
|
|