Gisi, Mark twisted the bytes to say:
>>> SPDX-License-Notice: This file is licensed under the following license(s): >>> SPDX-License-Identifier: MIT >>> SPDX-License-More-Information: http://wiki.spdx.org/ Mark> One aspect of SPDX we struggle with is its relatively weak Mark> support for representing file level licensing terms. The decision Mark> to water down the meta tag info to a simple license identifier, Mark> in my opinion, might be moving in the wrong direction. It is Mark> natural to want to take the path of least resistance for adoption Mark> purposes, but we are losing a significant amount of information Mark> required to be compliant. It should be a deal breaker once we Mark> start losing information. Mark, I agree with you. With the current SPDX, you can name licenses, but not to indicate the precise license requirements that you might have when those licenses need to interact. In a way, every time somebody uses a complex license statement that involves a previously known license, and adds/removes further statements, they are creating a new license. For example, GPLv2+ does not exist as a license per-se. It is a creation of adding an extra clause to the license at the file statement level (or any further version). Hence, the license is GPLv2 and (any-further-version applied to this license). that is why once we get into the exceptions of the GPL we get into a combinatorial problem. It is necessary to list every GPL version with + or not, and with every exception or not. What if more than one exceptions are used? Is it GPLv2-CLASSPATH-EXCEPTION AND GPLv2-BISON-EXCEPTION? but I also think that SPDX is not the place to do this. I think SPDX will go a long way if the data is extracted in a single location, rather than in each file. For instance, if many files have the same complex license statement, then by having it in the SPDX as an unknown license, I can go and analyze it once, rather than having to open each file. So yes, it is complex, but I don't think SPDX is the solution to clarify the licensing terms of a file (at least not yet). What I'd like SPDX to be for is being able to list, in a simple manner, the licenses used by the system, and the files that use them, so I don't have to track them down in the files. Mark> As Michael Herzog pointed out, Licenses and License Notices are Mark> different. File licensing terms are typically captured in one or Mark> more file license notices (NOTICES). A NOTICE is typically a rich Mark> free form description of licensing terms that references one or Mark> more licenses (LICENSES). NOTICES are typically easy to represent Mark> using simple Boolean expressions as opposed to a single license Mark> identifier. An important defining characteristic of a LICENSE is Mark> - the text (its meaning) doesn't change – a LICENSE is well Mark> defined and immutable (GPL-2.0, Apache-2.0, EPL-1.0). A LICENSE Keep in mind, the licenses-in-file (such as the BSDs and MITs) are changed all the time... and are not immutable (but we have been working on templates to deal with that problem). --dmg Mark> represents the constants in a boolean license expression and Mark> boolean license expressions represent file NOTICES. I realize Mark> that many files NOTICES can be represented using a single license Mark> identifier but many others cannot. For example: Mark> Example 1: Mark> ---------- Mark> File: ./cairo-1.10.2.tar.gz.txt/cairo-array.c (see attachment 1) Mark> NOTICE (simplified): "The file is licensed to you under either the LGPL-2.1 or MPL-1.1 at your option." Mark> LICENSE EXPRESSION = (LGPL-2.1 OR MPL-1.1) Mark> Example 2: Mark> ---------- Mark> FILE: busybox-1.20.2/shell/math.c (see attachment 2) Mark> NOTICE (simplified): "You can redistribute the file and/or modify it under the terms of BSD-3-Clause and the MIT license and GPL-2.0 or (at your option) any later version of the GPL" Mark> LICENSE EXPRESSION = (BSD-3-Clause AND MIT AND GPL-2.0+) Mark> Example 3: Mark> ---------- Mark> FILE: qt-mobility-opensource-src-1.2.0.tar.gz/AST.cpp (see attachment 3) Mark> NOTICE (simplified): "The licensing of this file is under the MIT AND either 1) Restricted Distribution license Or 2) the LGPL-2.1 Or 3) the LGPL-2.1 with additional rights" Mark> LICENSE EXPRESSION = MIT AND (LicenseRef-1 OR LGPL-2.1 OR (LGPL-2.1 AND LicenseRef-1)) Mark> Example 4: Mark> ---------- Mark> The Example 3 license expression is unusually complex. We could (and perhaps should) represent it using a single LicenseRef instead. There are, after all, many examples of custom (non-SPDX license) NOTICES out in the wild. How can a single LicenseRef be represented using the current meta-tag proposal? Mark> I am a big advocate for meta-tagging. We use it internally and we evangelized it at the Linux Collab Summit back in April. My main concern is: if we don't choose a sufficiently expressive syntax, and end up losing information, then we will have done more damage to SPDX than good. It needs to represent NOTICES and not just a single license. Mega-tagging should NOT be a replacement for traditional file license NOTICES. It should augment their existence in support of greater automation. Mark> We might want to consider a syntax that could support moderately complex NOTICE expressions. For example, we might consider a syntax similar to html: <SPDX-Licensing (BSD-3-Clause and MIT and GPL-2.0+) /> Mark> Note that the choice of key word here is not SPDX-License-"Identifier" but one that would suggest a license *expression*. Again, to my point above, we want to represent the file license NOTICE terms and therefore be less license "identifier" centric. We also may want to consider a syntax that is extensible via *optional* parameters. For example, having the ability to include the license list version would important. <SPDX-Licensing (BSD-3-Clause and MIT and GPL-2.0+) List=1.19 /> Mark> Or <SPDX-Licensing (LGPL-2.1 OR MPL-1.1) SPDX=http://wiki.spdx.org /> Mark> While simple things are still relatively simple: <SPDX-Licensing GPL-2.0 /> Mark> I attached one of the file examples we used at the Linux Collab Summit 2013 (see attachment 4). We still see flaws in this approach but it does address the issues highlighted above. We are not wedded to a particular syntax. We are wedded to obtaining better information to generate the required artifacts needed for achieving strong compliance (see attachment 5). One of our guiding principles is: how can we support strong compliance in a cost effective manner. SPDX 1.x has taken us to the next level. With the right tagging syntax we can go much higher. Mark> - Mark Mark> Mark Gisi | Wind River | Senior Intellectual Property Manager Mark> Tel (510) 749-2016 | Fax (510) 749-4552 Mark> -----Original Message----- Mark> From: spdx-biz-boun...@lists.spdx.org [mailto:spdx-biz-boun...@lists.spdx.org] On Behalf Of D M German Mark> Sent: Thursday, October 03, 2013 7:50 PM Mark> To: Wheeler, David A Mark> Cc: spdx-tech@lists.spdx.org; SPDX-biz; SPDX-legal Mark> Subject: Re: meta-tag page Wheeler, David A twisted the bytes to say: David> From a programmer's perspective I think the "cryptic" approach David> is FAR David> superior. There are lots of tools that can David> quickly examine files and David> return text with the pattern David> "SPDX-License-Identifier: ", and other David> tools that can David> trivially process the stuff after it. The above David> David> alternative is more work to process, and humans don't like David> unnecessary David> work :-). David> If you want more boilerplate with the goal of enforceability, you David> might try a format that's trivial to process, e.g.: David> SPDX-License-Notice: This file is licensed under the following license(s): David> SPDX-License-Identifier: MIT David> SPDX-License-More-Information: http://wiki.spdx.org/ Mark> I like this idea. Mark> My point is not about being cryptic or not, but being able to convey what the intention is to people who don't know anything about SPDX. There needs to be a way that if somebody opens the file, they know that that SPDX-License-Identifier means, and that it is an intention to license the file under that license. Mark> Now regarding the immutability of the SPDX license list, one way to deal with it is to version the list, but then the version of the list would have to be included in the file that is referring to the license. Mark> --dmg Mark> -- Mark> Daniel M. German "A coin symbolizes our free will" El Zahír, Jorge Luis Borges http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . Mark> _______________________________________________ Mark> Spdx-biz mailing list Mark> spdx-...@lists.spdx.org Mark> https://lists.spdx.org/mailman/listinfo/spdx-biz -- Daniel M. German "If Microsoft ever does applications Linus Torvalds -> for Linux it means I've won." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . _______________________________________________ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
