Re: Import and export function of SPDX


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.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
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




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


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


Join to automatically receive all group messages.