Re: Correct handling of snippets

Gary O'Neall

We spent quite a bit of time discussing snippets in the SPDX technical working group. There are definitely a number of issues and considerations.

At the conclusion of the discussions, there was a consensus that denoting snippets in an SPDX document was required for several use cases and was a common scenario in JavaScript / Node environments.

You could use the SPDX term "LicenseInfoInSnippet" since you are including the license information directly in the copied snippet. I've always treated this similar to the declared license for packages.

In terms of marking the start and end of the snippet, I don't know of any existing SPDX tags that would help. Within the SPDX document, we use a byte range. This would be rather impractical within the file containing the snippets. The proposal in the referenced thread of using a tag at the start and end of the snippet range looks like it would work.


-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
James Bottomley
Sent: Friday, June 5, 2020 9:08 AM
To: Max Mehl <max.mehl@...>; spdx-legal@...
Subject: Re: Correct handling of snippets

On Fri, 2020-06-05 at 16:15 +0200, Max Mehl wrote:
Hi all,

At REUSE, we currently discuss how to correctly handling snippets from
a third party, potentially under a different license [^1]. Since we
strive to make as much use of SPDX as possible, I wonder about how you
would solve this.

I saw that SPDX uses the following tags instead of FileCopyrightText
and License-Identifier:

* SPDX-SnippetCopyrightText: Foo Bar
* SPDX-SnippetLicenseConcluded: CC-BY-SA-4.0

This raised a bunch of questions:

* How would one mark the begin and end of a snippet?
* "LicenseConcluded" is quite different from the well-known
License-Identifier [^2], so not very intuitive for developers. Is
there some kind of alias that people can use?
* Is was asked how one could refer the source of the snippet.
I really think this is a recipe for disaster. What's wrong with simply keeping the
licence of the file? since to be contributed, the snippet must be compatible with
it. To put it another way, why treat a snippet (a cut and paste) differently from
a usual contribution? If someone really wants to cut a function out of Linux and
put it in BSD based on the theory that it's originally a snippet under a permissive
licence, they'll have to do a lot of legal analysis anyway.

The problem you'll run into if you track snippets differently is that once a
snippet inside a file is modified, under the DCO the modifications are under the
licence "of the file" not of the snippet, so the newly derived snippet is now
unconditionally under the licence of the file and that would make any separate
tracking of the snippet licence wrong unless someone manually keep it in sync,
which is not a burden any maintainer wants.

The way we handle explicitly allowing code to move from Linux to BSD (usually
in the area of drivers) is to make the *file* licence dual GPLv2/BSD to it's
unequivocally agreed that every contribution is under both licences and thus a
cut and paste from anywhere in the file is OK to go under a sole BSD licensed


Join { to automatically receive all group messages.