curl / Mailing Lists / curl-library / Single Mail
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.

Follow REUSE best practices for licensing/copyright

From: Max Mehl via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 16 May 2022 16:18:27 +0200

Hello all,

I would like to propose for curl to follow the REUSE best practices that
make licensing and copyright information unambiguous and perfectly
human- and machine-readable [^0]. It is a well-established standard and
intends to be as simple to adopt and maintain as possible, supported
with easy tooling. Additionally my colleagues from the Free Software
Foundation Europe (FSFE) would be happy to help in this process and
assist with potential legal questions in case of uncertainties (e.g.
license compatibilities).

The REUSE best practices basically involve three steps:

1. All used licenses are stored in one directory.
2. All files in the repo carry licensing and copyright information,
   ideally as a comment header, and there are alternatives for binary
   files or directories with a lot of test data. This step can be
   automated but would require manual review so we don't misinterpret.
3. Check the repo with the helper tool to identify missing pieces [^1].

This has two major advantages:

* Users and maintainers have a clear overview of the copyright and
  licensing situation. Are there proprietary components? Code developed
  by third parties? Or even under different licenses that may be
  incompatible?

* Re-users such as distributions (and their packagers, e.g. Debian) but
  also industry actors have a much easier time in understanding the
  project's licensing and copyright as well, and give proper respect to
  the copyright holders and licensing terms.

My first quick analysis shows that of the ~3500 files in the main repo,
almost the half already includes copyright information. Probably the
same amount has the license notice but unfortunately that's not
machine-readable in the sense of an unambiguous SPDX license identifier.
The other big chunk seems to mostly test data, documentation, and some
configuration files. That's a quite good baseline already!

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. In a next step, we'd have to
make sure that we interpreted the licensing and copyright situation
correctly.


I would like to note that while reaching REUSE compliance is a larger
one-time chunk, maintaining this status is fairly simple: inclusion in
CI pipelines, pre-commit hooks, badges, you-name-it, everything possible
[^2].

Please also note that REUSE is an established practice with a lot of
organisations using it, among them the KDE community, Linux kernel,
companies such as Siemens, SAP and LGE, as well as numerous smaller and
larger projects. We would be happy to have curl among them as one of the
most relevant tools in the FOSS world.

Please let me know what you think and whether we shall kick this off
with a pull request.

Best,
Max


[^0]: https://reuse.software

[^1]: https://github.com/fsfe/reuse-tool

[^2]: https://reuse.software/dev/


-- 
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.html
  • application/pgp-signature attachment: stored
Received on 2022-05-16