Re: Import and export function of SPDX
|
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 De :
wmboyle@... [mailto:wmboyle@...] De
la part de 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? :-(
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 Tel +33 (0) 6 75 25 21 94
|
|
|