RE: meta-tag page - part II
If I follow your argument, this code would now be covered by a GPL-2.0+ AND GPL-2.0 license construct. This is obviously absurd: I cannot both include and exclude the or later option simultaneously. Why not? I'm thinking you can under GPLv2 as it applies to this entire file. As to whether it would make sense in some larger context that could certainly be discussed. Jack -Original Message- From: spdx-biz-boun...@lists.spdx.org [mailto:spdx-biz-boun...@lists.spdx.org] On Behalf Of Wolfgang Denk Sent: Monday, October 07, 2013 4:42 AM To: Gary O'Neall Cc: spdx-t...@lists.spdx.org; 'SPDX-legal'; 'SPDX-biz'; 'Wheeler, David A'; d...@uvic.ca Subject: Re: meta-tag page - part II Dear Gary, In message 001f01cec2e5$9f1d9b20$dd58d160$@com you wrote: The AND situation would occur if you have a file which contains code from two or more different sources using two or more different licenses. In that case, I believe you would need to satisfy the obligations of all licenses (note: I'm not a lawyer so I am not proposing or providing a legal interpretation). Hopefully there is no conflict between the license obligations. I don't think this could work. We encountered such cases when we analyzed the U-Boot code while introducing license tags. There were some files that came with a the full GPL-2.0+ license header, but further down in the code that had a short comment that some parts (a few functions) have been copied from the Linux kernel. The analysis shows that the original Linux kernel files were covered by GPL-2.0 only. If I follow your argument, this code would now be covered by a GPL-2.0+ AND GPL-2.0 license construct. This is obviously absurd: I cannot both include and exclude the or later option simultaneously. Our understanding of the legal situation left two solutions: either we remove the GPL-2.0 code (and replace it by a clean-room implementation of similar functionality), or we change the file's license terms to GPL-2.0. We did the latter: the files are now licensed under GPL-2.0, i. e. the or later option had to be dropped for the file as a whole, because it was not available for the parts imported from Linux. There was no way to AND both licenses here. --- For a license set, when there is a choice between licenses (disjunctive license), they should be separated with or and enclosed in parentheses. When multiple licenses apply (conjunctive license), they should be separated with an and and enclosed in parentheses. Example: (LGPL-2.1 or MPL-1.1). --- Do you have an example, where such a conjunctive license construct actually works? We were also concerned about the difficulty in parsing the strings. We came up with enclosing them in parenthesis to aid in accurate and unambiguous parsing. For example, (LGPL-2.1 and (MPL-1.1 or BSD-3-Clause)) would describe the licensing for a file which contains code from an LGPL 2.1 package and code from a package licensed under a choice of MPL-1.1 or BSD-3-Clause. Understood. However, I think these are only very few pathological cases, and it would be nice to keep the syntax simple for the overwhelming majority of practical use cases. My vote goes for a simple white speace separated list of license IDs which should be interpreted as OR. Do you think it would be possible to extend the spec to allow for the (much easier to parse) lic1 lic2 [...] as synonym for (lic1 OR lic2 [OR ...]) ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Steal five dollars and you were a petty thief. Steal thousands of dollars and you are either a government or a hero. - Terry Pratchett, _Going_Postal_ ___ Spdx-biz mailing list spdx-...@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-biz ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: meta-tag page - part II
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
RE: meta-tag page - part II
Hi Wolfgang, I agree that if a conflict in licenses exist (as in your example) you cannot just AND the licenses together since that leads to conflicting terms. IMO you are taking the right approach in resolving the conflict and recording a non-conflicting license in the file. If there is no conflict in license terms, however, I do not see an issue in using this approach. I run across a large volume of MIT style and BSD style licenses mixed in with GPL code, for example. Using AND'd licenses is a compact way of stating all of the terms from license A and all of the terms for license B apply. I don't think it is critical to use the same syntax in the tagging as we do in the SPDX documents. I do, however, think it is important that we don't lose any embedded licensing information. For example, if there is an MIT notice stuck in the middle of a GPL licensed file, we should retain that information and not just call it a GPL licensed file. BTW - the issue of conflicting licenses is still an open issue as to whether we use the AND'd licenses to record the any conflicting licenses found within the same SPDX package or file. Gary -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, October 07, 2013 1:42 AM To: Gary O'Neall Cc: 'Wheeler, David A'; 'SPDX-legal'; spdx-t...@lists.spdx.org; 'SPDX-biz'; d...@uvic.ca Subject: Re: meta-tag page - part II Dear Gary, In message 001f01cec2e5$9f1d9b20$dd58d160$@com you wrote: The AND situation would occur if you have a file which contains code from two or more different sources using two or more different licenses. In that case, I believe you would need to satisfy the obligations of all licenses (note: I'm not a lawyer so I am not proposing or providing a legal interpretation). Hopefully there is no conflict between the license obligations. I don't think this could work. We encountered such cases when we analyzed the U-Boot code while introducing license tags. There were some files that came with a the full GPL-2.0+ license header, but further down in the code that had a short comment that some parts (a few functions) have been copied from the Linux kernel. The analysis shows that the original Linux kernel files were covered by GPL-2.0 only. If I follow your argument, this code would now be covered by a GPL-2.0+ AND GPL-2.0 license construct. This is obviously absurd: I cannot both include and exclude the or later option simultaneously. Our understanding of the legal situation left two solutions: either we remove the GPL-2.0 code (and replace it by a clean-room implementation of similar functionality), or we change the file's license terms to GPL-2.0. We did the latter: the files are now licensed under GPL-2.0, i. e. the or later option had to be dropped for the file as a whole, because it was not available for the parts imported from Linux. There was no way to AND both licenses here. --- For a license set, when there is a choice between licenses (disjunctive license), they should be separated with or and enclosed in parentheses. When multiple licenses apply (conjunctive license), they should be separated with an and and enclosed in parentheses. Example: (LGPL-2.1 or MPL-1.1). --- Do you have an example, where such a conjunctive license construct actually works? We were also concerned about the difficulty in parsing the strings. We came up with enclosing them in parenthesis to aid in accurate and unambiguous parsing. For example, (LGPL-2.1 and (MPL-1.1 or BSD-3-Clause)) would describe the licensing for a file which contains code from an LGPL 2.1 package and code from a package licensed under a choice of MPL-1.1 or BSD-3-Clause. Understood. However, I think these are only very few pathological cases, and it would be nice to keep the syntax simple for the overwhelming majority of practical use cases. My vote goes for a simple white speace separated list of license IDs which should be interpreted as OR. Do you think it would be possible to extend the spec to allow for the (much easier to parse) lic1 lic2 [...] as synonym for (lic1 OR lic2 [OR ...]) ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Steal five dollars and you were a petty thief. Steal thousands of dollars and you are either a government or a hero. - Terry Pratchett, _Going_Postal_ ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: meta-tag page - part II
Dear Gary, In message 002f01cec378$2f2a3470$8d7e9d50$@com you wrote: If there is no conflict in license terms, however, I do not see an issue in using this approach. I run across a large volume of MIT style and BSD style licenses mixed in with GPL code, for example. Using AND'd licenses is a compact way of stating all of the terms from license A and all of the terms for license B apply. But this example doesn't work either. If you mix a license that allows modify and keep the modified code closed with GPL, the only legally possible result is GPLed code. I see little value in constructing such more or less artificial examples. All code that I've seen so far in real life was either simple, i. e. covered by a single license, or it came under two (I'd have to think hard if I had to quote an example with more than two) licenses, which would implement a choice - either you use the code under GPL, or under a BSD license; either you use the commercial license, or GPL. It has always been this or that. Things become more difficult when importing such code into another project - then you usually have to decide which of the available choices you chose, and go with that. At this point, the other option becomes void. I don't think it is critical to use the same syntax in the tagging as we do in the SPDX documents. I do, however, think it is important that we don't lose any embedded licensing information. For example, if there is an MIT notice stuck in the middle of a GPL licensed file, we should retain that information and not just call it a GPL licensed file. True. The clause The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. explicitly requires that. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Beware of programmers carrying screwdrivers. - Chip Salzenberg ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: meta-tag page - part II
Wolfgang Denk [mailto:w...@denx.de] But there there is no actual choice. Yes, you take the parts of the project that do not include the GPL code - and you can use this code under the MIT license for other purposes. But as soon as we talk about the thing as a whole (say, the linked binary), then you do not have any choice, then it's GPL. GPL without any ORs or ANDs. Ah, but these are not linked binaries. These are scripts, and it's trivial to remove one of the scripts the rest of the software is straight-up MIT. Even for the MIT+GPLv2 script, it's trivial to remove a certain set of lines to make it MIT-only. Also: We agree that the effect of MIT AND GPLv2, legally, is just GPLv2... but some other license combinations do not simplify so easily. Anyway, I think it's important to be able to express more complex situations than this file has license X. In many cases, a file has multiple licenses, not one license; being able to express that situation is very helpful. -- David A. Wheeler ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: meta-tag page - part II
Wolfgang Denk wrote at 04:42 (EDT): the files are now licensed under GPL-2.0, i. e. the or later option had to be dropped for the file as a whole, because it was not available for the parts imported from Linux. Files aren't copyright-magical-single-units. Nothing in the copyright statute talks about how licenses go with files. Licenses go with works, and works can be merged, combined together, derived from, etc. to form new works which incorporate both its antecedents. Technologically, if you can get back to the original work and be sure that other works aren't mingled with it, then you are back to the original license. The easy way to do this is keep separately licensable works in different files, but that's not the only way. Thus, while splitting a file back up into parts that are GPLv2-only and GPLv2-or-later is difficult, it's not impossible, and you definitely change the outcome by observing it if you declare the license of a whole file to be GPLv2-only simply because some copyrightable material that was GPLv2-only was brought in. That said, I'm not a fan of this obsession to try to get perfect information about the license of a work, or its files, or anything else. It doesn't actually help compliance in ways that matter. -- -- bkuhn ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: meta-tag page - part II
Dear Mark, In message 01813e194c768044a6486db30b5338ccb711e...@ala-mba.corp.ad.wrs.com you wrote: Example 1: -- File: ./cairo-1.10.2.tar.gz.txt/cairo-array.c (see attachment 1) NOTICE (simplified): The file is licensed to you under either the LGPL-2.1 or MPL-1.1 at your option. LICENSE EXPRESSION = (LGPL-2.1 OR MPL-1.1) Example 2: -- FILE: busybox-1.20.2/shell/math.c (see attachment 2) 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 LICENSE EXPRESSION = (BSD-3-Clause AND MIT AND GPL-2.0+) Sorry but I think you get this wrong. The and in the text here does not translate into a logical AND operator. Instead, it is an OR just as in example 1. We have a list of liceses here, where the user can freely chose any one that fits, so it must be an OR. An expression as BSD-3-Clause AND MIT AND GPL-2.0+ makes zero sense; I can't even figure out how this should be interpreted from a legal point of view. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Boykottiert Microsoft - Kauft Eure Fenster bei OBI! ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
