Make repository REUSE.software compliant

[silverhook]

fixes https://github.com/electricjs/electric/issues/156

[silverhook]

What I did:

reuse lint to see what is missing. (Find the official reuse tool here)

reuse init and entered the following:

• project license: BSD-3-Clause
• project name: ElectricJS
• project homepage: https://github.com/electricjs/electric (because https://electricjs.com is dead)
• name of maintainer: Liferay Inc.
• maintainer e-mail: https://liferay.com (because it’s a contact regardless)

Which generated the following .reuse/dep5:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: ElectricJS
Upstream-Contact: Liferay Inc. <https://liferay.com>
Source: https://github.com/electricjs/electric

# Sample paragraph, commented out:
#
# Files: src/*
# Copyright: $YEAR $NAME <$CONTACT>
# License: ...

Caveat: I am using Fish Shell, so some of the more complex syntax is not 100% translatable to other, fully-POSIX-compliant shells

Until it gets implemented in reuse tool itself (see issue #297: Automatically determine copyright dates), this is what I need to do to fix the dates of old files:

for file in **
    reuse addheader --copyright-style spdx-symbol --year (git log --follow --format=%as $file | tail -n1 | cut -c-4) --copyright "Liferay International Ltd. <https://liferay.com>" --license BSD-3-Clause $file
end
for file in **/.*
    reuse addheader --copyright-style spdx-symbol --year (git log --follow --format=%as $file | tail -n1 | cut -c-4) --copyright "Liferay International Ltd. <https://liferay.com>" --license BSD-3-Clause $file
end
for file in .*
    reuse addheader --copyright-style spdx-symbol --year (git log --follow --format=%as $file | tail -n1 | cut -c-4) --copyright "Liferay International Ltd. <https://liferay.com>" --license BSD-3-Clause $file
end

The complication is that it has to call another command to find what was the date each file was committed to the repo for the first time. In the future this will be replaced with a simple flag in the reuse tool itself. For example for packages/electric/lib/download.js, it adds this comment to the top of the file:

// SPDX-FileCopyrightText: © 2017 Liferay International Ltd. <https://liferay.com>
//
// SPDX-License-Identifier: BSD-3-Clause

After this we managed to get 156 / 233 files equipped with appropriate license headers, what remained were:

• *.soy
• *.tpl
• *.js.snap
• yarn.lock
• and some dotfiles like .eslintrc, .yarnrc, .npmignore, .eslintignore

For *.soy this works (and a issue was opened upstream to have it automatically fixed in the future):

for file in **/*.soy
    reuse addheader --style c --copyright-style spdx-symbol --year (git log --follow --format=%as $file | tail -n1 | cut -c-4) --copyright "Liferay International Ltd. <https://liferay.com>" --license BSD-3-Clause $file
end

For what is left we need to generate an explicit license headers by using the --explicit-license flag, like so:

reuse addheader --explicit-license --copyright-style spdx-symbol --year (git log --follow --format=%as $file | tail -n1 | cut -c-4) --copyright "Liferay International Ltd. <https://liferay.com>" --license BSD-3-Clause $file

And that is it.

Once the reuse issues above get resolved, a lot of this manual work will not be needed anymore, and we will be able to call something as simple as:

reuse addheader  --copyright-style spdx-symbol --first-commit-date --copyright "Liferay International Ltd. <https://liferay.com>" --license BSD-3-Clause $file

As an added bonus I registered the repo with the REUSE API to obtain the pretty badge and online linter.

[jbalsas]

Hey @silverhook, thanks for all your work on this!

I don't see anything inherently bad in this PR other than it's not obvious at all how the reuse tool is used. Ideally, we'd want it to be integrated in our workflow so our CI would use it and make sure the repo is always green and does not require of manual intervention (or at the very least more than necessary).

This looks as a good first step and battle test.

For next steps, I'd recommend to head over to https://github.com/liferay/liferay-frontend-projects and try over there. You can partner with @bryceosterhaus, @izaera and @nhpatt to get that repo up to standards as it contains most of our frontend infrastructure code outside of the main liferay-portal repo.

One of the things you'll notice there is that we use the eslint plugin notice to automatically add copyright headers to all files as part of our format script which is checked on CI. This means:

• Copyright health of that repo should be hopefully better than this one
• Any replacement approach should integrate with the existing process, so it could be a good way to test the integration path

Finally, I'm not sure what to make of this PR, since we're not really maintaining this repo anymore... we could just merge it and move on to archive the repo so it's obvious we're no longer updating this... @nhpatt, @bryceosterhaus, does that sound good to you?

[bryceosterhaus]

I had no idea this repo still even existed...

we could just merge it and move on to archive the repo so it's obvious we're no longer updating this

This sounds good to me. I don't know who has access to this repo though, I don't have any permissions for it currently.

[jbalsas]

This sounds good to me. I don't know who has access to this repo though, I don't have any permissions for it currently.

Okay, I'll do the following:

1. Merge this 🤷
2. Transfer the repo to Liferay IT
3. Ask IT to archive the repo
4. Delete the organization (if I can)

I think most of the contributors/admins in this org would approve of this. If they don't, hopefully they're watching and can stop me before I proceed with the plan next week!

[silverhook]

I don't see anything inherently bad in this PR other than it's not obvious at all how the reuse tool is used. Ideally, we'd want it to be integrated in our workflow so our CI would use it and make sure the repo is always green and does not require of manual intervention (or at the very least more than necessary).

reuse was called locally with the commands I wrote in the above lengthy comment. Nothing more fancy than that. It’s a simple Python tool that does a few things only, but does them pretty well.