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

Hello,

 

I would like to request addition of the Eclipse Distribution License in the SPDX license list. The EDL-1.0 is a variation of the New BSD License (fixing . Here is what I would suggest:

 

1.    License name: Eclipse Distribution License 1.0

2.    Proposed Identifier: EDL-1.0

3.    URL: https://www.eclipse.org/org/documents/edl-v10.php

4.    See attached file.

5.    Indicate whether the license is OSI-approved : “The Eclipse Distribution License is an OSI Approved Open Source License by means of the New BSD License.” As said on the license’s full text page

6.    This license is used by Eclipse JGIT https://github.com/eclipse/jgit/blob/master/LICENSE with the following text:

This program and the accompanying materials are made available

under the terms of the Eclipse Distribution License v1.0 which

accompanies this distribution, is reproduced below, and is

available at http://www.eclipse.org/org/documents/edl-v10.php

 

Thank you in advance to take this request into account.

 

Regards,

Aurélien

 

[@@ THALES GROUP INTERNAL @@]

 

Hello,

 

I have received a preliminary positive report from OSI’s license committee on the Cryptographic Autonomy License v.1.0, or “CAL”.

The CAL also includes a built-in “Combined Works Exception” that seems like it would fit with your exception grammar.

1.       1. Provide a proposed Full Name for the license or exception:

2.       Cryptographic Autonomy License, v1.0, or
Cryptographic Autonomy License version 1.0, with Combined Work Exception”

3.      

4.       2. Provide a proposed Short Identifier.

5.       CAL-1.0 or CAL-1.0-with-exception

6.        

7.       3. Provide a functioning url reference to the license or exception text, either from the author or a community recognized source.

8.       https://docs.google.com/document/d/1-eD9EH6i3wdSXgG4XJbF-a0cSSknOERjYzlVonOwAQ0/edit?usp=sharing

9.        

10.   4. Create and attach a text file with the license or exception text from the url provided in #3.

11.   Attached.

12.    

13.   5. Indicate whether the license is OSI-approved (see: http://www.opensource.org/licenses/alphabetical) or whether it has been submitted for approval to the OSI and is currently under review.
It is currently under review and I expect approval.

14.   6. Provide a short explanation regarding the need for this license or exception to be included on the SPDX License List, including identifying at least one program that uses this license.

15.   I expect this will be approved by the OSI shortly. As soon as it is approved, Holochain will be moving to use it.

 

Van Lindberg Member VLindberg@...

210-554-5294 Direct 210-554-5500 Main 855-256-1479 Fax 214-364-7985 Mobile

112 E. Pecan Street, Suite 1800  San Antonio, Texas  78205 www.dykema.com

*** Notice from Dykema Gossett PLLC: This Internet message may contain information that is privileged, confidential, and exempt from disclosure. It is intended for use only by the person to whom it is addressed. If you have received this in error, please (1) do not forward or use this information in any way; and (2) contact me immediately. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Hi,

The Arch Linux community recently started a discussion around adopting
SPDX license identifiers to simplify/improve their license handling:

    https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029695.html

I imagine that the SPDX community may be interested in chiming in if
there are any known pitfalls on doing so, or general advice around it.

Cheers!
-Santiago.