Re: Import and export function of SPDX
|
Gary O'Neall
Thanks Michel. This does describe the use case. I think this is an
toggle quoted message
Show quoted text
excellent discussion on which use cases require which fields. For the use case http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses- redistribution, there may really be two different use cases. The first is receiving the open source information (import) and the second is providing the information to downstream consumers (export). In my opinion, there would be value in capturing the archive file and verification information on the import and passing it through if available - you may want to consider adding this to your process going forward (this is something I recommend to my clients). Even with an open source database of a million+ packages, there will be specific versions missing where having the checksums would speed up any verification process. That being said, for any legacy information where this was not already collected and a few other common circumstances, I believe it would not be practical to capture these fields. Following are two situations I have run across in helping other commercial entities setup an open source inventory management and review process: - Legacy open source where the original downloaded source files were not saved and the origin website for download is no longer available. - Code copied from website postings where there is no "file" to checksum. This is the case for some JavaScript open source. I don't have any hard data to back up this claim, but I believe if we require the export to contain the verification code and archive file name for all open source code which is embedded in the product, very few larger commercial companies of any size would be able to comply. We have some good representation of large commercial companies redistributing open source software participating in SPDX, so I will defer to their opinions on this topic. I have a couple ideas on how we can implement an "SPDX-Lite" mechanism which may help in this situation. Once I get a bit more time, I'll write up a proposal in Bugzilla. Gary -----Original Message-----
From: RUFFIN, MICHEL (MICHEL) [mailto:michel.ruffin@...] Sent: Wednesday, June 13, 2012 5:45 AM To: Gary O'Neall; 'Peter Williams' Cc: spdx-tech@...; spdx@... Subject: RE: Import and export function of SPDX 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.: theI 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=Spec 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 |
|
|