Hi Richard, Sorry for the late response. To be honest I assumed this would just go away because it is so impractical and just make work imho. But apparently people are still pushing for this. And seeing some other questions around this in the devel list, it seems people are as confused as I am about the why of this. To be clear I don't mind using a different set of short-hands in the License tags. Although it feels a little odd to try to create separate identifiers for lax-permissive MIT/BSD like licenses which sometimes just different in one or two words. However I really don't understand the purpose or goal of this idea of creating a large expression of all the license/permission notices that might be found in the sources that possibly make up the binary to the License tag. Because in my experience those are often not relevant or accurate at all. On Fri, Feb 17, 2023 at 04:48:05PM -0500, Richard Fontana wrote: > On Fri, Feb 17, 2023 at 3:07 PM Mark Wielaard <mark@xxxxxxxxx> wrote: > > If there is a reference to the original code and version that was > > incorporated then you could maybe look at that and reuse that under > > the original declared license. But I think it is somewhat pointless to > > list all such code snippets separately under their original license > > terms. For all intends and purposes those snippets of code are really > > (re)distributed under the GPL now by the project incorporating them. > > > > What is the goal of dropping the effective license and make packagers > > list all the licences of some code snippets originally incorporated > > under lax-permissive licenses? Is that not just make work for the > > packager if upsteam just uses one effective license? > > One rationale is given in Fedora legal documentation: > "There is no agreed-upon set of criteria or rules under which one can > make conclusions about “effective” licenses or reduce composite > license expressions to something simpler." Isn't that not just like most other things fedora, we follow upstream. Upstream states the (effective) license and we just adopt that. If we notice that there might be a bug and the effective license isn't exactly as the upstream project states, then we fix that upstream? > Basically, everyone has been making up their own interpretive system > for deciding what an "effective license" is, with no consistencies > across upstream packages and Fedora package maintainers. Is this really a problem? Could you show an example where an upstream or package maintainer stated in the license tag that the effective license was say "GPLv3+", but it would have been more "correct" to state that it was "GPL-3.0-or-later AND GPL-3.0-or-later WITH Autoconf-exception-generic-3.0 AND GPL-3.0-or-later WITH Bison-exception-2.2 AND GPL-2.0-or-later AND GPL-2.0-or-later WITH Autoconf-exception-generic AND LGPL-2.1-or-later AND LGPL-2.0-or-later AND X11"? I think the simple summary of GPLv3+ is probably more correct (and to keep correct) than the later license acronym salad. > Given that > situation, we are aiming for a more objective and administratively > easier standard for downstream package license metadata: a simple > enumeration of the licenses covering any code or content in the > installed RPM. It seems that the "enumeration" expression is not that easy to create objectively. If only because it is actually hard to know which sources to scan to get the license/permission snippets (just the upstream tar ball, the sources as created by fedpkg prep, those actually included in the binaries which depend on the build environment, etc.) And what is the actual purpose and goal of including them in the spec License tag? > Administratively easier because the package maintainer > doesn't have to construct some theory of effective licensing and > figure out how it applies to their package (possibly agreeing or > disagreeing with whatever theory of effective licensing the upstream > project has implicitly or explicitly developed, in subtle ways), or > apply some implicitly-formulated upstream theory which might not > actually make any sense; they just list the licenses they find in > relevant source files. I disagree that "just list the licenses they find" is simple or accurately describes the licenses covering the binaries. Also it seems weird to not simply use the license statement of the upstream project. If that statement is incorrect, then just treat it as a bug (that a package maintainer will try to fix upstream). > Also, I don't think "snippets" are the typical case. Often the non-GPL > license will appear to cover a whole file or perhaps a set of multiple > files. I have found it somewhat common for a Fedora package to include > multiple "merely aggregated" works which may be under the GPL and > other licenses. That's mere aggregation based on the license steward's > traditional guidance on interpretation of the GPL. In those scenarios > attempts to apply an effective license theory that ignores the non-GPL > license seem to embody a misunderstanding of the orthodox > interpretation of the GPL. That is not my experience from working on some larger code bases. For example when we were integrating GNU Classpath/IcedTea/OpenJDK I went over all the code to make sure we could merge the code bases. The top level LICENSE file explains the (effective) licenses. And every source code file has a header explaining the (effective) license for that file (GPLv2 or GPLv2-plus-classpath-exception). But it also includes lots of notices like: /* * This file is available under and governed by the GNU General Public * License version 2 only, as published by the Free Software Foundation. * However, the following notice accompanied the original version of this * file and, per its terms, should not be removed: * * Copyright (c) 2004 World Wide Web Consortium, * * (Massachusetts Institute of Technology, European Research Consortium for * Informatics and Mathematics, Keio University). All Rights Reserved. This * work is distributed under the W3C(r) Software License [1] in the hope that * it will be useful, but WITHOUT ANY WARRANTY; without even the implied * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * [1] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 */ Something similar is done in glibc. For example several files I contributed to were adapted from some BSD release and have a file header saying the file is copyright the Free Software Foundation, Inc. This file is part of the GNU C Library. And the state they are distributed under the GNU Lesser General Public License 2.1 or later. But also have the original BSD notice in the file: /*- * Copyright (c) 1990, 1993, 1994 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ But this is not the (effective) licenses, and there is no way to use the code under that license, since all contributions since 1994 have been done under the LGPL. Likewise for valgrind we have examples of the above. For example the dhat tool which have a GPLv2+ copyright and license header, but also say: /* Parts of this file are derived from Firefox, copyright Mozilla Foundation, and may be redistributed under the terms of the Mozilla Public License Version 2.0, as well as under the license of this project. A copy of the Mozilla Public License Version 2.0 is available at at https://www.mozilla.org/en-US/MPL/2.0/. */ Again, although there is a reference to MPLv2 here, the code is only available under GPLv2+. I believe including MPLv2 in the License tag for valgrind/dhat would be incorrect, even though a simple source scanning tool would suggest to include it. > When you say "upstream just uses one effective license", unfortunately > it is rarely so clear even if you set aside the basic lack of clarity > on what an effective license even is. In practice upstream often simply has a top-level COPYRIGHT, LICENSE or README file where they state the (effective) license, which covers the project as a whole. > The goal of the policy is not to promote reusability of isolated > source code elements under particular associated licenses. Rather, as > I see it, license metadata is fundamentally unnecessary, but if we are > going to have license metadata at all, and for better or worse I think > there is an expectation that we must, it might as well strive for > accuracy and consistency with metadata across all packages. I don't think trying to include SPDX expression for all license/permission snippets some source scanning tools can find is really accuracte or consistent. It will both miss some sources that do end up in the binaries and report some that won't or that aren't actually correctly describing the license permissions. Maybe doing what Debian does would better match your goal. Include a good faith attempt to include all copyright and license strings found in the upstream sources. Since we always distribute the sources someone who cares can then get those and look for the exact context and meaning of those strings. Cheers, Mark _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
