Re: public comments: release candidate version 3 (rc3)

Alexios Zavras <alexios.zavras@...>

Additionally (since I was the one who raised the issue), "copyleft" was only mentioned once in an example list of what to look for, something like "code that might have copyleft obligations".
Since there was nothing special about copyleft (you always have to take care of the obligations of any license), changing it with a generic "license obligations" did not change the meaning of the example.

-- zvr

-----Original Message-----
From: specification@... <specification@...> On Behalf Of Mark Gisi
Sent: Monday, 18 November, 2019 06:35
To: specification@...
Subject: Re: [specification] public comments: release candidate version 3 (rc3)

Hi Till,

I understand your concern. Although you and I may understand the importance of the copyleft principle, our understanding may not necessarily be universal. Let me explain.

The spec serves many different audiences (e.g., small vs huge companies; automotive vs medical device vs SaaS; North American vs Europe vs Asia, ...). We have committed to a number of guiding principles to ensure the spec remains simple, agnostic to specific practices and relevant to a diverse group. The guiding principles can be found here:

Two principles that are particularly relevant here are: i) the spec avoids legal advice and ii) less is more. For instance we avoid license interpretation:

Some could argue that "copyleft" is a legal term that requires legal interpretation. And often it is an unknown term to those new to open source compliance. The spec intentionally avoids mentioning of any specific license or license concept (e.g., permissive license, derivative works, public domain, ...) and focuses on the more basic obligation concepts (attributions, source code, build and install scripts, copy of licenses, ...).

Furthermore, the inclusion of the copyleft term, which is used just once in the spec, would require a definition. Its absence does not detract from the spec's objective - hence less is more.

"additional licensing obligations" was chosen because it is broader and hence more encompassing. It would include copyleft terms and additional permissive license terms (e.g., GPL-3 section 7).

- Mark

-----Original Message-----
From: specification@... [mailto:specification@...] On Behalf Of Till Jaeger via Lists.Openchainproject.Org
Sent: Sunday, November 17, 2019 10:16 AM
To: specification@...
Subject: Re: [specification] public comments: release candidate version 3 (rc3)

Dear Mark,

Why not defining "Copyleft"? Copyleft is a crucial issue it would be a pitty to hide this behind "additional licensing obligations" (which is quite unspecific).



Am 17.11.19 um 08:06 schrieb Mark Gisi:
We have receive feedback from the larger public as part of the public
comments stage. Some of which has been incorporated in to the 2.1
draft rc3 while the remainder was queued for the next major version
revision that commences January 2020. Recent updates added in draft rc3 included:


·        SPDX project updated the definition of SPDX

·        Improve the word flow of the compliant artifact definition

·        An update to the compliant artifact examples definition to include:
“build and install scripts”

·        "copyleft obligations" was replaced with "additional
licensing obligations" – because copyleft was not defined, used only
once and was too specific.

·        Lowercased ‘S’ in “Software” in definition section 2.2


The current draft is available at:


Past readers of the spec might find the marked up version useful:


You can send public comments feedback via:

·        the Mailing list: the list

·        the issues wiki: issues list
<>; or

·        replying to me directly if you wish to remain anonymous
(mark.gisi@... <mailto:mark.gisi@...>)





*Mark Gisi | Wind River | Director, IP & Open Source *

*Tel (510) 749-2016 | Fax (510) 749-4552*


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0,
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Join to automatically receive all group messages.