Dear Michel I find your idea utmost interesting and would like to discuss it in further (sorry that I did not react earlier. Due to my recent transfer to EU with major expansion of job

Well, today we solve more or less this issue by requesting the URL where the FOSs can be downloaded, so URL + name + version number determine the FOSS used. It is not perfect but I never manage a good

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

Agreed, and this is pretty much what I just posted in another reply before having read yours :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@... |

I'm curious how you see this working. As I posted on the other SPDX list yesterday, I find the package-level metadata to be mandatory in order to have a high degree of trust in the rest of the

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

Hi Michel, Thanks for contributing details of your SPDX requirements to the mailing list! Apologies for lack of direct reaction to earlier postings, but as you note some of the existing use cases

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

No ALU has a DB with 5000entries for open source maintained since 2002 describing IPR issues. Since 2007we are requesting from all our suppliers the list of FOSS coming with theirproducts with

Fair enough. For you that might qualify as a large piece of information. You might choose not to accept SPDX files missing this information. Obviously any file not containing the information needed to

I would like to know more about the use case. If this is a producer use case where the SPDX is included with a set of files distributed, then the archive file would be the archive file produced and

I would question whether this is one 'tiny little piece' or not. In my role as a consumer of such incoming license information, I would be unwilling to accept SPDX data describing a package unless I

I cannot speak for Michel, but sometimes it *is* hard. The packageVerificationCode, for example, is constructed from checksums produced by a relatively weak hash algorithm. We analyzed many packages

So, you want Alcalu to have a private version of SPDX? Why not just support the mandatory elements? Is it so hard? Of is it just difficult in the corporate political scene? :-( William Boyle Senior

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

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

Dear all As you probably noticed Alcatel-Lucent is trying to implement the SPDX standard. We have an internal database on FOSS IP issues that has been created in 2002. and we are trying to implement

Hi Marc-Etienne, Thanks for catching these. The property name is rdfs:comment for Review. I went ahead and submitted bug 1046 to fix the spec. For 1.1, there is also a web page with the rdf terms

Sorry, the Subject of the message should read "Problem with Review Comments" -- Marc-Etienne Vargenau Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE +33 (0)1 30 77 28 33,

Hello, In the SPDX 1.0 and spdx-1.1-rc20120403.pdf I read: 7.3.6 RDF: property spdx:comment in class spdx:Review Example: <Review> <rdfs:comment> All of the licenses seen in the file, are matching