search

Open-Source-Compliance / package-analysis

This repo contains license and copyright analysis results of open source packages. It further contains other license compliance relevant artifacts, which might be of value for others
https://www.osselot.org/
Other
37 stars 21 forks source link

Add package-url to disclosures #12

Closed armijnhemel closed 1 year ago

armijnhemel commented 1 year ago

It might be good to add package-urls to the disclosures, as package-url is becoming well supported in many tools.

@pombredanne

pombredanne commented 1 year ago

yes, this would be very nice indeed enabling interop an reuse. For instance

OliverFendt commented 1 year ago

Hi @pombredanne hi @armijnhemel good idea, just for clarification do you mean to add the purls to the Readme files or the OSS-disclosure files or the SPDX2TV files? It might be that for some I cannot provide the purl, because I received them by email, I would need to download them and do a reassessment, but these are only 6 or 7 packages.

armijnhemel commented 1 year ago

Hi @pombredanne hi @armijnhemel good idea, just for clarification do you mean to add the purls to the Readme files or the OSS-disclosure files or the SPDX2TV files? It might be that for some I cannot provide the purl, because I received them by email, I would need to download them and do a reassessment, but these are only 6 or 7 packages.

Why not both?

OliverFendt commented 1 year ago

Ah ok, then I think the best approach would be to put in all

armijnhemel commented 1 year ago

Ah ok, then I think the best approach would be to put in all

That actually was a reference to a meme, but both would indeed be a good place. At a minimum I would suggest the SPDX2TV files so tools processing the data automatically can use this information as well. @pombredanne would you concur?

OliverFendt commented 1 year ago

I think it would be enough to put the purl in:

The disclosure douments are not suited in my opinion, since they shall only contain the licenses, acknowlegdments and copyrights for automatic consumption.

What do you think?

pombredanne commented 1 year ago

@OliverFendt Thanks for the quick reply. You wrote:

The disclosure documents are not suited in my opinion, since they shall only contain the licenses, acknowlegdments and copyrights for automatic consumption.

I tend to think that acknowledgments are incomplete and inaccurate if the included software origin/provenance is not identifiable; i.e., if a "disclosure" document does not identify the software with a download URL and/or a purl, I could consider that reusable as this would not give accurate credits. Crediting implies identifying what you credit unambiguously IMHO.

pombredanne commented 1 year ago

I tend to think that acknowledgments are incomplete and inaccurate if the included software origin/provenance is not identifiable; i.e., if a "disclosure" document does not identify the software with a download URL and/or a purl, I could consider that reusable as this would not give accurate credits. Crediting implies identifying what you credit unambiguously IMHO.

To reformulate this, giving credits without an unambiguous subject for these credits is not crediting at all. If I do not know to what a license applies exactly, I can neither comply with the license terms, nor exercise any rights granted to me by this license.

OliverFendt commented 1 year ago

@pombredanne thank you for your comment.

I tend to think that acknowledgments are incomplete and inaccurate if the included software origin/provenance is not identifiable; i.e., if a "disclosure" document does not identify the software with a download URL and/or a purl, I could consider that reusable as this would not give accurate credits. Crediting implies identifying what you credit unambiguously IMHO.

I disagree. If you want to deliver software which includes FOSS you need to disclose which FOSS you integrated and you need to comply to the licenses of the integrated files. If a license requires that the download location has to be disclosed then of course you need to do that in order to be license compliant. But if there is not such requirement formulated in the applicable licenses you are not obliged to disclose the location from where you took the FOSS packages. For example I integrate openSSL version 1.1.1l in my software and I want to deliver my software to a 3rd party, then I need to fulfill all obigations of all applicable licenses of the files from openSSL I included in my software. So I need to declare that I included OpenSSL version 1.1.1l, furthermore I need to print several acknowledgments, provide the license texts, the copyright notices and fulfill other obigations stated in the licenses. One required acknowledgment (among others) is for example:

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)"

But there is no requirement formulated in the licenses (neither in the OpenSSL License nor in the Original SSLeay License) that I need to disclose from where I took OpenSSL. From this point of view it does not matter whether I downloaded it from https://github.com/openssl/openssl or from https://www.openssl.org/source/old/1.1.1/ or whether I incorporated via another source IMHO. Finally I need to say that I am not a lawyer and my opinion, which I expressed above, is no legal advice

armijnhemel commented 1 year ago

But there is no requirement formulated in the licenses (neither in the OpenSSL License nor in the Original SSLeay License) that I need to disclose from where I took OpenSSL. From this point of view it does not matter whether I downloaded it from https://github.com/openssl/openssl or from https://www.openssl.org/source/old/1.1.1/ or whether I incorporated via another source IMHO. Finally I need to say that I am not a lawyer and my opinion, which I expressed above, is no legal advice

I hope that we can all agree that it would be convenient to have that information in case someone wants to do further research. If the information is readily available (so without having to do extra work), then I think it would be good to include it.

OliverFendt commented 1 year ago

@armijnhemel you wrote

I hope that we can all agree that it would be convenient to have that information in case someone wants to do further research. If the information is readily available (so without having to do extra work), then I think it would be good to include it.

Sure I agree, that it will be convenient to have this information at hand. We will include the package URL, and thanks to @hex3262 there is already a PR, perhaps you @armijnhemel want to look at it https://github.com/Open-Source-Compliance/package-analysis/pull/15

OliverFendt commented 1 year ago

For now we provide the purls in the README files, right below of the download location. In case this is not sufficient please file a new issue or re-open this one. I am closing this one now