Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query: How can I tag the DCO file and satisfy reuse lint? #261

Closed
lofidevops opened this issue Oct 5, 2020 · 6 comments
Closed

Query: How can I tag the DCO file and satisfy reuse lint? #261

lofidevops opened this issue Oct 5, 2020 · 6 comments

Comments

@lofidevops
Copy link

lofidevops commented Oct 5, 2020

I include a verbatim copy of the Developer Certificate of Origin in my Git repo as a convenient reference to potential contributors. It states:

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

I cannot find an appropriate license code for this file at https://spdx.org/licenses/

I assume that, like license files themselves, I should be able to include the DCO text file in my codebase and satisfy reuse lint. How can I do that?

Suggested solutions

Assuming I haven't simply missed an existing way to do this:

  1. Allow DCO.txt to be added to the LICENSES folder, even though it is not a SPDX license and may not be referenced anywhere else.

  2. Convince SPDX to add the DCO to their license list, so that a project can be licensed as (for example) LGPL-2.1-only AND DCO. Or maybe WITH?

  3. Commit DCO.txt and then exclude it with .gitignore (seems hacky)

  4. Declare it as a custom license https://reuse.software/faq/#custom-license

@mxmehl
Copy link
Member

mxmehl commented Oct 5, 2020

You can make REUSE understand a custom license, see this FAQ entry.

However, I doubt that a DCO qualifies as a license, it's rather an agreement between contributor and distributor. Therefore, I am not sure whether you want REUSE to treat the DCO different than just a text file, and make the README or a CONTRIBUTE.md explain under which conditions you accept third-party code.

@lofidevops
Copy link
Author

@mxmehl What would I put in DCO.txt.license?

@mxmehl
Copy link
Member

mxmehl commented Oct 6, 2020

The copyright field would be rather straightforward: 2004, 2006 The Linux Foundation and its contributors.

Regarding the license of this files, that's interesting. There is the phrase "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." which we know from various GPL licenses for example, but because REUSE does not handle licenses of licenses (as it "ignores" LICENSES/), I am not sure we have a clear recommendation on that.

One way would be to add a custom license (see the aforementioned FAQ entry), and add this text as its only content. However, I'll clarify this internally and come back to you if you can wait a bit.

@lofidevops
Copy link
Author

However, I'll clarify this internally and come back to you if you can wait a bit.

Thanks! No rush. Just want to make sure I'm using the tool as intended (and therefore demonstrating it to others correctly 😊).

@silverhook
Copy link
Contributor

Note that the DCO is handling inbound licensing, while the REUSE spec is about storing the outbound licensing situation. This is similarly the reason why DCO does not have an SPDX ID – it is essentially a CLA, not an outbound license.

Here is what I would do:

  1. store the DCO text in a file, such as DCO-1.1.txt;

  2. create a LICENSES/LicenseRef-DCO-1.1-License.txt with the following text:

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
  1. and then use the following header either in DCO-1.1.txt itself, or (preferably) in a DCO-1.1.txt.license file or similar (upcoming) method:
SPDX-FileCopyrightText: Copyright (C) 2004, 2006 The Linux Foundation and its contributors
SPDX-License-Identifier: LicenseRef-DCO-1.1-License

@mxmehl
Copy link
Member

mxmehl commented Oct 6, 2020

Here is what I would do:

For the record, this would also be my recommendation following an internal discussion today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants