legal December 2013

legal@lists.fedoraproject.org

10 participants
10 discussions

Re: [Fedora-legal-list] CAcert.org license
by Tom Callaway 12 Feb '16

12 Feb '16

On Tue, 2008-12-09 at 23:03 +0100, Matthias Saou wrote: > > >>>>> "TC" == Tom \"spot\" Callaway <Tom> writes: > > > > TC> Given that it does not give permission for us to redistribute (the > > TC> cornerstone requirement for Content licenses), this license is not > > TC> acceptable for Fedora. > > > > I guess I'm glad I looked before approving the package, but I have to > > wonder: Do the cacert folks actually want anyone to use their > > certificates? I mean, this prevents basically everyone from using > > them, because they can't come with the OS or the browser. > > Personally, the more I read the document, the more I'm confused. > > "You may NOT distribute certificates or root keys under this > licence"... does this mean we can distribute under a different license? Well, sortof. The wording here is strange because you can get a different license from the CA issuer. We can't just pick a license, but the CA issuer might be willing to give us a different one. > Would it be worth getting in contact with CAcert.org in order to try > and have them allow us to redistribute the root certs under conditions > which are acceptable to the Fedora Project? Probably, yes. :) ~spot

4 6

winetricks
by T.C. Hollingsworth 01 Aug '15

01 Aug '15

winetricks [1] is free software, but I was originally under the impression that it was ineligible for inclusion in Fedora because it is used primarily to download and install non-free software. (That is not it's only function, though--it also does some registry hacks and can manage multiple WINEPREFIXes.) However, some members of the community disagree [2] and say that it might be eligible for Fedora, so we'd like confirmation one way or the other. Thanks! -T.C. [1] http://winetricks.org/ [2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=1992#c40

5 7

Linking of GPL-only and GPL-incompatible libraries
by Florian Weimer 25 Aug '14

25 Aug '14

What's Fedora's stance on linking GPL-only libraries into the same process as a library which is considered GPL-incompatible (such as 4-clause BSD) if this linking happens rather indirectly? We currently link psql against both libreadline and libcrypto/libssl (OpenSSL), so if that is okay, more indirect linking should be acceptable as well. However, I'm not sure I'd appreciate that if I were a GPL-only library author who chose that license deliberately (perhaps even with a desire to sell alternative licensing), and some intermediate libraries makes my work available under a more permissive license, only wrapped in a different programming interface. -- Florian Weimer / Red Hat Product Security Team

3 12

Re: [Fedora-legal-list] Exceptions restricting program name are compatible with "LGPLv2 with exceptions", correct?
by Jeff Backus 21 Jan '14

21 Jan '14

Hi Tom, Below is Tuomo's response regarding the Notion license in its entirety. In short, he was not interested in modifying the terms of the license, however, he did confirm that the Notion satisfies the terms of the current license. So, what's next? Is there anything I can do to help the process along? Regards, Jeff -------- Original Message -------- Subject: Re: Questions Regarding the Ion(tm) License Date: Sat, 7 Dec 2013 10:15:16 +0000 From: Tuomo Valkonen <tuomov(a)iki.fi> To: Jeff Backus <jeff.backus(a)gmail.com> > On 06 Dec 2013, at 12:44, Jeff Backus <jeff.backus(a)gmail.com> wrote: > > Dr. Valkonen, > > I know you are very busy, so I will be brief. > > I am writing to you on behalf of the Notion project, which is a fork of Ion3(tm) created in 2010. Since you have obviously moved onto bigger and better things and Ion3(tm) has not been active since 2009, we feel that the additional clauses added to the LGPL 2.1 license are no longer necessary to avoid confusion with regard to supporting unofficial versions - particularly since you have officially stated that you no longer offer support of any version. Therefore we ask that you grant permission to the Notion project to distribute as part of the Notion project any and all Ion(tm)-related material, including but not limited to primary and ancillary code and documentation, under the terms of the official LGPL version 2.1 as specified at https://www.gnu.org/licenses/lgpl-2.1.html. > > If you are not interested in releasing Ion(tm) under the official LGPL, either through Notion or other means, would you please at least verify that the Notion name sufficiently satisfies the Ion3(tm) license? It does. Tuomo > > An simple e-mailed response is sufficient for either request. I thank you in advance for your time. > > Kind Regards, > Jeff > > -- > Jeff Backus > jeff.backus(a)gmail.com > http://github.com/jsbackus > >

2 5

FDLIBM license
by Milan Bouchet-Valat 30 Dec '13

30 Dec '13

Hi! I'd like to package the openlibm library [1] which is a dependency of the Julia language [2]. The original license of the project, besides later contributions which are under BSD and MIT licenses, is an apparently custom license whose text is as follows (see [3]): Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. Developed at SunPro, a Sun Microsystems, Inc. business. Permission to use, copy, modify, and distribute this software is freely granted, provided that this notice is preserved. The text looks like slightly contradictory since it starts stating "All rights reserved" before granting the rights to do mostly anything you want with the code given the license is preserved. I guess it is OK to ship it, but I would like a confirmation for more clued people. As a secondary point, how should I indicate the license in the License field of the .spec file? FDLIBM and BSD and MIT? Regards 1: https://bugzilla.redhat.com/show_bug.cgi?id=1040517 2: https://github.com/JuliaLang/openlibm/ 3: https://github.com/JuliaLang/openlibm/blob/master/LICENSE.md

2 2

OpenCASCADE now under LGPL v2.1 plus exception
by Eric Smith 30 Dec '13

30 Dec '13

I'd like to package OpenCASCADE, which was formerly under a non-free license, but starting from version 6.7.0 it has been relicensed under LGPL v2.1 plus an exception. The full license is at: http://www.opencascade.org/getocc/license/ Here's the exception text, from the bottom of that page: Open CASCADE Exception (version 1.0) to GNU LGPL version 2.1. The object code (i.e. not a source) form of a "work that uses the Library" can incorporate material from a header file that is part of the Library. As a special exception to the GNU Lesser General Public License version 2.1, you may distribute such object code incorporating material from header files provided with the Open CASCADE Technology libraries (including code of CDL generic classes) under terms of your choice, provided that you give prominent notice in supporting documentation to this code that it makes use of or is based on facilities provided by the Open CASCADE Technology software. Is this acceptable for Fedora? Is the appropriate license tag "LGPLv2 with exceptions"? Thanks! Eric

3 2

Any legal issues against Bumblebee and bbswitch?
by twohot 25 Dec '13

25 Dec '13

Season's Greetings I have noticed that Bumblebee[1] and associated bbswitch[2] module are not in the official fedora repository. I am not aware of any proposal to package it for fedora but I am game. I'd like to know if there is any legal reason this shouldn't happen. Regards Onyeibo [1] http://bumblebee-project.org/ [2] https://github.com/Bumblebee-Project/bbswitch

2 1

Any legal issues against Bumblebee and bbswitch?
by Onyeibo Oku 25 Dec '13

25 Dec '13

1 0

Exceptions restricting program name are compatible with "LGPLv2 with exceptions", correct?
by Jeff Backus 03 Dec '13

03 Dec '13

Hi, I would like to package a window manager named Notion. It is a fork of the Ion(tm) window manager. Ion(tm) is released under the LGPLv2.1 with an addendum that restricts derivative works from calling said works Ion(tm) or using a name that implies being apart of the Ion(tm) project. The nature of these restrictions appears to be inline with the GNU free software philosophy, as is stated in the following paragraph: However, rules about how to package a modified version are acceptable, if they don't substantively limit your freedom to release modified versions, or your freedom to make and use modified versions privately. Thus, it is acceptable for the license to require that you change the name of the modified version, remove a logo, or identify your modifications as yours. As long as these requirements are not so burdensome that they effectively hamper you from releasing your changes, they are acceptable; you're already making other changes to the program, so you won't have trouble making a few more. -- "What is Free Software?" (https://www.gnu.org/philosophy/free-sw.html) The addendum is included below for reference. The complete license, including addendum, is available here: https://github.com/jsbackus/notion/blob/master/LICENSE Given that the software I would like to package is released under a different name, I do not see any conflicts with Fedora's licensing guidelines. Am I correct in my interpretations? Is this license compatible with Fedora's "LGPLv2 with exceptions" license? Thank you in advance for your time and any clarification you can provide. Regards, Jeff -= Begin License Addendum =- Copyright (c) Tuomo Valkonen 1999-2009. Unless otherwise indicated in components taken from elsewhere, this software is licensed under the GNU Lesser General Public License, version 2.1 ("LGPL", reproduced below), extended and modified with the following terms: If the name Ion(tm) or other names that can be associated with the Ion project are used to distribute this software, then: - A version that does not significantly differ from one of the copyright holder's releases, must be provided by default. - Versions not based on the copyright holder's latest release (on the corresponding "branch", such as Ion3(tm)), must within 28 days of this release, be prominently marked as (potentially) obsolete and unsupported. - Significantly altered versions may be provided only if the user explicitly requests for those modifications to be applied, and is prominently notified that the software is no longer considered the standard version, and is not supported by the copyright holder. The version string displayed by the program must describe these modifications and the "support void" status. Versions for which the above conditions are not satisfied, must be renamed so that they can not be associated with the Ion project, their executables must be given names that do not conflict with the copyright holder's version, and neither the copyright holder nor the Ion project may be referred to for support. In the text of sections 0-2, 4-12, and 14-16 of the LGPL, "this License" is to be understood to refer to the LGPL extended with these terms and, where applicable, possible similar terms related to the names of other works forming a whole. Sections 3 and 13 of the LGPL are void. Where contradictory, these additional terms take precedence over the LGPL. End of terms. Explanations Trademarks: With the terms above primarily appealing to copyright law, should any of the indicated trademarks be found invalid, does not excuse you from the conditions imposed by those terms. The use of these names in contexts other than redistribution of this software and modifications, is outside the scope of the terms above, and governed by applicable trademark or other laws. With regard to modules and other extensions to Ion(tm), the permission is hereby granted to use "Ion" as part of the name, provided that it occurs in a form suggesting that the work is supported by neither the copyright holder nor the Ion project: "Foo for Ion" instead of "Ion Foo", etc. Significant change: Bug fixes are insignificant as additions. Basic changes that are needed to install or run the software on a target platform, are insignificant. Additionally, basic/small configuration changes to better integrate the software with the target platform, without obstructing the standard behaviour, are insignificant. Everything else is significant, unless expressly declared otherwise by the copyright holder. Distributions: For example, suppose an aggregate distribution of software provides an `installpkg` command for installing packages. Then the action `installpkg ion3` (resp. `installpkg ion`) should provide the latest release of Ion3 (resp. the latest stable release) 28 days from release date at the latest, or prominently notify the user that the provided version is (likely to be) obsolete and unsupported. The latest release being provided by default, or prominently appearing in a listing, constitutes prominent marking of earlier releases as obsolete. Specific versions (including modified versions) may be provided if the user explicitly requests for those, within the constraints set above. The intent of these terms is to curb the power that "distributions", as the primary sources of software for many users, have in defining what is perceived as Ion. By providing significantly modified versions and out-dated development snapshots without prominently mentioning this fact, they do not present the work in a light that the author can agree with, and create a burden of dealing with (new) users seeking for support for such versions. -= End License Addendum =- -- Jeff Backus jeff.backus(a)gmail.com http://github.com/jsbackus

2 6

Creative Commons 4.0
by Miro Hrončok 03 Dec '13

03 Dec '13

HI, as you might know, there are new CC 4.0 licenses. http://creativecommons.org/weblog/entry/40768 Do we need to specify in the package the version of CC? Like we do with e.g. GPL? I saw eairlier today: "Licensed under CC BY-SA 3.0 or later." Do we also need some kind of + as we have in GPL? CCv3+ BY-SA? Or does Creative Commons contain some part that makes it back and forward compatible, so we don't need to do this? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal December 2013