Date
1 - 20 of 25
Import and export function of SPDX
RUFFIN MICHEL
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 an import/export function in SPDX standard.
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?
See bellow details
Michel
There are two fields that are mandatory in SPDX but have no equivalent in the
Alcatel-Lucent FOSS database.
These fields are:
4.3 Package File Name
4.3.1 Purpose: Provide the actual file name of the package. This may include the
packaging and compression methods used as part of the file name.
4.3.2 Intent: Here, the actual file name of the compressed file containing the
package is a significant technical element that needs to be included with each
package identification information.
4.3.3 Cardinality: Mandatory, one.
4.7 Package Verification Code
4.7.1 Purpose: This field provides an independently reproducible mechanism
identifying specific contents of a package based on the actual files (except the
SPDX file itself, if it is included in the package) that make up each package
and that correlates to the data in this SPDX file. This identifier enables a
recipient to determine if any file in the original package (that the analysis
was done on) has been changed and permits inclusion of an SPDX file as part of a
package.
4.7.2 Intent: Providing a unique identifier based on the files inside each
package, eliminates confusion over which version or modification of a specific
package the SPDX file refers to. The SPDX file can be embedded within the
package without altering the identifier.
4.7.3 Cardinality: Mandatory, one.
Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff
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
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
Peter Williams <peter.williams@...>
On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote:
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.
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.
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?
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.
Gary O'Neall
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
toggle quoted message
Show quoted text
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:
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
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
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?
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
William Boyle
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? :-(
toggle quoted message
Show quoted text
William Boyle
Senior Systems Engineer
Nokia Mobile Phones
On Tue, Jun 12, 2012 at 7:02 AM, RUFFIN, MICHEL (MICHEL) <michel.ruffin@...> wrote:
Dear allAs 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 an import/export function in SPDX standard.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?See bellow detailsMichelThere are two fields that are mandatory in SPDX but have no equivalent in theAlcatel-Lucent FOSS database.These fields are:4.3 Package File Name4.3.1 Purpose: Provide the actual file name of the package. This may include thepackaging and compression methods used as part of the file name.4.3.2 Intent: Here, the actual file name of the compressed file containing thepackage is a significant technical element that needs to be included with eachpackage identification information.4.3.3 Cardinality: Mandatory, one.4.7 Package Verification Code4.7.1 Purpose: This field provides an independently reproducible mechanismidentifying specific contents of a package based on the actual files (except theSPDX file itself, if it is included in the package) that make up each packageand that correlates to the data in this SPDX file. This identifier enables arecipient to determine if any file in the original package (that the analysiswas done on) has been changed and permits inclusion of an SPDX file as part of apackage.4.7.2 Intent: Providing a unique identifier based on the files inside eachpackage, eliminates confusion over which version or modification of a specificpackage the SPDX file refers to. The SPDX file can be embedded within thepackage without altering the identifier.4.7.3 Cardinality: Mandatory, one.Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical StaffTel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Peter Williams <peter.williams@...>
On Tue Jun 12 12:12:42 2012, William Boyle wrote:
So the questions is: Is it better to have SPDX files which contain a large amount of truly useful information but that are incomplete or should we hide all that information because we are missing one tiny little piece?
I'd vote for not letting the best be the enemy of the good. The more information people have the better their decisions will be, even if that information is incomplete. The real world is imperfect, messy and ambiguous which is why being liberal in what is accepted is a virtue[1] for an data exchange format. Just look at HTML -- probably one of the most interoperable formats ever created -- would it have succeeded if browsers had been pedantic about the HTML format? I seriously doubt it, just look at the (lack of) adoption of strict XHTML.
[1]: http://en.wikipedia.org/wiki/Robustness_principle
Peter
Why not justI 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 before the advent of SPDX and collected checksums using a much stronger algorithm. We no longer have access to many of those packages. In that situation it is *impossible* to produce an SPDX file with a packageVerificationCode.
support the mandatory elements? Is it so hard? Of is it just difficult
in the corporate political scene? :-(
So the questions is: Is it better to have SPDX files which contain a large amount of truly useful information but that are incomplete or should we hide all that information because we are missing one tiny little piece?
I'd vote for not letting the best be the enemy of the good. The more information people have the better their decisions will be, even if that information is incomplete. The real world is imperfect, messy and ambiguous which is why being liberal in what is accepted is a virtue[1] for an data exchange format. Just look at HTML -- probably one of the most interoperable formats ever created -- would it have succeeded if browsers had been pedantic about the HTML format? I seriously doubt it, just look at the (lack of) adoption of strict XHTML.
[1]: http://en.wikipedia.org/wiki/Robustness_principle
Peter
Kevin P. Fleming <kpfleming@...>
On 06/12/2012 03:06 PM, Peter Williams wrote:
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
So the questions is: Is it better to have SPDX files which contain aI 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 could conclusively confirm that the package supplied matched the data in the SPDX file.
large amount of truly useful information but that are incomplete or
should we hide all that information because we are missing one tiny
little piece?
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
Gary O'Neall
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 the verification code could be calculated from the files included in the
archive.
If this is an intermediate use case where existing packages are being
documented as SPDX files, I could see where it is more challenging to obtain
the archive file and verification code from the original package unless the
original package included an SPDX file or the original archive file was
maintained.
Gary
toggle quoted message
Show quoted text
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 the verification code could be calculated from the files included in the
archive.
If this is an intermediate use case where existing packages are being
documented as SPDX files, I could see where it is more challenging to obtain
the archive file and verification code from the original package unless the
original package included an SPDX file or the original archive file was
maintained.
Gary
-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On
Behalf Of Kevin P. Fleming
Sent: Tuesday, June 12, 2012 3:21 PM
To: spdx@...
Subject: Re: Import and export function of SPDX
On 06/12/2012 03:06 PM, Peter Williams wrote:
as a consumer of such incoming license information, I would be unwilling to
accept SPDX data describing a package unless I could conclusively confirm
that the package supplied matched the data in the SPDX file.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
From: spdx-bounces@... [mailto:spdx-bounces@...] On
Behalf Of Kevin P. Fleming
Sent: Tuesday, June 12, 2012 3:21 PM
To: spdx@...
Subject: Re: Import and export function of SPDX
On 06/12/2012 03:06 PM, Peter Williams wrote:
So the questions is: Is it better to have SPDX files which contain aI would question whether this is one 'tiny little piece' or not. In my role
large amount of truly useful information but that are incomplete or
should we hide all that information because we are missing one tiny
little piece?
as a consumer of such incoming license information, I would be unwilling to
accept SPDX data describing a package unless I could conclusively confirm
that the package supplied matched the data in the SPDX file.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Peter Williams <peter.williams@...>
On Tue Jun 12 16:20:35 2012, Kevin P. Fleming wrote:
Is it worse to receive a data set that is too incomplete to use for your purpose, or not receive any data at all? It seems to me that to two situations are practically the same, in either case you have no new information. On the other hand, if you can accomplish your goal with the incomplete data set, then receiving it improves your situation substantially. Let's err on the side of helping as many people as possible.
Even if you choose not to accept an incomplete file verbatim, having it might still be advantageous. If nothing else it gives you a place to start your investigation. For example, if i receive an SPDX file w/o a packageVerificationCode, i might decide i need to do my own analysis of the package i am using because i cannot verify that is exactly the one described by the SPDX file. Fortunately, the licensing of software packages rarely change dramatically between versions so i could use the untrusted SPDX data as a starting point. Such a head start would be likely to save a great deal of time and effort. This would be about the same process needed if i received an SPDX file with a packageVerificationCode that did not match my package.
Peter
PS: This is obviously a forward looking discussion. These fields are mandatory in 1.0, and will be in 1.1, so they need to be in SPDX files produced under those version. However, for 2.0 i think we could greatly encourage adoption by relaxing some of these constraints from "must have" to "should have". And we would get that benefit with no practical downside at all.
On 06/12/2012 03:06 PM, Peter Williams wrote: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 accomplish your goals is useless. I, however, might find it perfectly acceptable. The strict approach results in us both being deprived of the information.So the questions is: Is it better to have SPDX files which contain aI would question whether this is one 'tiny little piece' or not. In my
large amount of truly useful information but that are incomplete or
should we hide all that information because we are missing one tiny
little piece?
role as a consumer of such incoming license information, I would be
unwilling to accept SPDX data describing a package unless I could
conclusively confirm that the package supplied matched the data in the
SPDX file.
Is it worse to receive a data set that is too incomplete to use for your purpose, or not receive any data at all? It seems to me that to two situations are practically the same, in either case you have no new information. On the other hand, if you can accomplish your goal with the incomplete data set, then receiving it improves your situation substantially. Let's err on the side of helping as many people as possible.
Even if you choose not to accept an incomplete file verbatim, having it might still be advantageous. If nothing else it gives you a place to start your investigation. For example, if i receive an SPDX file w/o a packageVerificationCode, i might decide i need to do my own analysis of the package i am using because i cannot verify that is exactly the one described by the SPDX file. Fortunately, the licensing of software packages rarely change dramatically between versions so i could use the untrusted SPDX data as a starting point. Such a head start would be likely to save a great deal of time and effort. This would be about the same process needed if i received an SPDX file with a packageVerificationCode that did not match my package.
Peter
PS: This is obviously a forward looking discussion. These fields are mandatory in 1.0, and will be in 1.1, so they need to be in SPDX files produced under those version. However, for 2.0 i think we could greatly encourage adoption by relaxing some of these constraints from "must have" to "should have". And we would get that benefit with no practical downside at all.
RUFFIN MICHEL
No ALU has a DB with 5000 entries for open source maintained since 2002 describing IPR issues. Since 2007 we are requesting from all our suppliers the list of FOSS coming with their products with license, URL of origin, etc. Then one of our 200 FOSS evaluators look at this list compares it to what we have in our database to see if we can accept it or not. He/She enters in the DB the missing entries, … (and I can tell you that this is useful because on nearly 2 contracts on 3 with our suppliers, we find issues that need mitigation). The SPDX standard should allow us to automate partly this process. And our customers are now starting to ask us similar information.
These 2 fields are not relevant in this context to my knowledge. So if these fields are mandatory and we implement an export function, we will generate files that would not be compliant to the standard and then it might be worthless. For the import function we can ignore them I guess.
If there is a good reason for keeping these fields mandatory ALU will try to align its DB on it, but it would be a huge work. But if there is no good reason we ask to make them optional.
We are currently in the process of revisiting all our entries in the database to increase consistency and remove confidential information in order to be able to provide the content of our database to some external partner companies such as Blackduck (and there are others). The goal is to increase the quality and completeness of their database (we have 200 FOSS experts feeding our DB for 5000 entries, Blackduck has a DB of around 500 000 entries, Antelink has a DB of 1 000 000 entries, I do not know for Palamida, Protecode and NextB but it should be similar in range…). This should profit to us by providing better identification with Blackduck tool for instance. I have the long term intention to open source our database in order to share the manpower on this activity, to improve quality of information, to encourage FOSS contributors to control the correctness of information, and to raise awareness on FOSS IP issues (to decrease complexity). For instance our lawyers have done the Plan9 public license, the Lucent Public license (Both OSI certified) the Alcatel-Lucent public license. But we have decided now when contributing to open source to use more standard licenses such as MIT, BSD, Apache2 or GNU family to reduce complexity.
Michel
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
De :
wmboyle@... [mailto:wmboyle@...] De
la part de William Boyle
Envoyé : mardi 12 juin 2012
20:13
À : RUFFIN, MICHEL (MICHEL)
Cc : spdx@...
Objet : Re: Import and export
function of SPDX
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 Systems Engineer
Nokia Mobile Phones
On Tue, Jun 12, 2012 at 7:02 AM, RUFFIN, MICHEL (MICHEL) <michel.ruffin@...>
wrote:
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 an import/export function in SPDX standard.
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?
See bellow details
Michel
There are two fields that are mandatory in SPDX but have no equivalent in the
Alcatel-Lucent FOSS database.
These fields are:
4.3 Package File Name
4.3.1 Purpose: Provide the actual file name of the package. This may include the
packaging and compression methods used as part of the file name.
4.3.2 Intent: Here, the actual file name of the compressed file containing the
package is a significant technical element that needs to be included with each
package identification information.
4.3.3 Cardinality: Mandatory, one.
4.7 Package Verification Code
4.7.1 Purpose: This field provides an independently reproducible mechanism
identifying specific contents of a package based on the actual files (except the
SPDX file itself, if it is included in the package) that make up each package
and that correlates to the data in this SPDX file. This identifier enables a
recipient to determine if any file in the original package (that the analysis
was done on) has been changed and permits inclusion of an SPDX file as part of a
package.
4.7.2 Intent: Providing a unique identifier based on the files inside each
package, eliminates confusion over which version or modification of a specific
package the SPDX file refers to. The SPDX file can be embedded within the
package without altering the identifier.
4.7.3 Cardinality: Mandatory, one.
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
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
RUFFIN 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 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
toggle quoted message
Show quoted text
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:
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
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
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?
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
Bill Schineller
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 hopefully capture your needs.
I've attached your document to the following use case http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution
which may be the best fit.
Regarding the desire to produce SPDX documents from legacy data in spite of being able to populate all mandatory fields, there is also a use case
which can be elaborated on.
Best Regards,
Bill Schineller
On Jun 13, 2012, at 8:45 AM, RUFFIN, MICHEL (MICHEL) 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=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
<FOSS_clauses_rational_120227.doc>_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech
Bill Schineller
KnowledgeBase Manager
KnowledgeBase Manager
Black Duck Software, Inc.
8 New England Executive Park
Burlington, MA 01803
T: 781/425-4405
Jilayne Lovejoy <jilayne.lovejoy@...>
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:
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.: 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
optional?
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
Kevin P. Fleming <kpfleming@...>
On 06/13/2012 06:50 AM, RUFFIN, MICHEL (MICHEL) wrote:
As an example of why, let's assume that a company has received a binary distribution of some software from a vendor, and the software is nominally licensed under the GPLv2. The vendor supplies the company with a source archive that purportedly is the original source used to produce that binary code, and also provides an SPDX file that claims to be a valid and accurate representation of the license information present in the files in the source archive. The company wants to use this information to ensure that they are in compliance with the stated license obligations when they further distribute this binary.
However, the SPDX file does not contain the source archive name/version/etc. nor its checksum. All it contains is file names and their checksums. How can the receiving company be sure that the SPDX file correctly represents the source archive they have received? If the source archive contains additional source files not represented in the SPDX file, there is no way for the receiving company to know this other than to audit the source archive contents again, thus partially defeating the purpose of having received an SPDX file in the first place. In my own case, if I did this audit and found that the source archive contained source files that were *not* represented in the SPDX file, then I'd probably just throw away the SPDX file and act as if I had not received it in the first place.
I understand that there are probably many situations where the source archive is not available, or will not be distributed, and in such situations making these fields mandatory in SPDX seems burdensome. However, in any case where the source archive is available and will be distributed, I think these fields are as important as any other top-level metadata in the SPDX file.
Could we construct the SPDX 2.0 XML in such a way that there was an attribute indicating that the source archive is 'unavailable or unknown', and if this attribute it set, then (and only then) these other fields become optional? Doing this would mean that if the producer/distributor of an SPDX file makes the claim that the source archive is unavailable/unknown (and thus does not provide these additional pieces of information), but in fact the source archive is available, the receiver of the SPDX file could then choose whether to audit the source archive or trust the SPDX file.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
We are currently in the process of revisiting all our entries in theI'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 information present in the SPDX file.
database to increase consistency and remove confidential information in
order to be able to provide the content of our database to some external
partner companies such as Blackduck (and there are others). The goal is
to increase the quality and completeness of their database (we have 200
FOSS experts feeding our DB for 5000 entries, Blackduck has a DB of
around 500 000 entries, Antelink has a DB of 1 000 000 entries, I do not
know for Palamida, Protecode and NextB but it should be similar in range…).
As an example of why, let's assume that a company has received a binary distribution of some software from a vendor, and the software is nominally licensed under the GPLv2. The vendor supplies the company with a source archive that purportedly is the original source used to produce that binary code, and also provides an SPDX file that claims to be a valid and accurate representation of the license information present in the files in the source archive. The company wants to use this information to ensure that they are in compliance with the stated license obligations when they further distribute this binary.
However, the SPDX file does not contain the source archive name/version/etc. nor its checksum. All it contains is file names and their checksums. How can the receiving company be sure that the SPDX file correctly represents the source archive they have received? If the source archive contains additional source files not represented in the SPDX file, there is no way for the receiving company to know this other than to audit the source archive contents again, thus partially defeating the purpose of having received an SPDX file in the first place. In my own case, if I did this audit and found that the source archive contained source files that were *not* represented in the SPDX file, then I'd probably just throw away the SPDX file and act as if I had not received it in the first place.
I understand that there are probably many situations where the source archive is not available, or will not be distributed, and in such situations making these fields mandatory in SPDX seems burdensome. However, in any case where the source archive is available and will be distributed, I think these fields are as important as any other top-level metadata in the SPDX file.
Could we construct the SPDX 2.0 XML in such a way that there was an attribute indicating that the source archive is 'unavailable or unknown', and if this attribute it set, then (and only then) these other fields become optional? Doing this would mean that if the producer/distributor of an SPDX file makes the claim that the source archive is unavailable/unknown (and thus does not provide these additional pieces of information), but in fact the source archive is available, the receiver of the SPDX file could then choose whether to audit the source archive or trust the SPDX file.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
Kevin P. Fleming <kpfleming@...>
On 06/12/2012 06:08 PM, Peter Williams wrote:
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
Even if you choose not to accept an incomplete file verbatim, having itAgreed, and this is pretty much what I just posted in another reply before having read yours :-)
might still be advantageous. If nothing else it gives you a place to
start your investigation. For example, if i receive an SPDX file w/o a
packageVerificationCode, i might decide i need to do my own analysis of
the package i am using because i cannot verify that is exactly the one
described by the SPDX file. Fortunately, the licensing of software
packages rarely change dramatically between versions so i could use the
untrusted SPDX data as a starting point. Such a head start would be
likely to save a great deal of time and effort. This would be about the
same process needed if i received an SPDX file with a
packageVerificationCode that did not match my package.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
RUFFIN MICHEL
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)
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.
Michel
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
toggle quoted message
Show quoted text
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.
Michel
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é : 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:
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.: 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
optional?
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
RUFFIN MICHEL
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 solution to identify uniquely an open source.
Even the URL is not enough, when our foss evaluators received a URL to study a FOSS, they have first to check that it is the good one. For instance people are providing the URL on Sourceforge or on a mirror site, while this is not the home page for the software. So our internal recommendation is to use the home page of the copyright owner whenever possible.
Not that the URL and version number are the only mandatory fields in our database
michel
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
toggle quoted message
Show quoted text
Even the URL is not enough, when our foss evaluators received a URL to study a FOSS, they have first to check that it is the good one. For instance people are providing the URL on Sourceforge or on a mirror site, while this is not the home page for the software. So our internal recommendation is to use the home page of the copyright owner whenever possible.
Not that the URL and version number are the only mandatory fields in our database
michel
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 : spdx-bounces@... [mailto:spdx-bounces@...] De la part de Kevin P. Fleming
Envoyé : mercredi 13 juin 2012 16:57
À : spdx@...
Objet : Re: Import and export function of SPDX
On 06/13/2012 06:50 AM, RUFFIN, MICHEL (MICHEL) wrote:
yesterday, I find the package-level metadata to be mandatory in order to
have a high degree of trust in the rest of the information present in
the SPDX file.
As an example of why, let's assume that a company has received a binary
distribution of some software from a vendor, and the software is
nominally licensed under the GPLv2. The vendor supplies the company with
a source archive that purportedly is the original source used to produce
that binary code, and also provides an SPDX file that claims to be a
valid and accurate representation of the license information present in
the files in the source archive. The company wants to use this
information to ensure that they are in compliance with the stated
license obligations when they further distribute this binary.
However, the SPDX file does not contain the source archive
name/version/etc. nor its checksum. All it contains is file names and
their checksums. How can the receiving company be sure that the SPDX
file correctly represents the source archive they have received? If the
source archive contains additional source files not represented in the
SPDX file, there is no way for the receiving company to know this other
than to audit the source archive contents again, thus partially
defeating the purpose of having received an SPDX file in the first
place. In my own case, if I did this audit and found that the source
archive contained source files that were *not* represented in the SPDX
file, then I'd probably just throw away the SPDX file and act as if I
had not received it in the first place.
I understand that there are probably many situations where the source
archive is not available, or will not be distributed, and in such
situations making these fields mandatory in SPDX seems burdensome.
However, in any case where the source archive is available and will be
distributed, I think these fields are as important as any other
top-level metadata in the SPDX file.
Could we construct the SPDX 2.0 XML in such a way that there was an
attribute indicating that the source archive is 'unavailable or
unknown', and if this attribute it set, then (and only then) these other
fields become optional? Doing this would mean that if the
producer/distributor of an SPDX file makes the claim that the source
archive is unavailable/unknown (and thus does not provide these
additional pieces of information), but in fact the source archive is
available, the receiver of the SPDX file could then choose whether to
audit the source archive or trust the SPDX file.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
De : spdx-bounces@... [mailto:spdx-bounces@...] De la part de Kevin P. Fleming
Envoyé : mercredi 13 juin 2012 16:57
À : spdx@...
Objet : Re: Import and export function of SPDX
On 06/13/2012 06:50 AM, RUFFIN, MICHEL (MICHEL) wrote:
We are currently in the process of revisiting all our entries in theI'm curious how you see this working. As I posted on the other SPDX list
database to increase consistency and remove confidential information in
order to be able to provide the content of our database to some external
partner companies such as Blackduck (and there are others). The goal is
to increase the quality and completeness of their database (we have 200
FOSS experts feeding our DB for 5000 entries, Blackduck has a DB of
around 500 000 entries, Antelink has a DB of 1 000 000 entries, I do not
know for Palamida, Protecode and NextB but it should be similar in range.).
yesterday, I find the package-level metadata to be mandatory in order to
have a high degree of trust in the rest of the information present in
the SPDX file.
As an example of why, let's assume that a company has received a binary
distribution of some software from a vendor, and the software is
nominally licensed under the GPLv2. The vendor supplies the company with
a source archive that purportedly is the original source used to produce
that binary code, and also provides an SPDX file that claims to be a
valid and accurate representation of the license information present in
the files in the source archive. The company wants to use this
information to ensure that they are in compliance with the stated
license obligations when they further distribute this binary.
However, the SPDX file does not contain the source archive
name/version/etc. nor its checksum. All it contains is file names and
their checksums. How can the receiving company be sure that the SPDX
file correctly represents the source archive they have received? If the
source archive contains additional source files not represented in the
SPDX file, there is no way for the receiving company to know this other
than to audit the source archive contents again, thus partially
defeating the purpose of having received an SPDX file in the first
place. In my own case, if I did this audit and found that the source
archive contained source files that were *not* represented in the SPDX
file, then I'd probably just throw away the SPDX file and act as if I
had not received it in the first place.
I understand that there are probably many situations where the source
archive is not available, or will not be distributed, and in such
situations making these fields mandatory in SPDX seems burdensome.
However, in any case where the source archive is available and will be
distributed, I think these fields are as important as any other
top-level metadata in the SPDX file.
Could we construct the SPDX 2.0 XML in such a way that there was an
attribute indicating that the source archive is 'unavailable or
unknown', and if this attribute it set, then (and only then) these other
fields become optional? Doing this would mean that if the
producer/distributor of an SPDX file makes the claim that the source
archive is unavailable/unknown (and thus does not provide these
additional pieces of information), but in fact the source archive is
available, the receiver of the SPDX file could then choose whether to
audit the source archive or trust the SPDX file.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Soeren_Rabenstein@...
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 responsibilities, I hardly find time to read mails from this list anymore :()
But I think a better forum for this project would be the FSFE legal network.
Mit freundlichen Grüßen / Kind regards
Sören Rabenstein
____________________________________________________________
ASUS Computer GmbH
Sören Rabenstein, LL.M.
Legal Affairs Center
Harkortstr. 21-23, 40880 Ratingen
Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...
____________________________________________________________
-----Ursprüngliche Nachricht-----
Von: spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
Gesendet: Mittwoch, 13. Juni 2012 14:45
An: Gary O'Neall; 'Peter Williams'
Cc: spdx-tech@...; spdx@...
Betreff: 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
toggle quoted message
Show quoted text
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 responsibilities, I hardly find time to read mails from this list anymore :()
But I think a better forum for this project would be the FSFE legal network.
Mit freundlichen Grüßen / Kind regards
Sören Rabenstein
____________________________________________________________
ASUS Computer GmbH
Sören Rabenstein, LL.M.
Legal Affairs Center
Harkortstr. 21-23, 40880 Ratingen
Tel.: (+49) 2102 5609 317
Fax.: (+49) 2102 5609 309
soeren_rabenstein@...
____________________________________________________________
-----Ursprüngliche Nachricht-----
Von: spdx-bounces@... [mailto:spdx-bounces@...] Im Auftrag von RUFFIN, MICHEL (MICHEL)
Gesendet: Mittwoch, 13. Juni 2012 14:45
An: Gary O'Neall; 'Peter Williams'
Cc: spdx-tech@...; spdx@...
Betreff: 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:
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
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
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?
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
Kevin P. Fleming <kpfleming@...>
On 06/13/2012 10:51 AM, RUFFIN, MICHEL (MICHEL) wrote:
In other words, the problem you've been struggling with has been addressed as part of SPDX, but you aren't in a position to be able to take advantage of it, which is somewhat unfortunate.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
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 solution to identify uniquely an open source.Right, and this is what the package checksum was intended to solve. If you have that, then no matter where you go the source archive, you can confirm (with nearly 100% confidence) that it has the some contents as were used by the person who constructed the SPDX file.
Even the URL is not enough, when our foss evaluators received a URL to study a FOSS, they have first to check that it is the good one. For instance people are providing the URL on Sourceforge or on a mirror site, while this is not the home page for the software. So our internal recommendation is to use the home page of the copyright owner whenever possible.
Not that the URL and version number are the only mandatory fields in our database
In other words, the problem you've been struggling with has been addressed as part of SPDX, but you aren't in a position to be able to take advantage of it, which is somewhat unfortunate.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
Gary O'Neall
Thanks Michel. This does describe the use case. I think this is an
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
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:
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
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
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?
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
Jilayne Lovejoy <jilayne.lovejoy@...>
(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:
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...
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@...
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 areOne thing I noticed immediately about your clauses is the definition of
already happy when suppliers can comply to our requirements without too
much discussion so we did not formalize things too much)
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...
Thanks for sharing this. Really great to hear that you have adopted the
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.
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.: theI think making those fields optional would be advantageous. Would you
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?
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