SPDX-License-Identifier for composite-licensed source files


Richard Fontana
 

Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following copyright and
* permission notice:
*
* Copyright 2013 Joe Bloggs
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
* SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
*/

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
* This file incorporates work covered by the following copyright
notice and license:
* Copyright 2013 Joe Bloggs
* SPDX-License-Identifier: Apache-2.0
*/

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard


Kate Stewart
 

Hi Richard,
    I suspect the others will comment as well,  but 
I would hope to see 
"SPDX-License-Identifier: MPL-2.0 AND Apache-2.0"
as a summary. 

The second approach may become ambiguous to scanners
as they may try to treat it as an "OR",  and I believe that
"AND" is truer to the intention here.

Kate

On Thu, Dec 12, 2019 at 10:30 AM Richard Fontana <rfontana@...> wrote:
Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following copyright and
 * permission notice:
 *
 *   Copyright 2013 Joe Bloggs
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *        http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *   See the License for the specific language governing permissions and
 *   limitations under the License.
 */

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
 * SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
 */

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
 * This file incorporates work covered by the following copyright
notice and license:
 *   Copyright 2013 Joe Bloggs
 *   SPDX-License-Identifier: Apache-2.0
 */

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard





J Lovejoy
 



On Dec 12, 2019, at 9:48 AM, Kate Stewart <kstewart@...> wrote:

Hi Richard,
    I suspect the others will comment as well,  but 
I would hope to see 
"SPDX-License-Identifier: MPL-2.0 AND Apache-2.0"
as a summary. 

Agree. And also agree with Richard’s comment about avoiding legal interpretations. When you say that the license is “X AND Y” you are saying both licenses apply. Which is the fact for this file. You are not saying  whether those licenses are compatible (or what one does if they are incompatible) - that would be a legal interpretation.  You are merely reporting what is in the file. 



The second approach may become ambiguous to scanners
as they may try to treat it as an "OR",  and I believe that
"AND" is truer to the intention here.

The second approach is also not an SPDX license expression as defined in the spec, so that’s also problematic when used with “SPDX-License-Identifier” (I think)

Jilayne


Kate

On Thu, Dec 12, 2019 at 10:30 AM Richard Fontana <rfontana@...> wrote:
Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following copyright and
 * permission notice:
 *
 *   Copyright 2013 Joe Bloggs
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *        http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *   See the License for the specific language governing permissions and
 *   limitations under the License.
 */

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
 * SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
 */

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
 * This file incorporates work covered by the following copyright
notice and license:
 *   Copyright 2013 Joe Bloggs
 *   SPDX-License-Identifier: Apache-2.0
 */

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard






Gary O'Neall
 

+1 on Kate’s recommendation.  This format will be properly parsed by the SPDX Tools parsers (the 3 parsers I am aware of) and I believe represents the intent behind the AND operator.

 

Gary

 

From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Kate Stewart
Sent: Thursday, December 12, 2019 8:49 AM
To: Richard Fontana <rfontana@...>
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: SPDX-License-Identifier for composite-licensed source files

 

Hi Richard,

    I suspect the others will comment as well,  but 

I would hope to see 

"SPDX-License-Identifier: MPL-2.0 AND Apache-2.0"

as a summary. 

 

The second approach may become ambiguous to scanners

as they may try to treat it as an "OR",  and I believe that

"AND" is truer to the intention here.

 

Kate

 

On Thu, Dec 12, 2019 at 10:30 AM Richard Fontana <rfontana@...> wrote:

Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following copyright and
 * permission notice:
 *
 *   Copyright 2013 Joe Bloggs
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *        http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *   See the License for the specific language governing permissions and
 *   limitations under the License.
 */

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
 * SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
 */

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
 * This file incorporates work covered by the following copyright
notice and license:
 *   Copyright 2013 Joe Bloggs
 *   SPDX-License-Identifier: Apache-2.0
 */

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard




Matija Šuklje
 

Hi Richard,

I think both your possibilities work, and with the current state
of art, I would agree with Kate, Jilayne and Gary.

On the other hand it seems to me that exactly how to mark source
code is perhaps a bit out of the scope of SPDX (I might be wrong
though).

A project that is based on SPDX that is aimed directly at properly
marking up source code is <https://reuse.software>.

For 4.0 (i.e. next major release) spec, one of the bigger tasks is
to properly handle snippets. There is already a ticket open, and
I’d love to hear your (and everyone else’s on this list, of
course) feedback:
<https://github.com/fsfe/reuse-docs/issues/34>


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