I think I understand Mark's reservations about package-level licenses and I agree with them.
On previous instances of this same discussion (there have been a few ☺), it seemed that there was a disconnect, which was mostly explained by what people were considering when thinking about “packages”. People coming from Java (Maven) environment had one idea, people with experience in Javascript (npm) a somewhat different one, etc. Myself, I come from a good ol’ Unix/C environment. In my mind, a “package” is, for example, a .tar.gz release of a specific software. So, what would be the package-level license of, say, zlib-1.2.10.tar.gz? We all know that zlib uses the Zlib license. However, keep in mind that this “package” (archive), contains: * The source of zlib, obviously, licensed under Zlib; but also * other files like “README” or “Changelog” without any specific license; and even * some source (in contrib/ada) under GPL-2.0+ (!) Therefore, if you are using this package/archive to generate a library with Ada bindings, the resulting artifact would probably be licensed under GPL-2.0+. If you ignore this contrib directory and generate the zlib library for C, Zlib is probably the correct license. For even more extreme fun, I can point to cases like ffmpeg, where, according to the options get passed to configure build script, different files (under different licenses) get compiled and linked. In all these cases, it seems that the “package-level license”, should simply be the collection of all different licenses found in all the files of the package. I think that Mark was wondering whether this is particularly useful… -- zvr – From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Marc Jones Sent: Tuesday, 12 September, 2017 19:48 To: W. Trevor King <wk...@tremily.us>; Wheeler, David A <dwhee...@ida.org> Cc: SPDX-legal <spdx-legal@lists.spdx.org> Subject: Re: GPLv2 - Github example Mark, You said 'A package is a “box of stuff” where some stuff may be related by linking while other stuff is not.' While I agree that is true, I am not sure I agree that dealing with it at a file level avoids many problems. For two reasons: 1) wheather lawyers and licensing nerds like it or not there is a huge amount of FOSS that has never had and will never have a licensing statement include in each file. And 2) The file doesn't play any special boundary in copyright law, at least not any more than one could argue any other method of organizing information on a computer does. You can have the same multi-license complications in a single file that are present in a multi-file package, Take for example a program composed of two files, one under the BSD license and one under a Apache license. What is the license of the combination? It is not clear, actually I don't think it is dictated in that case. Go ahead and cut and past the contents of one of those files into the other. Has your licensing gotten any more or less complicated? I think you are still left asking the question of what license the combined work is licensed under? -Marc On Tue, Sep 12, 2017 at 12:47 PM W. Trevor King <wk...@tremily.us<mailto:wk...@tremily.us>> wrote: On Tue, Sep 12, 2017 at 02:52:26PM +0000, Wheeler, David A wrote: > Mark Gisi: > > the SPDX identifier model will need to accommodate a LicenseRef > > like mechanism... > > I'm not arguing to *remove* licenserefs, I agree they can be useful. > > My point is different. Since many users *only* use SPDX license > expressions, it's important that SPDX license expressions have > enough expressiveness (hah!) for common use cases WITHOUT using > licencerefs. Agreed. I don't think anyone is arguing for removing LicenseRef. A new ‘only’ operator allows you to express ‘CDDL-1.0 only’ as a vanilla license expression where you currently need to use a LicenseRef, but there are obviously lots of other LicenseRef use cases that an ‘only’ operator will not replace. > > This is a far bigger problem than the "only" operator. In fact, it > > is the ill- conceived package license concept that is creating > > significant frustration and confusion over the GPL only issue. The > > problem is not at the file level. The license expression syntax is > > well suited for that. It is not well suited for the package > > level. Until that is addressed we will continue to struggle. > > It's not ill-conceived. Package-level results are the WHOLE POINT. I don't know if I'd go as far as that; being able to drill down to find the license for a particular file or snippet is useful too. But I certainly don't see a reason why license expressions would not work fine for projects given that they work fine for files; projects are just collections of files. Similarly, files are collections of snippets. SPDX license expressions can (and do?) allow to you state the license terms of any work, regardless of whether that work is a snippet, file, project, distro, …. What the ‘only’ operator is about is making vanilla license expressions (which do not reference custom LicenseRefs and such) more expressive. That will help folks who are restricted to vanilla license expressions, regardless of what they happen to be licensing. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org<mailto:Spdx-legal@lists.spdx.org> https://lists.spdx.org/mailman/listinfo/spdx-legal Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
