How to best handle modification notices and notices of origin in SPDX


Matija Šuklje
 

On petek, 06. september 2019 05:35:48 CEST, J Lovejoy wrote:

I really wouldn’t conflate attribution and copyright notices - that seems to lead to a lot of unnecessarily confusion and other energy
FWIW - this reminded me that there are some licenses that require a specific acknowledgment (I’m intentionally not using “attribution” :) in the form of specific text you need to reproduce, such as Apache-1.1, clause 3 - https://www.gnu.org/licenses/identify-licenses-clearly.en.html
Depends on the license (e.g. CC licenses) and jurisdiction (moral rights), I’d say. So if someone really wanted to start a stink, they might use.

But you’re right, this is wider than just attribution, but that seemed the easiest use case/term for it.

When we began to do the review and conversion for the XML format, we began to label licenses that have this. We didn’t necessarily catch all of them or implement a XML tag for this, but the idea was that it would be possible (if someone wanted to do the work, there was enough work at that point that we didn’t proceed down this path at the time). Just thought I’d mention!
That helps with the license( template)s on the SPDX license list, but not all of these are included in the license text (again, see CC licenses, or UFL-1.1).

Regarding going through the XML sources and putting in the tags, I volunteer, so feel free to assign a ticket to me, but don’t have any free cycles until OSSEurope.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


J Lovejoy
 

better late, than never...

On Aug 22, 2019, at 8:34 AM, Matija ?uklje <matija@...> wrote:

On Sunday 28 July 2019 22:16:34 CEST
garysourceauditor@... wrote:
[G.O.] First a disclaimer - I have not implemented this specific
use case in an SPDX document, but here is one approach: For the
origin package, create a package definition (you can use
FilesAnalyzed=False to keep the required fields to a minimum).
Create a relationship between the modified file and the origin
with a relationship type FileModified and a comment indicating
what was changed.

I can see how this could work in the sense where we are using
packages. But it also seems like quite a tooling-heavy approach.

If I understand you correctly, this would imply you have an
inventory of all the packages used with corresponding SPDX files,
and then this inventory (or build system) could be used to track
the relationships and modification status.

BTW, if we’re talking about small single-file situations (e.g.
CSS, JS, fonts, images), it seems quite a hassle. Imagine doing
this for every single placeholder image.

In any case, there is still the attribution/provenance question
open.

The hack I currently have in mind is to misuse the SPDX-
FileCopyrightText tag in REUSE, but would very much like to depend
on something better.
https://github.com/fsfe/reuse-docs/issues/43


I really wouldn’t conflate attribution and copyright notices - that seems to lead to a lot of unnecessarily confusion and other energy

FWIW - this reminded me that there are some licenses that require a specific acknowledgment (I’m intentionally not using “attribution” :) in the form of specific text you need to reproduce, such as Apache-1.1, clause 3 - https://www.gnu.org/licenses/identify-licenses-clearly.en.html  

When we began to do the review and conversion for the XML format, we began to label licenses that have this. We didn’t necessarily catch all of them or implement a XML tag for this, but the idea was that it would be possible (if someone wanted to do the work, there was enough work at that point that we didn’t proceed down this path at the time).  Just thought I’d mention!

Jilayne




Matija Šuklje
 

On Sunday 28 July 2019 22:16:34 CEST
garysourceauditor@... wrote:
[G.O.] First a disclaimer - I have not implemented this specific
use case in an SPDX document, but here is one approach: For the
origin package, create a package definition (you can use
FilesAnalyzed=False to keep the required fields to a minimum).
Create a relationship between the modified file and the origin
with a relationship type FileModified and a comment indicating
what was changed.
I can see how this could work in the sense where we are using
packages. But it also seems like quite a tooling-heavy approach.

If I understand you correctly, this would imply you have an
inventory of all the packages used with corresponding SPDX files,
and then this inventory (or build system) could be used to track
the relationships and modification status.

BTW, if we’re talking about small single-file situations (e.g.
CSS, JS, fonts, images), it seems quite a hassle. Imagine doing
this for every single placeholder image.

In any case, there is still the attribution/provenance question
open.

The hack I currently have in mind is to misuse the SPDX-
FileCopyrightText tag in REUSE, but would very much like to depend
on something better.
https://github.com/fsfe/reuse-docs/issues/43


cheers,
Matija Šuklje
--
gsm: +386 41 849 552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Gary O'Neall
 

Hi Matija,

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
Matija ?uklje
Sent: Wednesday, July 24, 2019 11:14 AM
To: SPDX-legal <spdx-legal@...>
Subject: How to best handle modification notices and notices of origin in SPDX

Hi all,

recently I’ve been thinking about how to store¹ additional notices that are
required by some licenses on the SPDX license list. Specifically reference to the
origin of the work, and notice of modification of original work.

I’m sure people on this list are very well aware of the notice of modification as
e.g. in §5.a of GPL-3.0:

“The work must carry prominent notices stating that you modified it, and giving
a relevant date.”

As an example of where the requirement (of attribution) is to provide a notice of
where the original work came from, I can offer CC-BY-4.0 and its
§3.a.1.A.v:

“a URI or hyperlink to the Licensed Material to the extent reasonably
practicable;”

…which BTW also includes a notice of modification requirement in §3.a.1.B:

“indicate if You modified the Licensed Material and retain an indication of any
previous modifications;”

This “BY” clause is inherent to all CC-* licenses (apart from CC0-1.0 and CC-
PDDC), and similar clauses exist already in its 1.0 version, so I think it is safe to
assume that all CC licenses have this requirement.

So, I was wondering if there was a way to express this information in SPDX
(other than the generic comment).

I thought of some ugly workarounds, but would first like to hear if there is
already a proper way, before I soil this mailing list with that.
[G.O.] First a disclaimer - I have not implemented this specific use case in an SPDX document, but here is one approach:
For the origin package, create a package definition (you can use FilesAnalyzed=False to keep the required fields to a minimum). Create a relationship between the modified file and the origin with a relationship type FileModified and a comment indicating what was changed.
Gary


Matija Šuklje
 

Hi all,

recently I’ve been thinking about how to store¹ additional notices that are required by some licenses on the SPDX license list. Specifically reference to the origin of the work, and notice of modification of original work.

I’m sure people on this list are very well aware of the notice of modification as e.g. in §5.a of GPL-3.0:

“The work must carry prominent notices stating that you modified it, and giving a relevant date.”

As an example of where the requirement (of attribution) is to provide a notice of where the original work came from, I can offer CC-BY-4.0 and its §3.a.1.A.v:

“a URI or hyperlink to the Licensed Material to the extent reasonably practicable;”

…which BTW also includes a notice of modification requirement in §3.a.1.B:

“indicate if You modified the Licensed Material and retain an indication of any previous modifications;”

This “BY” clause is inherent to all CC-* licenses (apart from CC0-1.0 and CC-PDDC), and similar clauses exist already in its 1.0 version, so I think it is safe to assume that all CC licenses have this requirement.

So, I was wondering if there was a way to express this information in SPDX (other than the generic comment).

I thought of some ugly workarounds, but would first like to hear if there is already a proper way, before I soil this mailing list with that.



cheers,
Matija

1 Or, better yet, express.
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...