Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Follow REUSE best practices for licensing/copyright
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Max Mehl via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 17 May 2022 11:14:35 +0200
Hello Daniel(s),
Thanks for the swift replies!
~ Daniel Stenberg [2022-05-16 17:00 +0200]:
> I'm casually positive on improving visibility of the copyright situation in
> curl, nut it needs to be done with minimal friction and burden on existing
> users and developers. Existing consumers have not had a hard time to figure
> out the curl copyright situation in the past.
Absolutely, that's the main goal of REUSE, and as mentioned you did a
good job with keeping a good oversight and communicating it, something
only a fraction of Free Software projects do! All we propose is to
upgrade this to an established best practice and, with SPDX, ISO
standard.
>> My first quick analysis shows that of the ~3500 files in the main repo,
>> almost the half already includes copyright information.
>
> ... and they are all actually in their respective state on purpose. Or at
> least with full knowledge. We have ./scripts/copyright.pl to help us verify
> that all the files that we think *should* have copyright headers, have.
>
> Have you identified any particular files you think should have copyright info
> that haven't? For example, we deliberately ignore all the tests.
Not yet, but actually the logic of REUSE is not to find fuzzy heuristics
to define what's copyrightable and what not because in our experience
this increases maintenance of custom checker scripts (in case they even
exist) and onboarding for new developers. If just all files were
covered, potentially also in bulk as Daniel G. elaborated, combined with
automatic checks, the effort in the long term is usually rather lower
than higher.
>> The REUSE team would be happy to propose a first pull request that showcases
>> some possibilities of how REUSE could be applied, and how the file headers
>> shall look like after all.
>
> Sure, but maybe you can start with a minimal adjustment and show us how you
> suggest we updated the generic copyright header before you go ahead and update
> thousands of files?
Sure, sounds good. I will work on a pull request today that tackles some
of the concerns/questions you brought up. In particular I will present
some options for how to extend/replace the existing copyright headers.
>> In a next step, we'd have to make sure that we interpreted the licensing and
>> copyright situation correctly.
>
> I don't think that should be very difficuly.
Do you already know whether *all* files in the repository are under the
curl license and "Copyright (C) 1998 - 2022, Daniel Stenberg,
<daniel_at_haxx.se>, et al."?
As we would also cover insignificant files such as configuration files,
shall they also be just under the curl license or would you tend towards
making them similar to public domain?
>> I would like to note that while reaching REUSE compliance is a larger
>> one-time chunk, maintaining this status is fairly simple
>
> If we just update ./scripts/copyright.pl accordingly, it's done.
From a first glance it would even be possible to replace it completely,
depending on whether you would like to stick with updating the years
(which is not really necessary/useful as many argue [^1]). But of course
that'd be up to you, I'm just listing options to keep things as simple
as possible :)
Best,
Max
[^1]: https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code#why-not-bump-the-year-on-change
Date: Tue, 17 May 2022 11:14:35 +0200
Hello Daniel(s),
Thanks for the swift replies!
~ Daniel Stenberg [2022-05-16 17:00 +0200]:
> I'm casually positive on improving visibility of the copyright situation in
> curl, nut it needs to be done with minimal friction and burden on existing
> users and developers. Existing consumers have not had a hard time to figure
> out the curl copyright situation in the past.
Absolutely, that's the main goal of REUSE, and as mentioned you did a
good job with keeping a good oversight and communicating it, something
only a fraction of Free Software projects do! All we propose is to
upgrade this to an established best practice and, with SPDX, ISO
standard.
>> My first quick analysis shows that of the ~3500 files in the main repo,
>> almost the half already includes copyright information.
>
> ... and they are all actually in their respective state on purpose. Or at
> least with full knowledge. We have ./scripts/copyright.pl to help us verify
> that all the files that we think *should* have copyright headers, have.
>
> Have you identified any particular files you think should have copyright info
> that haven't? For example, we deliberately ignore all the tests.
Not yet, but actually the logic of REUSE is not to find fuzzy heuristics
to define what's copyrightable and what not because in our experience
this increases maintenance of custom checker scripts (in case they even
exist) and onboarding for new developers. If just all files were
covered, potentially also in bulk as Daniel G. elaborated, combined with
automatic checks, the effort in the long term is usually rather lower
than higher.
>> The REUSE team would be happy to propose a first pull request that showcases
>> some possibilities of how REUSE could be applied, and how the file headers
>> shall look like after all.
>
> Sure, but maybe you can start with a minimal adjustment and show us how you
> suggest we updated the generic copyright header before you go ahead and update
> thousands of files?
Sure, sounds good. I will work on a pull request today that tackles some
of the concerns/questions you brought up. In particular I will present
some options for how to extend/replace the existing copyright headers.
>> In a next step, we'd have to make sure that we interpreted the licensing and
>> copyright situation correctly.
>
> I don't think that should be very difficuly.
Do you already know whether *all* files in the repository are under the
curl license and "Copyright (C) 1998 - 2022, Daniel Stenberg,
<daniel_at_haxx.se>, et al."?
As we would also cover insignificant files such as configuration files,
shall they also be just under the curl license or would you tend towards
making them similar to public domain?
>> I would like to note that while reaching REUSE compliance is a larger
>> one-time chunk, maintaining this status is fairly simple
>
> If we just update ./scripts/copyright.pl accordingly, it's done.
From a first glance it would even be possible to replace it completely,
depending on whether you would like to stick with updating the years
(which is not really necessary/useful as many argue [^1]). But of course
that'd be up to you, I'm just listing options to keep things as simple
as possible :)
Best,
Max
[^1]: https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code#why-not-bump-the-year-on-change
-- Max Mehl - Programme Manager -- Free Software Foundation Europe Contact and information: https://fsfe.org/about/mehl -- _at_mxmehl The FSFE is a charity that empowers users to control technology -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-05-17