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.
Jilayne Lovejoy | Corporate Counsel
jlovejoy@... | 720 240 4545
10910 W 120th Ave, Suite 450
Broomfield, Colorado 80021
Twitter @openlogic @cloudswing
On 6/13/12 6:45 AM, "RUFFIN, MICHEL (MICHEL)"
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
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
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
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
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
for some of the use cases where that information is not available. There
need to make sure the components described in the SPDX file match the
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.
[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.: theI think making those fields optional would be advantageous. Would you mind
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
filing a bug so that we don't forget to look into the issue for the
As for your immediate issues of not having data for those fields, if you
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
their goal. (In which case they cannot use your SPDX files, anyway.) If
are using the tag-value format skipping the fields altogether will, i
prove problematic due to that format's stricter syntactic constraints.
or Gary, can you confirm this?)
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