Hi all,
Since Max is on leave for some weeks, I have the honour to share some success story with you today!
The FSFE's REUSE booster team has been in close communication with the curl team and after some feedback loop, this pull request got merged today: https://github.com/curl/curl/pull/8869
So, now curl is officially REUSE compliant! https://github.com/curl/curl
Special thanks to @MaxMehl for the great job that he did there, and to all the curl team for all the feedback and openness to adapt REUSE best practices to display the copyright and licensing information.
Hope we can keep sharing more of these news in the future :)
Best, Lina
On Mon, Jun 13, 2022 at 04:29:31PM +0200, Lina Ceballos wrote:
Hi all,
Since Max is on leave for some weeks, I have the honour to share some success story with you today!
The FSFE's REUSE booster team has been in close communication with the curl team and after some feedback loop, this pull request got merged today: https://github.com/curl/curl/pull/8869
This is wonderful news! I've been eager to see the results from the REUSE Booster programme, so am thrilled to hear about this.
Best wishes,
Sebastian
Hi all,
I took the thread as a trigger to check what our scanners derive and made the following observations (not intended to be complete, but to simply to trigger thoughts):
1) /curl-master/scripts/copyright.pl should be tagged as "GPL-3.0-or-later WITH Autoconf-exception-2.0" (to be validated) instead of just be "GPL-3.0-or-later" (HIDE)
2) /curl-master/lib/curl_path.c includes an ISC snippet, but this is not marked with an SPDX-License-Identifier (HIDE)
3) /curl-master/lib/sha256.c includes a quote that parts of the code are based on public domain. This is not captured. (HIDE)
4) /curl-master/lib/md4.c includes contains code under Public Domain or simple redistribution terms (“heavily cut down BSD license”). This is not captured. (HIDE)
5) /curl-master/lib/md5.c includes contains code under Public Domain or simple redistribution terms (“heavily cut down BSD license”). This is not captured. (HIDE)
Being picky (while greetings go to Jilayne):
6) /curl-master/lib/krb5.c contains a variant of the BSD-3-Clause. The SPDX-License-Identifier says BSD-3-Clause. In /curl-master/LICENSES/BSD-3-Clause.txt is however the standard/default text not matching the original license text. (OBFUSCATE)
Being extremely picky:
7) The files
/curl-master/tests/data/test222 /curl-master/tests/data/test230 /curl-master/tests/data/test232 /curl-master/tests/data/test314 /curl-master/tests/data/test396 /curl-master/tests/data/test1123
contain references to X11 License and suggest that curl is under such license. I would propose to rework those test cases to not cause any ambiguity.
My biggest concern with REUSE is that it might HIDE or OBFUSCATE information (see items above). Just relying on the SPDX-License-Identifier does not provide the full truth.
Currently we configure our scanner to intentionally excludes lines containing SPDX-License-Identifier tags, because we would like “to see through”.
I don’t want to say, that this is the final situation. But in case projects apply REUSE, I would require them to be as accurate as possible and identify all corner cases; otherwise it just adds further work and ambiguity.
Just my thoughts…
Regards, Karsten
On 22.06.22, 14:22, "REUSE on behalf of Sebastian Crane" <reuse-bounces@lists.fsfe.org on behalf of seabass-labrax@gmx.com> wrote:
On Mon, Jun 13, 2022 at 04:29:31PM +0200, Lina Ceballos wrote: > Hi all, > > Since Max is on leave for some weeks, I have the honour to share some > success story with you today! > > The FSFE's REUSE booster team has been in close communication with the curl > team and after some feedback loop, this pull request got merged today: > https://github.com/curl/curl/pull/8869
This is wonderful news! I've been eager to see the results from the REUSE Booster programme, so am thrilled to hear about this.
Best wishes,
Sebastian _______________________________________________ REUSE mailing list REUSE@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Hi all,
A correction on item 1):
The path I was referring to got mixed. It should have been
curl-master/m4/ax_compile_check_sizeof.m4 (see https://github.com/curl/curl/blob/master/m4/ax_compile_check_sizeof.m4)
I'd still argue (after some background discussions) that this is
GPL-3.0-or-later WITH Autoconf-exception-2.0 (to be verified along the SPDX matching guidelines)
Some more details on item 6):
a) I don’t argue against that the license identification is BSD-3-Clause. That is fine with me within the boundaries of the SPDX matching guidelines. My point is, that there is an “original” license text with variations, and I would like to see that “original” license text reproduced in the license folder, not a rather arbitrary template.
In the beginning curl had one instance of a BSD-3-Clause license (the “original”). After REUSE is applied it shows two instances (template and “original”).
When I only parse the REUSE tags, I miss the "original" license.
b) The license text (binary redistribution clause) says:
“2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.“
We take „this list of conditions and the following disclaimer“ verbatim. This is in alignment with our key objective to not trivialize license terms and conditions.
Therefore, we were concluding that REUSE is obfuscating information.
We propose to indicate the "template" characteristics of the current BSD-3-Clause license in the license folder and add the original license as well. Perhaps this can be done by a naming conventions on the license files.
Regards, Karsten
metaeffekt GmbH Firmensitz: Renettenweg 6/1, 69124 Heidelberg Registergericht: Amtsgericht Mannheim, HRB 725313 Geschäftsführer: Karsten Klein USt.-IdNr.: DE307084554
Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen beinhalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen Sie diese E-Mail und alle Kopien umgehend. Eine unbefugte Weitergabe der E-Mail oder deren Inhalte und Anhänge ist nicht gestattet.
Möchten Sie als Empfänger keine Informationen dieser Art erhalten, setzen Sie sich bitte unmittelbar mit dem Absender der E-Mail in Verbindung. Die metaeffekt GmbH unterstützt Ihre Datenhoheit und informationelle Selbstbestimmung und übermittelt Informationen ausschließlich auf der Rechtsgrundlage der europäischen Datenschutzgrundverordnung (DSGVO). Weitere Informationen zu den Datenverarbeitungsvorgängen und insbesondere Ihrer Rechte entnehmen Sie der Datenschutzerklärung der metaeffekt GmbH http://www.metaeffekt.com/files/metaeffekt-data-privacy_v2018-05-29.pdf.
On 22.06.22, 18:06, "REUSE on behalf of Karsten Klein" <reuse-bounces@lists.fsfe.org on behalf of karsten.klein@metaeffekt.com> wrote:
Hi all,
I took the thread as a trigger to check what our scanners derive and made the following observations (not intended to be complete, but to simply to trigger thoughts):
1) /curl-master/scripts/copyright.pl should be tagged as "GPL-3.0-or-later WITH Autoconf-exception-2.0" (to be validated) instead of just be "GPL-3.0-or-later" (HIDE)
2) /curl-master/lib/curl_path.c includes an ISC snippet, but this is not marked with an SPDX-License-Identifier (HIDE)
3) /curl-master/lib/sha256.c includes a quote that parts of the code are based on public domain. This is not captured. (HIDE)
4) /curl-master/lib/md4.c includes contains code under Public Domain or simple redistribution terms (“heavily cut down BSD license”). This is not captured. (HIDE)
5) /curl-master/lib/md5.c includes contains code under Public Domain or simple redistribution terms (“heavily cut down BSD license”). This is not captured. (HIDE)
Being picky (while greetings go to Jilayne):
6) /curl-master/lib/krb5.c contains a variant of the BSD-3-Clause. The SPDX-License-Identifier says BSD-3-Clause. In /curl-master/LICENSES/BSD-3-Clause.txt is however the standard/default text not matching the original license text. (OBFUSCATE)
Being extremely picky:
7) The files
/curl-master/tests/data/test222 /curl-master/tests/data/test230 /curl-master/tests/data/test232 /curl-master/tests/data/test314 /curl-master/tests/data/test396 /curl-master/tests/data/test1123
contain references to X11 License and suggest that curl is under such license. I would propose to rework those test cases to not cause any ambiguity.
My biggest concern with REUSE is that it might HIDE or OBFUSCATE information (see items above). Just relying on the SPDX-License-Identifier does not provide the full truth.
Currently we configure our scanner to intentionally excludes lines containing SPDX-License-Identifier tags, because we would like “to see through”.
I don’t want to say, that this is the final situation. But in case projects apply REUSE, I would require them to be as accurate as possible and identify all corner cases; otherwise it just adds further work and ambiguity.
Just my thoughts…
Regards, Karsten
On 22.06.22, 14:22, "REUSE on behalf of Sebastian Crane" <reuse-bounces@lists.fsfe.org on behalf of seabass-labrax@gmx.com> wrote:
On Mon, Jun 13, 2022 at 04:29:31PM +0200, Lina Ceballos wrote: > Hi all, > > Since Max is on leave for some weeks, I have the honour to share some > success story with you today! > > The FSFE's REUSE booster team has been in close communication with the curl > team and after some feedback loop, this pull request got merged today: > https://github.com/curl/curl/pull/8869
This is wonderful news! I've been eager to see the results from the REUSE Booster programme, so am thrilled to hear about this.
Best wishes,
Sebastian _______________________________________________ REUSE mailing list REUSE@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
_______________________________________________ REUSE mailing list REUSE@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Hi Karsten,
~ Karsten Klein [2022-06-22 18:06 +0200]:
I took the thread as a trigger to check what our scanners derive and made the following observations (not intended to be complete, but to simply to trigger thoughts):
Thanks for taking this as a chance to make a thorough check of the project. It highlights how a variety of tools and multiple pairs of eyes are needed to capture the complexity of a project like curl.
I took the liberty to create an issue upstream as this is best to be discussed there. I also added some comments behind the points on how these can be addressed with REUSE:
https://github.com/curl/curl/issues/9220
My biggest concern with REUSE is that it might HIDE or OBFUSCATE information (see items above). Just relying on the SPDX-License-Identifier does not provide the full truth.
Of course. REUSE, as most best practices, is not meant to be the single point of truth or the silver bullet to all problems in its sphere. It's an intentionally simple practice to mark files and get an overview for humans and machines of licensing and copyright – for the project's developers, re-users, compliance folks etc.
Currently we configure our scanner to intentionally excludes lines containing SPDX-License-Identifier tags, because we would like “to see through”.
I don’t want to say, that this is the final situation. But in case projects apply REUSE, I would require them to be as accurate as possible and identify all corner cases; otherwise it just adds further work and ambiguity.
I, foreseeably, would see it the other way round. Especially for projects that adopt REUSE from the start, it usually is a great resource and helps its developers to keep track of special cases like included snippets under different copyright and license, third-party libraries, dual-licensing and so on. Retroactively identifying and fixing these is much harder (see Linux) and – as we see it here – also prone to mistakes.
But it's still worth it! Many more people have a much better understanding of curl's licensing now, including the maintainer. During the process, we fixed some incompatible licensing and clarified a lot of questions. Moreover, it now is a constant reminder for contributors and maintainers to keep a closer look on potential licensing issues.
Best, Max