Armijn Hemel replied: I'm sorry; you're right; I inadvertently added an "E". I was thinking of FTF-legal, which does exist: https://mail.fsfeurope.org/mailman/listinfo/ftf-legal Indeed, I should

You are indeed correct, Bradley. That was a function of sloppy and quick typing on my part and should have really referred to it as the European Legal Network (facilitated by FSFE) to be perfectly

There is no such thing as "FTFE-legal". You might be referring to the European Legal Network. Information about it can be found here: http://fsfe.org/projects/ftf/network.en.html armijn --

Jilayne Lovejoy wrote: Just for clarification: the FSF doesn't have a legal network, to my knowledge. I believe you are likely referring to the highly secretive entity called FTFE-legal, which

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

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

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

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

So far our FOSS clauses are not aligned on the SPDX standard (we are already happy when suppliers can comply to our requirements without too much discussion so we did not formalize things too

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

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

Hi Michel, Thanks again for sharing your information. In regards to your posting (to both this group and the FSF legal network) about the legal clauses, I have noticed this and apologize as well for

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

Gary, I think in my previous mail I expressed our use case: 1) getting information from our suppliers on FOSS included in their products in order to respect license obligations and to provide this to

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

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

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

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

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

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