-
Notifications
You must be signed in to change notification settings - Fork 20
A way to log origin for attribution #43
Comments
Good idea for future versions of REUSE. However, as with Copyright Text, coordination with SPDX and other projects is key. The quoted excerpt of CC-BY-4.0 is very interesting. Section 3 (B) is not easy to fulfill just with REUSE, but I am also not certain whether this is our scope. |
§3.B could be fulfillable with REUSE, if we chose to adopt it, but if we do so, I would suggest to simply allow for optional comments both in the header (which we implicitly already do), as well as in the Note that this notification of modification issue exists also for the GPL family of licenses, so at least allowing for this in a free-form way could be useful. This could be as simple as stating in the FAQ, that if a license requires such notices, you may simply use comments in the header (or |
I just checked the current (3.0a1) spec and it seems to me we could already abuse the From what I understand the following might not be what REUSE suggests (or intended), but still perfectly valid by REUSE 3.0 spec: SPDX-FileCopyrightText: © 2014 Matija Šuklje <[email protected]> as found on <https://matija.suklje.name/ceci-nest-pas-une-pipe>
SPDX-License-Identifier: CC-BY-4.0 …should satisfy https://wiki.creativecommons.org/wiki/best_practices_for_attribution and SPDX-FileCopyrightText: Photo by Jeremy Bishop <https://unsplash.com/photos/KFIjzXYg1RM> on Unsplash <https://unsplash.com/>
SPDX-License-Identifier: LicenseRef-Unsplash …is pretty much a direct implementation of the suggestion on https://unsplash.com/license This way might get a bit messy once we get into modifications and how to squeeze those into the copyright/attribution field. |
Thanks for the overview. I would also be rather in favour of putting such things in an extra line. While using the Copyright/FileCopyrightText header would be valid REUSE, it's rather off our recommendation Perhaps this discussion is worth to be started within the SPDX legal team first, or even wider forums? |
On sreda, 24. julij 2019 17:14:31 CEST, Max Mehl wrote:
Thanks for the overview. I would also be rather in favour of
putting such things in an extra line. While using the
Copyright/FileCopyrightText header would be valid REUSE, it's
rather off our recommendation <year> <name> <email> which I find
very good for oversight and consistency.
I very much agree. But it would still be valid to according to the spec ;)
Perhaps this discussion is worth to be started within the SPDX
legal team first, or even wider forums?
Sure, happy to open a thread on SPDX Legal mailing list.
…--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: [email protected]
sip: [email protected]
|
I believe this can be solved more elegantly. I believe what SPDX wants to do for their next version of the spec, is to allow the user to pick any section from the SPDX spec, and tag-ify it. Ergo, "File Copyright Text" becomes "SPDX-FileCopyrightText". Thus, we could pick any section from the spec and use it to convey the origin information. For instance:
Unfortunately, there is nothing at the "File" level for this. Perhaps this is something that SPDX could be prompted about. |
I am asking SPDX about this already. I agree, this would be best solved first in SPDX itself, and then used or allowed in REUSE. |
I opened a the thread on SPDX-Legal on this topic but so far no useful solution popped up. For the time being, I will use the following work-around internally, but am very much looking forward to a standardised solution later on: SPDX-FileCopyrightText: © 2017 Peter Janzen <https://cc0.photo/author/peter/>
SPDX-License-Identifier: CC0-1.0
Origin: <https://cc0.photo/2017/06/04/huge-headframe-zeche-zollverein-essen/> This relies on the fact that neither the spec nor the |
It seems the SPDX-Legal discussion led to no conclusion, although I'd like to see such a tag as well. I'm not sure whether an issue here is useful, as REUSE's focus is on copyright and licensing. I'll close therefore, but please feel free to reopen if you think otherwise. |
I gave it a bit more thought and we could use PackageURL for this. I checked the SPDX spec and there is something we could use, but it’s a bit ugly: https://spdx.github.io/spdx-spec/v2.3/external-repository-identifiers/ So, the appropriate SPDX tag would therefore be e.g.:
If we can find a better solution, I’m all ears. Reopening. |
Some (mostly content) licenses either directly ask for or encourage, for the origin of the licensed material.
To quote from CC-BY-4.0, which is then repeat throughout all of CC licenses (emphasis mine):
As an example of a license that does not require, but encourages the notice of such an notice of origin, I refer to the Unsplash license
For a future version of REUSE spec, we might want to look into whether we can reasonably add an optional (SPDX?) tag to mark origin, where this is required. This would be most practical for binary content such as images, fonts etc.
The text was updated successfully, but these errors were encountered: