From apevec at gmail.com Tue Dec 1 11:42:33 2009 From: apevec at gmail.com (Alan Pevec) Date: Tue, 1 Dec 2009 12:42:33 +0100 Subject: [Fedora-legal-list] openpkg license for specs? Message-ID: <2be7262f0912010342v32af1e81t1d75b6d70720ea31@mail.gmail.com> Hi all, there's proposed spec in https://bugzilla.redhat.com/show_bug.cgi?id=541744#c1 with the license which is not listed in http://fedoraproject.org/wiki/Licensing#SoftwareLicenses ## liboping.spec -- OpenPKG RPM Package Specification ## Copyright (c) 2000-2009 OpenPKG Foundation e.V. ## ## Permission to use, copy, modify, and distribute this software for ## any purpose with or without fee is hereby granted, provided that ## the above copyright notice and this permission notice appear in all ## copies. ## ## THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED 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 AUTHORS AND COPYRIGHT HOLDERS AND THEIR ## 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. ## Would this be allowed in Fedora? http://fedoraproject.org/wiki/Licensing#License_of_Fedora_SPEC_Files says Fedora CLA is default but it also says "(unless otherwise explicitly licensed)" Cheers, Alan From tcallawa at redhat.com Tue Dec 1 17:16:46 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 01 Dec 2009 12:16:46 -0500 Subject: [Fedora-legal-list] openpkg license for specs? In-Reply-To: <2be7262f0912010342v32af1e81t1d75b6d70720ea31@mail.gmail.com> References: <2be7262f0912010342v32af1e81t1d75b6d70720ea31@mail.gmail.com> Message-ID: <4B154F7E.4050307@redhat.com> On 12/01/2009 06:42 AM, Alan Pevec wrote: > Hi all, > > there's proposed spec in https://bugzilla.redhat.com/show_bug.cgi?id=541744#c1 > with the license which is not listed in > http://fedoraproject.org/wiki/Licensing#SoftwareLicenses > > ## liboping.spec -- OpenPKG RPM Package Specification > ## Copyright (c) 2000-2009 OpenPKG Foundation e.V. > ## > ## Permission to use, copy, modify, and distribute this software for > ## any purpose with or without fee is hereby granted, provided that > ## the above copyright notice and this permission notice appear in all > ## copies. > ## > ## THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED 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 AUTHORS AND COPYRIGHT HOLDERS AND THEIR > ## 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. > ## > > Would this be allowed in Fedora? Yes, that's MIT. ~spot From npajkovs at redhat.com Wed Dec 2 10:25:52 2009 From: npajkovs at redhat.com (Nikola Pajkovsky) Date: Wed, 02 Dec 2009 11:25:52 +0100 Subject: [Fedora-legal-list] di license Message-ID: <4B1640B0.8030006@redhat.com> Hello, is it compatible with ours licenses? Taken from http://www.gentoo.com/di/ di License Copyright 1994-2009 Brad Lanam, Walnut Creek, CA, USA This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. -- Nikola Pajkovsky .~. Base Operating Systems Brno /V\ // \\ Jabber: nikis at isgeek.info /( )\ Mobile: +420 777 895 064 ^`~'^ From dan at danny.cz Wed Dec 2 10:41:17 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 02 Dec 2009 11:41:17 +0100 Subject: [Fedora-legal-list] di license In-Reply-To: <4B1640B0.8030006@redhat.com> References: <4B1640B0.8030006@redhat.com> Message-ID: <1259750477.3761.54.camel@eagle.danny.cz> Nikola Pajkovsky p??e v St 02. 12. 2009 v 11:25 +0100: > Hello, > > is it compatible with ours licenses? > > Taken from http://www.gentoo.com/di/ > > di License > Copyright 1994-2009 Brad Lanam, Walnut Creek, CA, USA > > This software is provided 'as-is', without any express or implied > warranty. In no event will the authors be held liable for any damages > arising from the use of this software. > > Permission is granted to anyone to use this software for any purpose, > including commercial applications, and to alter it and redistribute it > freely, subject to the following restrictions: > > 1. The origin of this software must not be misrepresented; you must not > claim that you wrote the original software. If you use this software in > a product, an acknowledgment in the product documentation would be > appreciated but is not required. > > 2. Altered source versions must be plainly marked as such, and must not > be misrepresented as being the original software. > > 3. This notice may not be removed or altered from any source distribution. It's zlib license (http://www.gzip.org/zlib/zlib_license.html) and this is OK for Fedora Dan From juliusdavies at gmail.com Thu Dec 3 07:48:00 2009 From: juliusdavies at gmail.com (Julius Davies) Date: Wed, 2 Dec 2009 23:48:00 -0800 Subject: [Fedora-legal-list] 12 dynamic GPL link problems Message-ID: <598ad5b50912022348w1ebaff36pdc31c6b9898bf17e@mail.gmail.com> Hi, I think I might have found 12 problems with code that dynamically links into GPL code. These ones I'm pretty sure are a problem since AutoReqProv caused them: ---------------------------------- pilot-link -> readline pilot-link-devel -> readline device-mapper -> readline device-mapper-event -> readline lvm2 -> readline kdebase-workspace -> qedje kdebase-workspace -> qzion kdebase3 -> libsmbclient libtirpc -> libgssglue These ones I'm not so sure about, since they are Maintainer specified (not AutoReqProv): ---------------------------------- eclipse-callgraph -> systemtap ghostscript -> urw-fonts This one is AutoReqProv, but maybe gvfs's LGPL just switches into GPL, since LGPL allows that? (But wouldn't this cause a transitivity problem for others that expect gvfs to be LGPL?) ------------------------------------- gvfs -> libgudev1 More details are here (e.g. licenses, and what AutoReqProv picked): ------------------------------------- http://juliusdavies.ca/uvic/csc490-2009-fall-dmg/fedora12_lic_probs.html Two questions: 1. Am I actually identifying some real problems? 2. What does Fedora normally do to detect and avoid similar problems? -- yours, Julius Davies 250-592-2284 (Home) 250-893-4579 (Mobile) http://juliusdavies.ca/logging.html From adam at spicenitz.org Thu Dec 3 16:26:21 2009 From: adam at spicenitz.org (Adam Goode) Date: Thu, 03 Dec 2009 11:26:21 -0500 Subject: [Fedora-legal-list] JPEG 2000 Message-ID: <4B17E6AD.4030302@spicenitz.org> Hi, A year ago, the question of JPEG 2000 came up: https://www.redhat.com/archives/fedora-legal-list/2008-December/msg00007.html Was there ever any resolution to the question of JPEG 2000 in Fedora? Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Thu Dec 3 20:05:27 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 03 Dec 2009 15:05:27 -0500 Subject: [Fedora-legal-list] JPEG 2000 In-Reply-To: <4B17E6AD.4030302@spicenitz.org> References: <4B17E6AD.4030302@spicenitz.org> Message-ID: <4B181A07.2010308@redhat.com> On 12/03/2009 11:26 AM, Adam Goode wrote: > Hi, > > A year ago, the question of JPEG 2000 came up: > > https://www.redhat.com/archives/fedora-legal-list/2008-December/msg00007.html > > > Was there ever any resolution to the question of > JPEG 2000 in Fedora? This is not yet resolved, other more pressing issues temporarily bumped it down, but I reminded Red Hat Legal of this today. ~spot From tcallawa at redhat.com Thu Dec 3 20:54:32 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 03 Dec 2009 15:54:32 -0500 Subject: [Fedora-legal-list] 12 dynamic GPL link problems In-Reply-To: <598ad5b50912022348w1ebaff36pdc31c6b9898bf17e@mail.gmail.com> References: <598ad5b50912022348w1ebaff36pdc31c6b9898bf17e@mail.gmail.com> Message-ID: <4B182588.1000807@redhat.com> On 12/03/2009 02:48 AM, Julius Davies wrote: > I think I might have found 12 problems with code that dynamically > links into GPL code. First of all, thank you for your help! It is certainly not Fedora's intention to have any GPL incompatibility scenarios. I will look into each case and determine whether it is valid, and what actions to take if so. For example, replacing readline with libedit is almost always a viable solution. Here's my initial notes: > These ones I'm pretty sure are a problem since AutoReqProv caused them: > ---------------------------------- > pilot-link -> readline > pilot-link-devel -> readline > device-mapper -> readline > device-mapper-event -> readline > lvm2 -> readline Have not checked for validity, but should be resolvable using libedit. > kdebase-workspace -> qedje > kdebase-workspace -> qzion plasma/generic/scriptengines/qedjescript/ depends on qedje and qzion, notably: plasma/generic/scriptengines/qedjescript/qedje_applet.cpp (GPLv2+) plasma/generic/scriptengines/qedjescript/qedje_package.cpp (GPLv2+) They get compiled into: /usr/lib64/kde4/plasma_appletscript_qedje.so That depends on kdelibs (LGPLv2+), qt (LGPLv2 with exceptions or GPLv3 with exceptions), qzion (GPLv3+), and qedje (GPLv3+), so it should all be fine. > kdebase3 -> libsmbclient There are two files in the kdebase3 package that are dependent on libsmbclient: /usr/lib64/kde3/kio_smb.la /usr/lib64/kde3/kio_smb.so The kio_smb direct code is GPLv2+, they depend on the kdelibs which are LGPLv2 (which is GPLv2+ compatible) and libsmbclient (GPLv3+ and LGPLv2+). So, in this specific case, there is no compatibility issue. > libtirpc -> libgssglue This is a known concern, and we are currently working with Sun to resolve the issue by removing the SISSL from the three files in libtirpc. > These ones I'm not so sure about, since they are Maintainer specified > (not AutoReqProv): > ---------------------------------- > eclipse-callgraph -> systemtap eclipse-callgraph is EPL which is incompatible with systemtap (GPLv2+), but Red Hat is the copyright holder for eclipse-callgraph. I've escalated this to Red Hat Legal. > ghostscript -> urw-fonts This isn't a code dependency, but even if it was, ghostscript is GPLv3+ and urw-fonts is GPL+, so I think this may be a mistake. > > This one is AutoReqProv, but maybe gvfs's LGPL just switches into GPL, > since LGPL allows that? (But wouldn't this cause a transitivity > problem for others that expect gvfs to be LGPL?) > ------------------------------------- > gvfs -> libgudev1 The FSF permits the LGPL -> GPL, and it doesn't really cause a transitivity issue. There is a theoretical issue there, but in practice, it is not a concern. > Two questions: > > 1. Am I actually identifying some real problems? I think so. Even though it is more work for me, I'd rather know about them like this than find out via a lawsuit. > 2. What does Fedora normally do to detect and avoid similar problems? We look during package import, but we could definitely stand to improve our auditing techniques in this area. I'm very interested in your code efforts, and possibly implementing them in Fedora directly as part of an automated audit effort. Thanks again, ~spot From juliusdavies at gmail.com Fri Dec 4 04:13:11 2009 From: juliusdavies at gmail.com (Julius Davies) Date: Thu, 3 Dec 2009 20:13:11 -0800 Subject: [Fedora-legal-list] 12 dynamic GPL link problems In-Reply-To: <4B182588.1000807@redhat.com> References: <598ad5b50912022348w1ebaff36pdc31c6b9898bf17e@mail.gmail.com> <4B182588.1000807@redhat.com> Message-ID: <598ad5b50912032013i6cffa07bve89fadc334ed702d@mail.gmail.com> Thanks for your reply, Tom. That's fascinating how these resolved! ---------------------------------------- kdebase-workspace -> qedje kdebase-workspace -> qzion kdebase3 -> libsmbclient ---------------------------------------- As for: * -> readline ---------------------------------------- Since all of the Readline issues are essentially this problem: (gplv2) -> (gplv3+), I'm wondering if maybe Fedora-12 upgraded Readline a little too soon, and should have held on to an older GPLv2+ version of Readline a little longer. This wouldn't have helped with the PHP issue, but certainly takes care of these. As for: eclipse-callgraph -> systemtap ---------------------------------------- Probably Eclipse could insert an LGPL "eclipse-callgraph-systemtap" module inbetween those two to play it safe? Or maybe Eclipse calls systemtap via exec(), so it's okay? In this case I didn't spend that much time trying to figure out if it truly is a dynamic linking problem. I was also getting a little bit stuck on the fact systemtap is a script interpreter, so do the scripts need to be GPLv2+? (I suspect not, otherwise all bash scripts would also have to be GPLv3+!). Sorry, still a bit of a newb on these issues. This page you wrote has been *invaluable* ! http://fedoraproject.org/wiki/Licensing As for: ghostscript -> urw-fonts ---------------------------------------- I was considering the package license "as a whole" and ghostscript gets tainted by that Adobe "no modifications" rider. So I presumed the "no modifications" rider would kill ghostscript's ability to use "urw-fonts". But based on the way the kde problems above resolved, I realize the logic for license compliance is not so simple! Thank you very very very much! I know, I know, mailing lists hate to help undergrads with their homework. ;-) But I think my professor might be subscribed to the list, so he'll adjust my mark accordingly. :-p By the way, the 12 license problems I sent to the list are not just a random sample. They are the only 12 I could find in all of Fedora 12. Maybe my techniques will improve and I will find more, but for now this is all I got. yours, Julius On Thu, Dec 3, 2009 at 12:54 PM, Tom "spot" Callaway wrote: > On 12/03/2009 02:48 AM, Julius Davies wrote: >> I think I might have found 12 problems with code that dynamically >> links into GPL code. > > First of all, thank you for your help! It is certainly not Fedora's > intention to have any GPL incompatibility scenarios. > > I will look into each case and determine whether it is valid, and what > actions to take if so. > > For example, replacing readline with libedit is almost always a viable > solution. > > Here's my initial notes: > >> These ones I'm pretty sure are a problem since AutoReqProv caused them: >> ---------------------------------- >> pilot-link -> readline >> pilot-link-devel -> readline >> device-mapper -> readline >> device-mapper-event -> readline >> lvm2 -> readline > > Have not checked for validity, but should be resolvable using libedit. > >> kdebase-workspace -> qedje >> kdebase-workspace -> qzion > > plasma/generic/scriptengines/qedjescript/ depends on qedje and qzion, > notably: > > plasma/generic/scriptengines/qedjescript/qedje_applet.cpp (GPLv2+) > plasma/generic/scriptengines/qedjescript/qedje_package.cpp (GPLv2+) > > They get compiled into: > /usr/lib64/kde4/plasma_appletscript_qedje.so > > That depends on kdelibs (LGPLv2+), qt (LGPLv2 with exceptions or GPLv3 > with exceptions), qzion (GPLv3+), and qedje (GPLv3+), so it should all > be fine. > >> kdebase3 -> libsmbclient > > There are two files in the kdebase3 package that are dependent on > libsmbclient: > > /usr/lib64/kde3/kio_smb.la > /usr/lib64/kde3/kio_smb.so > > The kio_smb direct code is GPLv2+, they depend on the kdelibs which are > LGPLv2 (which is GPLv2+ compatible) and libsmbclient (GPLv3+ and LGPLv2+). > > So, in this specific case, there is no compatibility issue. > >> libtirpc -> libgssglue > > This is a known concern, and we are currently working with Sun to > resolve the issue by removing the SISSL from the three files in libtirpc. > >> These ones I'm not so sure about, since they are Maintainer specified >> (not AutoReqProv): >> ---------------------------------- >> eclipse-callgraph -> systemtap > > eclipse-callgraph is EPL which is incompatible with systemtap (GPLv2+), > but Red Hat is the copyright holder for eclipse-callgraph. I've > escalated this to Red Hat Legal. > >> ghostscript -> urw-fonts > > This isn't a code dependency, but even if it was, ghostscript is GPLv3+ > and urw-fonts is GPL+, so I think this may be a mistake. > >> >> This one is AutoReqProv, but maybe gvfs's LGPL just switches into GPL, >> since LGPL allows that? ?(But wouldn't this cause a transitivity >> problem for others that expect gvfs to be LGPL?) >> ------------------------------------- >> gvfs -> libgudev1 > > The FSF permits the LGPL -> GPL, and it doesn't really cause a > transitivity issue. There is a theoretical issue there, but in practice, > it is not a concern. > >> Two questions: >> >> 1. ?Am I actually identifying some real problems? > > I think so. Even though it is more work for me, I'd rather know about > them like this than find out via a lawsuit. > >> 2. ?What does Fedora normally do to detect and avoid similar problems? > > We look during package import, but we could definitely stand to improve > our auditing techniques in this area. I'm very interested in your code > efforts, and possibly implementing them in Fedora directly as part of an > automated audit effort. > > Thanks again, > > ~spot > > > -- yours, Julius Davies 250-592-2284 (Home) 250-893-4579 (Mobile) http://juliusdavies.ca/logging.html From hughsient at gmail.com Fri Dec 4 10:24:48 2009 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 4 Dec 2009 10:24:48 +0000 Subject: [Fedora-legal-list] Abobe RGB ICC profiles in Fedora In-Reply-To: <15e53e180912040220m114d4699u8639ae28acdc29f3@mail.gmail.com> References: <15e53e180912040220m114d4699u8639ae28acdc29f3@mail.gmail.com> Message-ID: <15e53e180912040224y338c8b17q45a613c76babbcf0@mail.gmail.com> I have a legal question regarding distributing Abobe RGB ICC profiles in Fedora. I am soon to package gnome-color-manager for Fedora (GPLv2+), but it requires additional data to be really useful. To actually use a colour managed workflow, you need a set of standard profiles. Profiles are just data files that define a "working set" of color. Quite a few people will already be using (or want to use) Adobe RGB. Here's the link http://www.adobe.com/support/downloads/detail.jsp?ftpID=3682 to the Adobe distributor package with details. Ideally I want to include them in a separate package, maybe called shared-color-profiles (or shared-color-profiles-adobe if you think one package [subpackage?] per different licence is better). If you download the archive, there's also another licence agreement inside, which may be easier to read. Adobe really want people to ship the files (hence the permissive licensing terms) and it would be a shame to have to punt this to other repos like rpmfusion. Can anyone give me any advice on whether the Adobe licence agreement would be valid for profiles shipped in Fedora? If not, would I be allowed to link to the adobe webpage in the GNOME Color Manager help documentation? Thanks. Richard Hughes. From hughsient at gmail.com Fri Dec 4 10:28:43 2009 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 4 Dec 2009 10:28:43 +0000 Subject: [Fedora-legal-list] Re: sRGB ICC profiles in Fedora Message-ID: <15e53e180912040228p10badbd3kfde1772a78c2c9c8@mail.gmail.com> 2009/12/4 Richard Hughes : > I have a legal question regarding distributing Abobe RGB ICC profiles in Fedora. Another email about profiles (sorry!), just a different licence this time. I want to ship the official ICC sRGB profiles available here in Fedora: http://www.color.org/srgbprofiles.xalter This states: Terms of use: To anyone who acknowledges that the file "sRGB_v4_ICC_preference.icc" is provided "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTY, permission to use, copy and distribute this file for any purpose is hereby granted without fee, provided that the file is not changed including the ICC copyright notice tag, and that the name of ICC shall not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. ICC makes no representations about the suitability of this software for any purpose. Suitable for Fedora or one for rpmfusion? Thanks. Richard. From hughsient at gmail.com Fri Dec 4 16:01:17 2009 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 4 Dec 2009 16:01:17 +0000 Subject: [Fedora-legal-list] Re: Abobe RGB ICC profiles in Fedora In-Reply-To: <15e53e180912040220m114d4699u8639ae28acdc29f3@mail.gmail.com> References: <15e53e180912040220m114d4699u8639ae28acdc29f3@mail.gmail.com> Message-ID: <15e53e180912040801i37168849m79a54f97fb4634f@mail.gmail.com> 2009/12/4 Richard Hughes : > Can anyone give me any advice on whether the Adobe licence agreement > would be valid for profiles shipped in Fedora? This may be of interest: http://lists.freedesktop.org/archives/openicc/2005q4/000668.html It's an invitation from the Adobe guys to the OpenICC mailing list asking people to package their stuff. Some of the legal questions are answered there too. Richard. From alekcejk at googlemail.com Fri Dec 4 18:38:57 2009 From: alekcejk at googlemail.com (alekcejk at googlemail.com) Date: Fri, 4 Dec 2009 20:38:57 +0200 Subject: [Fedora-legal-list] Including of MARS code in cryptopp package Message-ID: <200912042038.57879.alekcejk@googlemail.com> Hi All, There is IBM implementation of MARS code in cryptopp 5.6.0 an it was removed from Fedora cryptopp package. But SVN 479 version of cryptopp contains mars.cpp that was written and placed in the public domain by Wei Dai. https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5/mars.cpp Can we include this MARS code in Fedora cryptopp package? Alexey Kurov From saulgoode at flashingtwelve.brickfilms.com Sat Dec 5 18:31:28 2009 From: saulgoode at flashingtwelve.brickfilms.com (saulgoode at flashingtwelve.brickfilms.com) Date: Sat, 05 Dec 2009 13:31:28 -0500 Subject: [Fedora-legal-list] Fedora and MS-PL (Dynamic Language Runtime) Message-ID: <20091205133128.6nsld5q9q8ogsgkk@flashingtwelve.brickfilms.com> I apologize if resurrecting such an old thread is considered poor etiquette for this list; however, it seems that the discussion in this thread served as a predicate for the MS-PL being deemed acceptable for inclusion in Fedora[1], and I wish to raise a question about that decision[2]. While the discussion in this thread effectively addressed the incompatibility between the Microsoft Public License and GNU's General Public license, it focused upon terms of the GPL and whether they might preclude inclusion of MS-PLed code in Fedora. I feel it is far more incumbent to examine the terms and conditions of the MS-PL and consider whether those terms can be satisfied should both MS-PLed code and GPLed code be provided together on a CD/DVD or in a corresponding ISO file. In brief, my concern lies with the fact that there is no explicit exception included in the MS-PL for "collective works" or "compilations" as defined under U.S. copyright law[3]; instead the MS-PL is based[4] upon the U.S. Copyright Act's definition of "derivative works"[5] and a license-explicit definition of a "contribution"[6], and it claims for its applicable scope all derivative works of the contribution. This is problematic for a Fedora distribution because, though Fedora should rightly fit the definition for a "compilation", it may still qualify as a "derivative work" as those terms are defined in the U.S. Copyright Act. The two classifications are not of necessity mutually exclusive; as stated in the congressional footnotes to the Copyright Act[7]: "Between them the terms 'compilations' and 'derivative works' which are defined in section 101, comprehend every copyrightable work that employs preexisting material or data of any kind. THERE IS NECESSARILY SOME OVERLAPPING BETWEEN THE TWO, but they basically represent different concepts." (emphasis mine) Further coverage of the legal uncertainty at to whether a compilation (or even collective work) can be considered a derivative work can be found in the Copyright Office's "Copyright Registration for Derivative Works" circular[8 (PDF)], and in the first chapter[9] of Lee A. Hollaar's "Legal Protection of Digital Information". Though I am an engineer (not a lawyer), it seems the distinction being made in the Copyright Act phraseology is owing to the legislature's desire to clarify the durations and protections of copyright obtained in the constituent parts of a collection or compilation, and not a presumption of the law to interfere with the exclusive rights of the copyright holder to decide the terms and scope under which his work might be licensed. In other words, I find it entirely conceivable that a court would find that it is within an author's rights to prohibit distribution of his work in collections/compilations containing other works which the author may find objectionable. While my interpretation is by no means conclusive (and certainly not authoritative), it should be noted that it is this legal uncertainty which has prompted other reciprocal licenses to provide explicit exceptions for "collective works". This is addressed employing the term "mere aggregation" in Section 3 of the GPLv2[10], and the term "aggregate" in Section 5 of the GPLv3[11] and in Section 7 of the GNU Free Document License[12]. It is addressed in the Creative Commons Share-Alike by providing a license-specific definition of a "collection" and exempting such collections from reciprocity terms[13]. I won't speculate as to whether it was the intent of the authors of the Microsoft Public License to consider "mere aggregation" to be excluded from the scope of their reciprocal terms and conditions[14], but regardless of their intent it seems that lack of an exception being explicitly provided within the license itself may potentially lead to a court decision that inclusion of both MS-PLed and GPLed software within a Fedora distribution constitutes copyright infringement -- not because the terms of the GPL weren't met, but that those of the MS-PL were not met. Any clarification on this issue would be appreciated. Regards. ---------------------------------- [1] http://fedoraproject.org/wiki/Licensing#Software_License_List MS-PL listed under "Software Licenses that are OK for Fedora" [2] https://www.redhat.com/archives/fedora-legal-list/2009-August/msg00017.html "The MS Public License is acceptable for Fedora, Free but GPL incompatible. I'm adding it to the table now." -- Tom Calloway [3] http://www.law.cornell.edu/uscode/usc_sec_17_00000101----000-.html "A 'collective work' is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole. "A 'compilation' is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term 'compilation' includes collective works." -- USC Title 17 Section 101 [4] http://www.microsoft.com/opensource/licenses.mspx#Ms-PL "The terms 'reproduce', 'reproduction', 'derivative works', and 'distribution' have the same meaning here as under U.S. copyright law." -- MS-PL: Definitions [5] http://www.law.cornell.edu/uscode/usc_sec_17_00000101----000-.html "A 'derivative work' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'." -- USC Title 17 Section 101 [6] http://www.microsoft.com/opensource/licenses.mspx#Ms-PL "A 'contribution' is the original software, or any additions or changes to the software." -- MS-PL: Definitions [7] http://digital-law-online.info/lpdi1.0/treatise6.html "Between them the terms 'compilations' and 'derivative works' which are defined in section 101, comprehend every copyrightable work that employs preexisting material or data of any kind. There is necessarily some overlapping between the two, but they basically represent different concepts. A ?compilation? results from a process of selecting, bringing together, organizing, and arranging previously existing material of all kinds, regardless of whether the individual items in the material have been or ever could have been subject to copyright. A ?derivative work,? on the other hand, requires a process of recasting, transforming, or adapting ?one or more preexisting works?; the ?preexisting work? must come within the general subject matter of copyright set forth in section 102, regardless of whether it is or was ever copyrighted." FN31: H.R. Rep. No. 94-1476 [8] http://www.copyright.gov/circs/circ14.html [9] http://digital-law-online.info/lpdi1.0/treatise6.html [10] http://www.gnu.org/licenses/old-licenses/gpl-2.0.html "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." -- GPLv2 [11] http://www.gnu.org/licenses/gpl.html "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate." -- GPLv3 [12] http://www.gnu.org/licenses/fdl.html "When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document." -- GFDL [13] http://creativecommons.org/licenses/by-sa/3.0/legalcode "A work that constitutes a Collection will not be considered an Adaptation (as defined below) for the purposes of this License." -- CC-SA [14] http://www.microsoft.com/opensource/licenses.mspx#Ms-PL "If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution. If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license." -- MS-PL Section 3d) From rfontana at redhat.com Sat Dec 5 20:05:15 2009 From: rfontana at redhat.com (Richard Fontana) Date: Sat, 5 Dec 2009 15:05:15 -0500 Subject: [Fedora-legal-list] Fedora and MS-PL (Dynamic Language Runtime) In-Reply-To: <20091205133128.6nsld5q9q8ogsgkk@flashingtwelve.brickfilms.com> References: <20091205133128.6nsld5q9q8ogsgkk@flashingtwelve.brickfilms.com> Message-ID: <20091205150515.0b7797b2@calliope> On Sat, 05 Dec 2009 13:31:28 -0500 saulgoode at flashingtwelve.brickfilms.com wrote: > I won't speculate as to whether it was the intent of the authors of > the Microsoft Public License to consider "mere aggregation" to be > excluded from the scope of their reciprocal terms and > conditions[14], but regardless of their intent it seems that lack of > an exception being explicitly provided within the license itself may > potentially lead to a court decision that inclusion of both MS-PLed > and GPLed software within a Fedora distribution constitutes > copyright infringement -- not because the terms of the GPL weren't > met, but that those of the MS-PL were not met. I think you're arguing that we should consider the possibility that the MS-PL is what I'll call a 'hyper-strong' copyleft license, with a copyleft scope broader than that traditionally assumed by consensus of GPL-licensing communities to apply to the GPL, extending to combinations that would not have any copyleft implications in a GPL context, if only because of the latter's 'mere aggregation' clause.[1] The particular concern you have is that the MS-PL intended copyleft scope could extend to whole compilations in the copyright law sense, as for example all the code in a Fedora .iso that happens to contain one package licensed under MS-PL. There are a number of reasons, largely involving common sense and cultural intuition, why I think it is *extremely* unlikely that such an interpretation was intended by Microsoft (or other licensors using the MS-PL or would be adopted by such licensors or by a court construing this license. The likelihood is so remote that I think we can safely ignore it. However, if the issue continues to concern you, you may wish to contact Microsoft to get clarification from the horse's mouth. (Michele Herman at Microsoft's outside counsel firm Woodcock Washburn might be the best contact.) - Richard [1]Although I think the historical evidence shows that Richard Stallman added the mere aggregation clause to proto-versions of the GPL so he would stop getting questions about whether it was okay to distribute GNU software and unrelated proprietary software on the same tape, an issue he seems to have thought should have been obvious. -- Richard E. Fontana Open Source Licensing and Patent Counsel Red Hat, Inc. From tcallawa at redhat.com Sat Dec 5 22:00:49 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 05 Dec 2009 17:00:49 -0500 Subject: [Fedora-legal-list] Re: sRGB ICC profiles in Fedora In-Reply-To: <15e53e180912040228p10badbd3kfde1772a78c2c9c8@mail.gmail.com> References: <15e53e180912040228p10badbd3kfde1772a78c2c9c8@mail.gmail.com> Message-ID: <4B1AD811.8020006@redhat.com> On 12/04/2009 05:28 AM, Richard Hughes wrote: > 2009/12/4 Richard Hughes : >> I have a legal question regarding distributing Abobe RGB ICC profiles in Fedora. > > Another email about profiles (sorry!), just a different licence this time. > > I want to ship the official ICC sRGB profiles available here in > Fedora: http://www.color.org/srgbprofiles.xalter > > This states: > > Terms of use: > To anyone who acknowledges that the file "sRGB_v4_ICC_preference.icc" > is provided "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTY, permission to > use, copy and distribute this file for any purpose is hereby granted > without fee, provided that the file is not changed including the ICC > copyright notice tag, and that the name of ICC shall not be used in > advertising or publicity pertaining to distribution of the software > without specific, written prior permission. ICC makes no > representations about the suitability of this software for any > purpose. > > Suitable for Fedora or one for rpmfusion? Thanks. rpmfusion. It refers to itself as software, but does not grant permission to modify. Not a Free license. ~spot From tcallawa at redhat.com Sat Dec 5 22:06:52 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 05 Dec 2009 17:06:52 -0500 Subject: [Fedora-legal-list] Including of MARS code in cryptopp package In-Reply-To: <200912042038.57879.alekcejk@googlemail.com> References: <200912042038.57879.alekcejk@googlemail.com> Message-ID: <4B1AD97C.5010006@redhat.com> On 12/04/2009 01:38 PM, alekcejk at googlemail.com wrote: > Hi All, > > There is IBM implementation of MARS code in cryptopp 5.6.0 an it was removed > from Fedora cryptopp package. > > But SVN 479 version of cryptopp contains mars.cpp that was written and placed > in the public domain by Wei Dai. > > https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5/mars.cpp > > Can we include this MARS code in Fedora cryptopp package? Well, it depends on where Wei Dai is a citizen. There are many places where it is not possible to put code into the Public Domain. I've sent him an email asking for clarification, but until we hear back, we should hold off on including this code. ~spot From adam at spicenitz.org Sun Dec 6 00:50:10 2009 From: adam at spicenitz.org (Adam Goode) Date: Sat, 05 Dec 2009 19:50:10 -0500 Subject: [Fedora-legal-list] Re: sRGB ICC profiles in Fedora In-Reply-To: <4B1AD811.8020006@redhat.com> References: <15e53e180912040228p10badbd3kfde1772a78c2c9c8@mail.gmail.com> <4B1AD811.8020006@redhat.com> Message-ID: <4B1AFFC2.2070603@spicenitz.org> On 12/05/2009 05:00 PM, Tom "spot" Callaway wrote: > On 12/04/2009 05:28 AM, Richard Hughes wrote: >> 2009/12/4 Richard Hughes : >>> I have a legal question regarding distributing Abobe RGB ICC profiles in Fedora. >> >> Another email about profiles (sorry!), just a different licence this time. >> >> I want to ship the official ICC sRGB profiles available here in >> Fedora: http://www.color.org/srgbprofiles.xalter >> >> >> Suitable for Fedora or one for rpmfusion? Thanks. > > rpmfusion. It refers to itself as software, but does not grant > permission to modify. Not a Free license. Do you think the ICC would be open to adjusting their license? Can't hurt to try... Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Sun Dec 6 15:08:35 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 06 Dec 2009 10:08:35 -0500 Subject: [Fedora-legal-list] Re: sRGB ICC profiles in Fedora In-Reply-To: <4B1AFFC2.2070603@spicenitz.org> References: <15e53e180912040228p10badbd3kfde1772a78c2c9c8@mail.gmail.com> <4B1AD811.8020006@redhat.com> <4B1AFFC2.2070603@spicenitz.org> Message-ID: <4B1BC8F3.6080904@redhat.com> On 12/05/2009 07:50 PM, Adam Goode wrote: > On 12/05/2009 05:00 PM, Tom "spot" Callaway wrote: >> On 12/04/2009 05:28 AM, Richard Hughes wrote: >>> 2009/12/4 Richard Hughes : >>>> I have a legal question regarding distributing Abobe RGB ICC profiles in Fedora. >>> >>> Another email about profiles (sorry!), just a different licence this time. >>> >>> I want to ship the official ICC sRGB profiles available here in >>> Fedora: http://www.color.org/srgbprofiles.xalter >>> >>> >>> Suitable for Fedora or one for rpmfusion? Thanks. >> >> rpmfusion. It refers to itself as software, but does not grant >> permission to modify. Not a Free license. > > Do you think the ICC would be open to adjusting their license? Can't > hurt to try... I have no idea, but I agree, it would not hurt to try. Richard, if you want me to send an email (and you can find the appropriate person), I would be willing to try, or you can try on your own. ~spot From tcallawa at redhat.com Sun Dec 6 15:09:06 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 06 Dec 2009 10:09:06 -0500 Subject: [Fedora-legal-list] Including of MARS code in cryptopp package In-Reply-To: <4B1AD97C.5010006@redhat.com> References: <200912042038.57879.alekcejk@googlemail.com> <4B1AD97C.5010006@redhat.com> Message-ID: <4B1BC912.9050002@redhat.com> On 12/05/2009 05:06 PM, Tom "spot" Callaway wrote: > On 12/04/2009 01:38 PM, alekcejk at googlemail.com wrote: >> Hi All, >> >> There is IBM implementation of MARS code in cryptopp 5.6.0 an it was removed >> from Fedora cryptopp package. >> >> But SVN 479 version of cryptopp contains mars.cpp that was written and placed >> in the public domain by Wei Dai. >> >> https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5/mars.cpp >> >> Can we include this MARS code in Fedora cryptopp package? > > Well, it depends on where Wei Dai is a citizen. There are many places > where it is not possible to put code into the Public Domain. I've sent > him an email asking for clarification, but until we hear back, we should > hold off on including this code. He's a US citizen, so this code is fine for Fedora. ~spot From david at gnsa.us Sun Dec 6 15:43:45 2009 From: david at gnsa.us (David Nalley) Date: Sun, 6 Dec 2009 10:43:45 -0500 Subject: [Fedora-legal-list] Good, not Evil in jsmin-php Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An update to zikula bundles jsmin-php (http://code.google.com/p/jsmin-php/) I started to work on packaging this, and struck upon this potential licensing issue. Google lists this as MIT licensed, however the text of the license contains this line in addition to the MIT license: * The Software shall be used for Good, not Evil. That strikes me as non-free, but figured I would ask. Thoughts? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10) iEYEARECAAYFAksb0YEACgkQkZOYj+cNI1dVcQCeMMmitiEupLk41lzU6qDoFtdz pecAmgKVIQ+kfIFmP16CZ+TY1VKGdl0g =lWI2 -----END PGP SIGNATURE----- From jonstanley at gmail.com Sun Dec 6 15:52:29 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 6 Dec 2009 10:52:29 -0500 Subject: [Fedora-legal-list] Good, not Evil in jsmin-php In-Reply-To: References: Message-ID: On Sun, Dec 6, 2009 at 10:43 AM, David Nalley wrote: > > ?* The Software shall be used for Good, not Evil. > > That strikes me as non-free, but figured I would ask. That is non-free as a "field of use" restriction. Can you convince upstream to drop that? From alekcejk at googlemail.com Sun Dec 6 15:51:25 2009 From: alekcejk at googlemail.com (alekcejk at googlemail.com) Date: Sun, 6 Dec 2009 17:51:25 +0200 Subject: [Fedora-legal-list] Including of MARS code in cryptopp package In-Reply-To: <4B1BC912.9050002@redhat.com> References: <200912042038.57879.alekcejk@googlemail.com> <4B1AD97C.5010006@redhat.com> <4B1BC912.9050002@redhat.com> Message-ID: <200912061751.25301.alekcejk@googlemail.com> > On 12/05/2009 05:06 PM, Tom "spot" Callaway wrote: > > On 12/04/2009 01:38 PM, alekcejk at googlemail.com wrote: > >> Hi All, > >> > >> There is IBM implementation of MARS code in cryptopp 5.6.0 an it was > >> removed from Fedora cryptopp package. > >> > >> But SVN 479 version of cryptopp contains mars.cpp that was written and > >> placed in the public domain by Wei Dai. > >> > >> https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5/mars.cpp > >> > >> Can we include this MARS code in Fedora cryptopp package? > > > > Well, it depends on where Wei Dai is a citizen. There are many places > > where it is not possible to put code into the Public Domain. I've sent > > him an email asking for clarification, but until we hear back, we should > > hold off on including this code. > > He's a US citizen, so this code is fine for Fedora. > > ~spot > Thank you, spot. I will build cryptopp svn 479 without removing MARS code http://koji.fedoraproject.org/koji/buildinfo?buildID=143094 for Fedora 11,12 and rawhide when this issue will be resolved https://bugzilla.redhat.com/show_bug.cgi?id=544358 Alexey From bochecha at fedoraproject.org Sun Dec 6 16:00:16 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Sun, 6 Dec 2009 15:00:16 -0100 Subject: [Fedora-legal-list] Good, not Evil in jsmin-php In-Reply-To: References: Message-ID: <2d319b780912060800h75cfc90ch6e00c2267e8edcff@mail.gmail.com> Hi, On Sun, Dec 6, 2009 at 14:43, David Nalley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > An update to zikula bundles jsmin-php (http://code.google.com/p/jsmin-php/) > I started to work on packaging this, and struck upon this potential > licensing issue. > Google lists this as MIT licensed, however the text of the license > contains this line in addition to the MIT license: > > ?* The Software shall be used for Good, not Evil. > > That strikes me as non-free, but figured I would ask. > > Thoughts? JSMin is not free [1] I asked here about a Python implementation of JSMin [2] and got the same answer [3] and thus had to remove it from the OpenLayers source archive. Best regards, [1] https://bugzilla.redhat.com/show_bug.cgi?id=455507 [2] https://www.redhat.com/archives/fedora-legal-list/2009-August/msg00000.html [3] https://www.redhat.com/archives/fedora-legal-list/2009-September/msg00014.html ---------- Mathieu Bridon (bochecha) From hughsient at gmail.com Sun Dec 6 20:37:29 2009 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 6 Dec 2009 20:37:29 +0000 Subject: [Fedora-legal-list] Re: sRGB ICC profiles in Fedora In-Reply-To: <4B1BC8F3.6080904@redhat.com> References: <15e53e180912040228p10badbd3kfde1772a78c2c9c8@mail.gmail.com> <4B1AD811.8020006@redhat.com> <4B1AFFC2.2070603@spicenitz.org> <4B1BC8F3.6080904@redhat.com> Message-ID: <15e53e180912061237i1828993cg123c938f1b8b1319@mail.gmail.com> 2009/12/6 Tom "spot" Callaway : >> Do you think the ICC would be open to adjusting their license? Can't >> hurt to try... I would imagine they would be very receptive to the idea. > I have no idea, but I agree, it would not hurt to try. Richard, if you > want me to send an email (and you can find the appropriate person), I > would be willing to try, or you can try on your own. The only contact information I can find is askphil at colourspace.demon.co.uk -- If it's okay with you I would prefer the email came from you guys (as fedora-legal) as I would not be sure what to exactly request or how to argue the case for changes required. Thanks, Richard. From saulgoode at flashingtwelve.brickfilms.com Sun Dec 6 21:22:52 2009 From: saulgoode at flashingtwelve.brickfilms.com (saulgoode at flashingtwelve.brickfilms.com) Date: Sun, 06 Dec 2009 16:22:52 -0500 Subject: [Fedora-legal-list] Fedora and MS-PL (Dynamic Language Runtime) In-Reply-To: <20091205150515.0b7797b2@calliope> References: <20091205133128.6nsld5q9q8ogsgkk@flashingtwelve.brickfilms.com> <20091205150515.0b7797b2@calliope> Message-ID: <20091206162252.v9wxvp29ic8k48gg@flashingtwelve.brickfilms.com> Thank you for the rapid response and for concisely representing my concern. I won't belabor your decision but I will admit that I am bit more skeptical about associating "common sense" with some of the rulings and dicta of U.S. copyright law. :) I also thank you for the suggestion that I contact Michele Herman to discover Microsoft's understanding of the scope of their license; though I would consider that more in the nature of philosophical inquiry as it would seem the more legitimate concern would target the intent (or perhaps even the degree of caprice) of the copyright holder of any MS-PLed code in question. Regards. P.S. The link provided in reference #8 of my post was incorrect and should have been: http://www.copyright.gov/circs/circ14.pdf If that does not work then the appropriate PDF can be found by visiting http://www.copyright.gov/circs . Quoting Richard Fontana : > On Sat, 05 Dec 2009 13:31:28 -0500 > saulgoode at flashingtwelve.brickfilms.com wrote: > >> I won't speculate as to whether it was the intent of the authors of >> the Microsoft Public License to consider "mere aggregation" to be >> excluded from the scope of their reciprocal terms and >> conditions[14], but regardless of their intent it seems that lack of >> an exception being explicitly provided within the license itself may >> potentially lead to a court decision that inclusion of both MS-PLed >> and GPLed software within a Fedora distribution constitutes >> copyright infringement -- not because the terms of the GPL weren't >> met, but that those of the MS-PL were not met. > > I think you're arguing that we should consider the possibility that the > MS-PL is what I'll call a 'hyper-strong' copyleft license, with a > copyleft scope broader than that traditionally assumed by consensus of > GPL-licensing communities to apply to the GPL, extending to > combinations that would not have any copyleft implications in a GPL > context, if only because of the latter's 'mere aggregation' clause.[1] > The particular concern you have is that the MS-PL intended copyleft > scope could extend to whole compilations in the copyright law sense, as > for example all the code in a Fedora .iso that happens to contain one > package licensed under MS-PL. > > There are a number of reasons, largely involving common sense and > cultural intuition, why I think it is *extremely* unlikely that such an > interpretation was intended by Microsoft (or other licensors using the > MS-PL or would be adopted by such licensors or by a court construing > this license. The likelihood is so remote that I think we can safely > ignore it. However, if the issue continues to concern you, you may wish > to contact Microsoft to get clarification from the horse's mouth. > (Michele Herman at Microsoft's outside counsel firm Woodcock Washburn > might be the best contact.) > > - Richard > > [1]Although I think the historical evidence shows that Richard Stallman > added the mere aggregation clause to proto-versions of the GPL so he > would stop getting questions about whether it was okay to distribute > GNU software and unrelated proprietary software on the same tape, an > issue he seems to have thought should have been obvious. > > -- > Richard E. Fontana > Open Source Licensing and Patent Counsel > Red Hat, Inc. > From cjac at colliertech.org Sun Dec 6 23:32:36 2009 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Sun, 06 Dec 2009 15:32:36 -0800 Subject: [Fedora-legal-list] Fedora and MS-PL (Dynamic Language Runtime) In-Reply-To: <20091205133128.6nsld5q9q8ogsgkk@flashingtwelve.brickfilms.com> References: <20091205133128.6nsld5q9q8ogsgkk@flashingtwelve.brickfilms.com> Message-ID: <1260142356.4545.13.camel@calcifer> On Sat, 2009-12-05 at 13:31 -0500, saulgoode at flashingtwelve.brickfilms.com wrote: > I apologize if resurrecting such an old thread is considered poor > etiquette for this list; however, it seems that the discussion in this > thread served as a predicate for the MS-PL being deemed acceptable for > inclusion in Fedora[1], and I wish to raise a question about that > decision[2]. I didn't know that. I'm glad it has had such an effect. > While the discussion in this thread effectively addressed the > incompatibility between the Microsoft Public License and GNU's General > Public license, it focused upon terms of the GPL and whether they > might preclude inclusion of MS-PLed code in Fedora. I feel it is far > more incumbent to examine the terms and conditions of the MS-PL and > consider whether those terms can be satisfied should both MS-PLed code > and GPLed code be provided together on a CD/DVD or in a corresponding > ISO file. I'm not certain how they are mutually exclusive aside from where inter-linking within the same application is concerned... > In brief, my concern lies with the fact that there is no explicit > exception included in the MS-PL for "collective works" or > "compilations" as defined under U.S. copyright law[3]; instead the > MS-PL is based[4] upon the U.S. Copyright Act's definition of > "derivative works"[5] and a license-explicit definition of a > "contribution"[6], and it claims for its applicable scope all > derivative works of the contribution. I still do not see how this applies to applications which do not link between one another, unless you are implying that an .iso file is not a collection of separate works, but is instead a work in itself. If this is the case, then MS-PL and GPL are the least of our problems. We run into issues with OpenSSL licenses, LGPL vs GPL, etc. I think the fact that this has not been a problem implies that an .iso is not considered a single work, but a collection. > This is problematic for a Fedora distribution because, though Fedora > should rightly fit the definition for a "compilation", it may still > qualify as a "derivative work" as those terms are defined in the U.S. > Copyright Act. The two classifications are not of necessity mutually > exclusive; as stated in the congressional footnotes to the Copyright > Act[7]: > > "Between them the terms 'compilations' and 'derivative works' > which are defined in section 101, comprehend every copyrightable > work that employs preexisting material or data of any kind. > THERE IS NECESSARILY SOME OVERLAPPING BETWEEN THE TWO, but they > basically represent different concepts." (emphasis mine) > > Further coverage of the legal uncertainty at to whether a compilation > (or even collective work) can be considered a derivative work can be > found in the Copyright Office's "Copyright Registration for Derivative > Works" circular[8 (PDF)], and in the first chapter[9] of Lee A. > Hollaar's "Legal Protection of Digital Information". > > Though I am an engineer (not a lawyer), it seems the distinction being > made in the Copyright Act phraseology is owing to the legislature's > desire to clarify the durations and protections of copyright obtained > in the constituent parts of a collection or compilation, and not a > presumption of the law to interfere with the exclusive rights of the > copyright holder to decide the terms and scope under which his work > might be licensed. In other words, I find it entirely conceivable that > a court would find that it is within an author's rights to prohibit > distribution of his work in collections/compilations containing other > works which the author may find objectionable. As I said above, if this is the case, we'd better stop shipping software collections on iso files ;) > While my interpretation is by no means conclusive (and certainly not > authoritative), it should be noted that it is this legal uncertainty > which has prompted other reciprocal licenses to provide explicit > exceptions for "collective works". This is addressed employing the > term "mere aggregation" in Section 3 of the GPLv2[10], and the term > "aggregate" in Section 5 of the GPLv3[11] and in Section 7 of the GNU > Free Document License[12]. It is addressed in the Creative Commons > Share-Alike by providing a license-specific definition of a > "collection" and exempting such collections from reciprocity terms[13]. > > I won't speculate as to whether it was the intent of the authors of > the Microsoft Public License to consider "mere aggregation" to be > excluded from the scope of their reciprocal terms and conditions[14], > but regardless of their intent it seems that lack of an exception > being explicitly provided within the license itself may potentially > lead to a court decision that inclusion of both MS-PLed and GPLed > software within a Fedora distribution constitutes copyright > infringement -- not because the terms of the GPL weren't met, but that > those of the MS-PL were not met. > > Any clarification on this issue would be appreciated. > > Regards. > > > > ---------------------------------- > [1] http://fedoraproject.org/wiki/Licensing#Software_License_List > MS-PL listed under "Software Licenses that are OK for Fedora" > > [2] > https://www.redhat.com/archives/fedora-legal-list/2009-August/msg00017.html > "The MS Public License is acceptable for Fedora, Free but GPL > incompatible. I'm adding it to the table now." -- Tom Calloway > > [3] http://www.law.cornell.edu/uscode/usc_sec_17_00000101----000-.html > "A 'collective work' is a work, such as a periodical issue, anthology, > or encyclopedia, in which a number of contributions, constituting > separate and independent works in themselves, are assembled into a > collective whole. > "A 'compilation' is a work formed by the collection and assembling of > preexisting materials or of data that are selected, coordinated, or > arranged in such a way that the resulting work as a whole constitutes > an original work of authorship. The term 'compilation' includes > collective works." -- USC Title 17 Section 101 > > [4] http://www.microsoft.com/opensource/licenses.mspx#Ms-PL > "The terms 'reproduce', 'reproduction', 'derivative works', and > 'distribution' have the same meaning here as under U.S. copyright > law." -- MS-PL: Definitions > > [5] http://www.law.cornell.edu/uscode/usc_sec_17_00000101----000-.html > "A 'derivative work' is a work based upon one or more preexisting > works, such as a translation, musical arrangement, dramatization, > fictionalization, motion picture version, sound recording, art > reproduction, abridgment, condensation, or any other form in which > a work may be recast, transformed, or adapted. A work consisting of > editorial revisions, annotations, elaborations, or other > modifications which, as a whole, represent an original work of > authorship, is a 'derivative work'." -- USC Title 17 Section 101 > > [6] http://www.microsoft.com/opensource/licenses.mspx#Ms-PL > "A 'contribution' is the original software, or any additions or > changes to the software." -- MS-PL: Definitions > > [7] http://digital-law-online.info/lpdi1.0/treatise6.html > "Between them the terms 'compilations' and 'derivative works' > which are defined in section 101, comprehend every copyrightable > work that employs preexisting material or data of any kind. > There is necessarily some overlapping between the two, but they > basically represent different concepts. A ?compilation? results > from a process of selecting, bringing together, organizing, and > arranging previously existing material of all kinds, regardless > of whether the individual items in the material have been or ever > could have been subject to copyright. A ?derivative work,? on the > other hand, requires a process of recasting, transforming, or > adapting ?one or more preexisting works?; the ?preexisting work? > must come within the general subject matter of copyright set > forth in section 102, regardless of whether it is or was ever > copyrighted." FN31: H.R. Rep. No. 94-1476 > > [8] http://www.copyright.gov/circs/circ14.html > > [9] http://digital-law-online.info/lpdi1.0/treatise6.html > > [10] http://www.gnu.org/licenses/old-licenses/gpl-2.0.html > "In addition, mere aggregation of another work not based on > the Program with the Program (or with a work based on the > Program) on a volume of a storage or distribution medium > does not bring the other work under the scope of this > License." -- GPLv2 > > [11] http://www.gnu.org/licenses/gpl.html > "Inclusion of a covered work in an aggregate does not cause this > License to apply to the other parts of the aggregate." -- GPLv3 > > [12] http://www.gnu.org/licenses/fdl.html > "When the Document is included in an aggregate, this License > does not apply to the other works in the aggregate which are not > themselves derivative works of the Document." -- GFDL > > [13] http://creativecommons.org/licenses/by-sa/3.0/legalcode > "A work that constitutes a Collection will not be considered > an Adaptation (as defined below) for the purposes of this > License." -- CC-SA > [14] http://www.microsoft.com/opensource/licenses.mspx#Ms-PL > "If you distribute any portion of the software in source code > form, you may do so only under this license by including a > complete copy of this license with your distribution. If you > distribute any portion of the software in compiled or object > code form, you may only do so under a license that complies > with this license." -- MS-PL Section 3d) > > > _______________________________________________ > Fedora-legal-list mailing list > Fedora-legal-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legal-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Mon Dec 7 17:42:14 2009 From: kwade at redhat.com (Karsten Wade) Date: Mon, 7 Dec 2009 09:42:14 -0800 Subject: [Fedora-legal-list] cascading the CC licenses Message-ID: <20091207174214.GD15126@calliope.phig.org> Some questions about how to reuse/remix CC content in to our wiki and other content locations. Given: our content is now CC BY SA 3.0. What happens when we reuse CC BY content in to our wiki? Is it OK that it turns in to SA after that? Or what does it become? If not, do we have to do something special when mixing CC BY content in? I know we cannot reuse NC content, but what about reuse/remix/redistribution of: * CC BY 3.0 * CC BY SA 2.x * CC BY ND I'm guessing that the no-derivatives content can be redistributed by us, but we don't want to because then we create a mixed work that cannot be free? - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From loganjerry at gmail.com Tue Dec 8 18:50:25 2009 From: loganjerry at gmail.com (Jerry James) Date: Tue, 8 Dec 2009 11:50:25 -0700 Subject: [Fedora-legal-list] Spin commercial license Message-ID: <870180fe0912081050k9523b2fp66689c91c2cc0de0@mail.gmail.com> Is this license acceptable for Fedora (assuming a copy is provided with the package, as required by the license)? http://www.spinroot.com/spin/spin_license.html Thank you, -- Jerry James http://www.jamezone.org/ From oget.fedora at gmail.com Wed Dec 9 09:34:57 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 9 Dec 2009 04:34:57 -0500 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) Message-ID: 1) I came across another review with the same license question. The source files have one of the GPLv2, GPLv2+ and LGPLv2+ headers each. They get compiled and produce 1 final binary executable. None of the headers (or other source code files) go to the final RPM. What goes to the license tag of the package? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=537325#c4 2) Hypothetical question (although happens rather frequently): What if there was a -devel subpackage and .h files with different licenses ended up in this -devel subpackage? Orcan From fabian.deutsch at gmx.de Wed Dec 9 20:57:10 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Wed, 09 Dec 2009 21:57:10 +0100 Subject: [Fedora-legal-list] Legal aspects of fedora based appliances Message-ID: <1260392230.4492.5.camel@decade.local> Hello. Fedora contains various tools for appliance creation. AFAIK it is intended that Fedora shall be used as a base for various appliances ISVs or OEMs want to create. But there is there some legal-guide which summarizes the legal aspects of Fedora based appliances e.g. when I want to distribute a Fedora AOS with some proprietary software? (As some kind of media-center). Greetings fabian From stickster at gmail.com Wed Dec 9 21:14:06 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 9 Dec 2009 16:14:06 -0500 Subject: [Fedora-legal-list] Legal aspects of fedora based appliances In-Reply-To: <1260392230.4492.5.camel@decade.local> References: <1260392230.4492.5.camel@decade.local> Message-ID: <20091209211406.GN9741@victoria.internal.frields.org> On Wed, Dec 09, 2009 at 09:57:10PM +0100, Fabian Deutsch wrote: > Hello. > > Fedora contains various tools for appliance creation. AFAIK it is > intended that Fedora shall be used as a base for various appliances ISVs > or OEMs want to create. But there is there some legal-guide which > summarizes the legal aspects of Fedora based appliances e.g. when I want > to distribute a Fedora AOS with some proprietary software? (As some kind > of media-center). I'm assuming you mean guidance on whether, and how, these types of appliances can use the "Fedora" name and associated trademarks. You can find our full trademark guidelines here: https://fedoraproject.org/wiki/Legal:Trademark_guidelines The particular section on appliances and OS images is here: https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_unmodified_Fedora_software https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From fabian.deutsch at gmx.de Wed Dec 9 21:22:07 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Wed, 09 Dec 2009 22:22:07 +0100 Subject: [Fedora-legal-list] Legal aspects of fedora based appliances In-Reply-To: <20091209211406.GN9741@victoria.internal.frields.org> References: <1260392230.4492.5.camel@decade.local> <20091209211406.GN9741@victoria.internal.frields.org> Message-ID: <1260393727.4492.9.camel@decade.local> Am Mittwoch, den 09.12.2009, 16:14 -0500 schrieb Paul W. Frields: > On Wed, Dec 09, 2009 at 09:57:10PM +0100, Fabian Deutsch wrote: > > Hello. > > > > Fedora contains various tools for appliance creation. AFAIK it is > > intended that Fedora shall be used as a base for various appliances ISVs > > or OEMs want to create. But there is there some legal-guide which > > summarizes the legal aspects of Fedora based appliances e.g. when I want > > to distribute a Fedora AOS with some proprietary software? (As some kind > > of media-center). > > I'm assuming you mean guidance on whether, and how, these types of > appliances can use the "Fedora" name and associated trademarks. You > can find our full trademark guidelines here: > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines > > The particular section on appliances and OS images is here: > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_unmodified_Fedora_software > https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software The usage of the "Fedora" tardemark is just one point. There are more questions (for me at least :) ), like: Will a appliance providers have to keep the sources of all distributed packages, even if they are official Fedora packages? - fabian From ville.skytta at iki.fi Wed Dec 9 21:34:22 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 9 Dec 2009 23:34:22 +0200 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: References: Message-ID: <200912092334.23006.ville.skytta@iki.fi> On Wednesday 09 December 2009, Orcan Ogetbil wrote: > 1) I came across another review with the same license question. The > source files have one of the > GPLv2, GPLv2+ and LGPLv2+ headers each. They get compiled and produce > 1 final binary executable. None of the headers (or other source code > files) go to the final RPM. > > What goes to the license tag of the package? > > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=537325#c4 > > 2) Hypothetical question (although happens rather frequently): What if > there was a -devel subpackage and .h files with different licenses > ended up in this -devel subpackage? Aren't both questions answered pretty well by https://fedoraproject.org/wiki/Packaging/LicensingGuidelines ? From oget.fedora at gmail.com Thu Dec 10 00:10:19 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 9 Dec 2009 19:10:19 -0500 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: <200912092334.23006.ville.skytta@iki.fi> References: <200912092334.23006.ville.skytta@iki.fi> Message-ID: On Wed, Dec 9, 2009 at 4:34 PM, Ville Skytt? wrote: > On Wednesday 09 December 2009, Orcan Ogetbil wrote: >> 1) I came across another review with the same license question. The >> source files have one of the >> GPLv2, GPLv2+ and LGPLv2+ headers each. They get compiled and produce >> 1 final binary executable. None of the headers (or other source code >> files) go to the final RPM. >> >> What goes to the license tag of the package? >> >> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=537325#c4 >> >> 2) Hypothetical question (although happens rather frequently): What if >> there was a -devel subpackage and .h files with different licenses >> ended up in this -devel subpackage? > > Aren't both questions answered pretty well by > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines ? > Nope. I wouldn't ask if they were. Orcan From stickster at gmail.com Thu Dec 10 00:19:25 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 9 Dec 2009 19:19:25 -0500 Subject: [Fedora-legal-list] Legal aspects of fedora based appliances In-Reply-To: <1260393727.4492.9.camel@decade.local> References: <1260392230.4492.5.camel@decade.local> <20091209211406.GN9741@victoria.internal.frields.org> <1260393727.4492.9.camel@decade.local> Message-ID: <20091210001925.GK9741@victoria.internal.frields.org> On Wed, Dec 09, 2009 at 10:22:07PM +0100, Fabian Deutsch wrote: > Am Mittwoch, den 09.12.2009, 16:14 -0500 schrieb Paul W. Frields: > > On Wed, Dec 09, 2009 at 09:57:10PM +0100, Fabian Deutsch wrote: > > > Hello. > > > > > > Fedora contains various tools for appliance creation. AFAIK it is > > > intended that Fedora shall be used as a base for various appliances ISVs > > > or OEMs want to create. But there is there some legal-guide which > > > summarizes the legal aspects of Fedora based appliances e.g. when I want > > > to distribute a Fedora AOS with some proprietary software? (As some kind > > > of media-center). > > > > I'm assuming you mean guidance on whether, and how, these types of > > appliances can use the "Fedora" name and associated trademarks. You > > can find our full trademark guidelines here: > > > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines > > > > The particular section on appliances and OS images is here: > > > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_unmodified_Fedora_software > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software > > The usage of the "Fedora" tardemark is just one point. There are more > questions (for me at least :) ), like: > Will a appliance providers have to keep the sources of all distributed > packages, even if they are official Fedora packages? Spot or someone else will correct me if I go wrong here, but because the Fedora Project ships source pursuant to the requirements of the GPLv2 section 3(a), downstream remixers cannot simply point to the Fedora Project for source distribution (as in section 3(c)). This is intentional and unlikely to change in the near future. Also, section 3(c) as I understand it is not workable for commercial redistributors. The best solution I can imagine is for downstream remixers to simply prepare the matching source collection, and offer it at the same point of distribution under GPL 3(a) as well. IANAL, TINLA, and so forth. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From mschwendt at gmail.com Thu Dec 10 10:25:19 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 10 Dec 2009 11:25:19 +0100 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: References: <200912092334.23006.ville.skytta@iki.fi> Message-ID: <20091210112519.1f2c4ad3@gmail.com> On Wed, 9 Dec 2009 19:10:19 -0500, Orcan wrote: > On Wed, Dec 9, 2009 at 4:34 PM, Ville Skytt? wrote: > > On Wednesday 09 December 2009, Orcan Ogetbil wrote: > >> 1) I came across another review with the same license question. The > >> source files have one of the > >> GPLv2, GPLv2+ and LGPLv2+ headers each. They get compiled and produce > >> 1 final binary executable. None of the headers (or other source code > >> files) go to the final RPM. > >> > >> What goes to the license tag of the package? > >> > >> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=537325#c4 > >> > >> 2) Hypothetical question (although happens rather frequently): What if > >> there was a -devel subpackage and .h files with different licenses > >> ended up in this -devel subpackage? > > > > Aren't both questions answered pretty well by > > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines ? > > > > Nope. I wouldn't ask if they were. Fedora's Licensing Guidelines don't use the term "effective license" anywhere. Not even in the section on dual licensing, which is the scenario where the packager may choose to pick either license for the whole program. There is no such thing as an "effective license" related to the Mixed Source Licensing Scenario [1], because re-licensing a program, such as converting from LGPL to GPL, is not done implicitly or automatically. The FSF wants licensing terms to be applied in a clear/unambiguous way. That's why they explicitly recommend how to apply a license to source code files and why they also point out what licenses may be converted to eachother when copying source code from programs and how to do such conversion. In the case of copying LGPL licensed source files into a GPL licensed program, the files (including code modifications) stay LGPL licensed till the developers opt to convert them to GPL. Irrevocably and with a proper change of source code files. Where such a conversion of licenses is not done in the source code, no implicit/automatic conversion to a license is done for the compiled program either. On the contrary, linking with separate programs is a different scenario. In the "License:" tags filled in by a src.rpm, we only cover the licenses applied to The Program contained within the src.rpm, but not any licenses of external programs/libraries which are linked with. [1] http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Mixed_Source_Licensing_Scenario From tcallawa at redhat.com Thu Dec 10 16:54:12 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 10 Dec 2009 11:54:12 -0500 Subject: [Fedora-legal-list] Re: Fwd: Forking libtar and licensing it as LGPL In-Reply-To: <37547773.1436451260368267001.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> References: <37547773.1436451260368267001.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <4B2127B4.9090108@redhat.com> On 12/09/2009 09:17 AM, Huzaifa Sidhpurwala wrote: > Hi All, > I maintain the libtar package for some time now. However it seems that the upstream author is no longer responding to any patch requests and is also no longer interesting in maintaining the package any more. > I have therefore forked the code and call it libtar-ng. > The libtar library is licensed in MIT like license, The license file can be found at: > http://git.fedorahosted.org/git/?p=libtar-ng.git;a=blob;f=COPYRIGHT;h=2471ec01bf241c48278c181557e5a3919057af21;hb=HEAD > > Now the question is have is: > 1. Can i fork this code? Yes. > 2. If i fork it, do i have to license my forked code as MIT (original license), or can i make it LGPL? You can make it LGPL, the sublicensing permission from MIT permits this. > 3. When i fork it, do i have to retain the header (license and author detail) for each file (code) or can i replace it with my own. Yes, you need to retain the previous copyright information (for each file). You'll need to change the header to reflect the new LGPL license as well as the old MIT license. Here's how you should do it: /* * Copyright (c) 2009 Huzaifa Sidhpurwala * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed 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. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA * 02110-1301 USA * * This file incorporates work covered by the following copyright and * permission notice: * * Copyright (c) 1998-2003 University of Illinois Board of Trustees * Copyright (c) 1998-2003 Mark D. Roth * All rights reserved. * * Developed by: Campus Information Technologies and Educational * Services, University of Illinois at Urbana-Champaign * * Permission is hereby granted, free of charge, to any person * obtaining a copy of this software and associated documentation * files (the ``Software''), to deal with the Software without * restriction, including without limitation the rights to use, copy, * modify, merge, publish, distribute, sublicense, and/or sell copies * of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimers. * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimers in * the documentation and/or other materials provided with the * distribution. * * * Neither the names of Campus Information Technologies and * Educational Services, University of Illinois at Urbana-Champaign, * nor the names of its contributors may be used to endorse or * promote products derived from this Software without specific * prior written permission. * * THE SOFTWARE IS PROVIDED ``AS IS'', WITHOUT WARRANTY OF ANY KIND, * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND * NONINFRINGEMENT. IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER * DEALINGS WITH THE SOFTWARE. */ Don't forget to include COPYING with a copy of the LGPLv2 in plaintext! > 4. If i retain the header in the code files, can i add my name to it? Yes, in fact, you should do this as soon as you have made a copyrightable change to the codebase. Hope this helps, ~spot From shakthimaan at gmail.com Fri Dec 11 07:38:24 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Fri, 11 Dec 2009 13:08:24 +0530 Subject: [Fedora-legal-list] TAPR Open Hardware License Message-ID: Hi, I would like to know if TAPR Open Hardware License is an acceptable license for Fedora: http://www.tapr.org/ohl.html Please clarify. Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com From tcallawa at redhat.com Fri Dec 11 20:19:55 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 11 Dec 2009 15:19:55 -0500 Subject: [Fedora-legal-list] TAPR Open Hardware License In-Reply-To: References: Message-ID: <4B22A96B.6050904@redhat.com> On 12/11/2009 02:38 AM, Shakthi Kannan wrote: > Hi, > > I would like to know if TAPR Open Hardware License is an acceptable > license for Fedora: > > http://www.tapr.org/ohl.html > > Please clarify. Thanks! Umm... this license isn't a copyright license, nor is it useful for software, fonts, or content. What are you trying to do with it? ~spot From tcallawa at redhat.com Fri Dec 11 20:54:59 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 11 Dec 2009 15:54:59 -0500 Subject: [Fedora-legal-list] Spin commercial license In-Reply-To: <870180fe0912081050k9523b2fp66689c91c2cc0de0@mail.gmail.com> References: <870180fe0912081050k9523b2fp66689c91c2cc0de0@mail.gmail.com> Message-ID: <4B22B1A3.50501@redhat.com> On 12/08/2009 01:50 PM, Jerry James wrote: > Is this license acceptable for Fedora (assuming a copy is provided > with the package, as required by the license)? Nope. Non-free. ~spot From loganjerry at gmail.com Fri Dec 11 21:00:39 2009 From: loganjerry at gmail.com (Jerry James) Date: Fri, 11 Dec 2009 14:00:39 -0700 Subject: [Fedora-legal-list] Spin commercial license In-Reply-To: <4B22B1A3.50501@redhat.com> References: <870180fe0912081050k9523b2fp66689c91c2cc0de0@mail.gmail.com> <4B22B1A3.50501@redhat.com> Message-ID: <870180fe0912111300j15847faw667f1894ac9b76ae@mail.gmail.com> On Fri, Dec 11, 2009 at 1:54 PM, Tom "spot" Callaway wrote: > Nope. Non-free. > > ~spot Dang. I hoped that having a license at all would be an improvement over the days when there was no visible license for that tool... Thank you for checking. -- Jerry James http://www.jamezone.org/ From oget.fedora at gmail.com Sat Dec 12 01:54:31 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 11 Dec 2009 20:54:31 -0500 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: <20091210112519.1f2c4ad3@gmail.com> References: <200912092334.23006.ville.skytta@iki.fi> <20091210112519.1f2c4ad3@gmail.com> Message-ID: On Thu, Dec 10, 2009 at 5:25 AM, Michael Schwendt wrote: > > Fedora's Licensing Guidelines don't use the term "effective license" > anywhere. Not even in the section on dual licensing, which is the scenario > where the packager may choose to pick either license for the whole > program. > > There is no such thing as an "effective license" related to the Mixed > Source Licensing Scenario [1], because re-licensing a program, such as > converting from LGPL to GPL, is not done implicitly or automatically. > Thanks but that doesn't answer my question. Are so many people just imagining things? Why does this inconsistency exist? I'd like to have this cleared up so we won't have to discuss the same issue over and over again. Orcan From sundaram at fedoraproject.org Sat Dec 12 02:03:27 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 12 Dec 2009 07:33:27 +0530 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: References: <200912092334.23006.ville.skytta@iki.fi> <20091210112519.1f2c4ad3@gmail.com> Message-ID: <4B22F9EF.9080900@fedoraproject.org> On 12/12/2009 07:24 AM, Orcan Ogetbil wrote: > On Thu, Dec 10, 2009 at 5:25 AM, Michael Schwendt wrote: >> >> Fedora's Licensing Guidelines don't use the term "effective license" >> anywhere. Not even in the section on dual licensing, which is the scenario >> where the packager may choose to pick either license for the whole >> program. >> >> There is no such thing as an "effective license" related to the Mixed >> Source Licensing Scenario [1], because re-licensing a program, such as >> converting from LGPL to GPL, is not done implicitly or automatically. >> > > Thanks but that doesn't answer my question. Are so many people just > imagining things? Why does this inconsistency exist? I'd like to have > this cleared up so we won't have to discuss the same issue over and > over again. People are just confused. The issue has already been clarified. Is there still some specific confusion? Rahul From oget.fedora at gmail.com Sat Dec 12 04:43:44 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 11 Dec 2009 23:43:44 -0500 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: <4B22F9EF.9080900@fedoraproject.org> References: <200912092334.23006.ville.skytta@iki.fi> <20091210112519.1f2c4ad3@gmail.com> <4B22F9EF.9080900@fedoraproject.org> Message-ID: On Fri, Dec 11, 2009 at 9:03 PM, Rahul Sundaram wrote: > On 12/12/2009 07:24 AM, Orcan Ogetbil wrote: >> On Thu, Dec 10, 2009 at 5:25 AM, Michael Schwendt ?wrote: >>> >>> Fedora's Licensing Guidelines don't use the term "effective license" >>> anywhere. Not even in the section on dual licensing, which is the scenario >>> where the packager may choose to pick either license for the whole >>> program. >>> >>> There is no such thing as an "effective license" related to the Mixed >>> Source Licensing Scenario [1], because re-licensing a program, such as >>> converting from LGPL to GPL, is not done implicitly or automatically. >>> >> >> Thanks but that doesn't answer my question. Are so many people just >> imagining things? Why does this inconsistency exist? I'd like to have >> this cleared up so we won't have to discuss the same issue over and >> over again. > > People are just confused. The issue has already been clarified. Is there > still some specific confusion? Okay. Whenever someone says "most restrictive license wins" again, I will say "no", and will refer to this thread. Thanks, Orcan From shakthimaan at gmail.com Sat Dec 12 05:54:09 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Sat, 12 Dec 2009 11:24:09 +0530 Subject: [Fedora-legal-list] TAPR Open Hardware License In-Reply-To: <4B22A96B.6050904@redhat.com> References: <4B22A96B.6050904@redhat.com> Message-ID: Hi, --- On Sat, Dec 12, 2009 at 1:49 AM, Tom "spot" Callaway wrote: | Umm... this license isn't a copyright license, nor is it useful for | software, fonts, or content. What are you trying to do with it? \-- Would like to package and ship open hardware designs that are released under TAPR with Fedora Electronic Lab (FEL) so people can use the FEL tools with it. The open graphics project, for examples, uses this license: http://wiki.opengraphics.org/tiki-index.php SK -- Shakthi Kannan http://www.shakthimaan.com From juliusdavies at gmail.com Sun Dec 13 04:29:57 2009 From: juliusdavies at gmail.com (Julius Davies) Date: Sat, 12 Dec 2009 20:29:57 -0800 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: References: <200912092334.23006.ville.skytta@iki.fi> <20091210112519.1f2c4ad3@gmail.com> <4B22F9EF.9080900@fedoraproject.org> Message-ID: <598ad5b50912122029x4b916b59yaf45e409fc48a7da@mail.gmail.com> Hi, Maybe the overall "master" copyright license for the Fedora compilation causes every single GPL+ compatible file inside Fedora to be licensed as GPL+ ? So every LGPL, BSD, MIT file which *can* be relicensed in this way *is" even if such a relicensing is unnecessary for license compliance? Take a look at this file on your Fedora CDROM: ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/releases/12/Everything/i386/os/GPL ----------- ***************************************************************************** The following copyright applies to the Fedora compilation and any portions of Fedora it does not conflict with. Whenever this policy does conflict with the copyright of any individual portion of Fedora, it does not apply. ***************************************************************************** GNU GENERAL PUBLIC LICENSE Version 2, June 1991 [Rest of file is verbatim copy of GPLv2 license.] ----------- Notice I'm saying GPL+ and not GPLv2+ because of information on the "Licensing:FAQ - FedoraProject" wiki page: https://fedoraproject.org/wiki/Licensing/FAQ ----------- If neither the source, nor the upstream composed documentation says anything about the license version, then it could be under _ANY_ version of the GPL. The version listed in COPYING is irrelevant from this perspective. Technically it could be under any license, but if all we have to go by is COPYING, we'll use COPYING to imply that it is under the GPL, all versions (GPL+). ----------- yours, Julius On Fri, Dec 11, 2009 at 8:43 PM, Orcan Ogetbil wrote: > On Fri, Dec 11, 2009 at 9:03 PM, Rahul Sundaram wrote: >> On 12/12/2009 07:24 AM, Orcan Ogetbil wrote: >>> On Thu, Dec 10, 2009 at 5:25 AM, Michael Schwendt ?wrote: >>>> >>>> Fedora's Licensing Guidelines don't use the term "effective license" >>>> anywhere. Not even in the section on dual licensing, which is the scenario >>>> where the packager may choose to pick either license for the whole >>>> program. >>>> >>>> There is no such thing as an "effective license" related to the Mixed >>>> Source Licensing Scenario [1], because re-licensing a program, such as >>>> converting from LGPL to GPL, is not done implicitly or automatically. >>>> >>> >>> Thanks but that doesn't answer my question. Are so many people just >>> imagining things? Why does this inconsistency exist? I'd like to have >>> this cleared up so we won't have to discuss the same issue over and >>> over again. >> >> People are just confused. The issue has already been clarified. Is there >> still some specific confusion? > > Okay. Whenever someone says "most restrictive license wins" again, I > will say "no", and will refer to this thread. > > Thanks, > Orcan > > _______________________________________________ > Fedora-legal-list mailing list > Fedora-legal-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legal-list > -- yours, Julius Davies 250-592-2284 (Home) 250-893-4579 (Mobile) http://juliusdavies.ca/logging.html From juliusdavies at gmail.com Sun Dec 13 04:45:11 2009 From: juliusdavies at gmail.com (Julius Davies) Date: Sat, 12 Dec 2009 20:45:11 -0800 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: <598ad5b50912122029x4b916b59yaf45e409fc48a7da@mail.gmail.com> References: <200912092334.23006.ville.skytta@iki.fi> <20091210112519.1f2c4ad3@gmail.com> <4B22F9EF.9080900@fedoraproject.org> <598ad5b50912122029x4b916b59yaf45e409fc48a7da@mail.gmail.com> Message-ID: <598ad5b50912122045s348b08cfv68c3c0666b59fcd6@mail.gmail.com> ps. My email is more of a personal tangential thought I'm having and not really relevant to Orcan's original questions since it doesn't have any implications for what to put in the RPM license tag! Here's my attempt at answering Orcan's question: 1. If source contains at least one GPL source code file (but let's ignore header files) and this source code is compiled into a binary file, then the license of the binary file must be: a. If the binary is a single work derived from all the source code files, then that GPL code will take precendence, and the binary as a whole becomes GPL. b. If the binary is a compilation, then I don't know what happens! I'm curious if Java jar files are compilations. 2. As for header files, well they don't really end up in the binary file, do they? So does it matter? And I vaguely recall some notion that API's are not copyrightable, so couldn't someone always rewrite a header file to contain the minimum necessary for compilation and then release that version under any license they like? yours, Julius On Sat, Dec 12, 2009 at 8:29 PM, Julius Davies wrote: > Hi, > > Maybe the overall "master" copyright license for the Fedora > compilation causes every single GPL+ compatible file inside Fedora to > be licensed as GPL+ ? ?So every LGPL, BSD, MIT file which *can* be > relicensed in this way *is" even if such a relicensing is unnecessary > for license compliance? ?Take a look at this file on your Fedora > CDROM: > > ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/releases/12/Everything/i386/os/GPL > ----------- > ***************************************************************************** > The following copyright applies to the Fedora compilation and any > portions of Fedora it does not conflict with. Whenever this > policy does conflict with the copyright of any individual portion of Fedora, > it does not apply. > > ***************************************************************************** > ? ? ? ? ? ? ? ? ? ?GNU GENERAL PUBLIC LICENSE > ? ? ? ? ? ? ? ? ? ? ? Version 2, June 1991 > > [Rest of file is verbatim copy of GPLv2 license.] > ----------- > > > Notice I'm saying GPL+ and not GPLv2+ because of information on the > "Licensing:FAQ - FedoraProject" wiki page: > https://fedoraproject.org/wiki/Licensing/FAQ > > ----------- > If neither the source, nor the upstream composed documentation says > anything about the license version, then it could be under _ANY_ > version of the GPL. The version listed in COPYING is irrelevant from > this perspective. Technically it could be under any license, but if > all we have to go by is COPYING, we'll use COPYING to imply that it is > under the GPL, all versions (GPL+). > ----------- > > > > yours, > > Julius > > > > On Fri, Dec 11, 2009 at 8:43 PM, Orcan Ogetbil wrote: >> On Fri, Dec 11, 2009 at 9:03 PM, Rahul Sundaram wrote: >>> On 12/12/2009 07:24 AM, Orcan Ogetbil wrote: >>>> On Thu, Dec 10, 2009 at 5:25 AM, Michael Schwendt ?wrote: >>>>> >>>>> Fedora's Licensing Guidelines don't use the term "effective license" >>>>> anywhere. Not even in the section on dual licensing, which is the scenario >>>>> where the packager may choose to pick either license for the whole >>>>> program. >>>>> >>>>> There is no such thing as an "effective license" related to the Mixed >>>>> Source Licensing Scenario [1], because re-licensing a program, such as >>>>> converting from LGPL to GPL, is not done implicitly or automatically. >>>>> >>>> >>>> Thanks but that doesn't answer my question. Are so many people just >>>> imagining things? Why does this inconsistency exist? I'd like to have >>>> this cleared up so we won't have to discuss the same issue over and >>>> over again. >>> >>> People are just confused. The issue has already been clarified. Is there >>> still some specific confusion? >> >> Okay. Whenever someone says "most restrictive license wins" again, I >> will say "no", and will refer to this thread. >> >> Thanks, >> Orcan >> >> _______________________________________________ >> Fedora-legal-list mailing list >> Fedora-legal-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-legal-list >> > > > > -- > yours, > > Julius Davies > 250-592-2284 (Home) > 250-893-4579 (Mobile) > http://juliusdavies.ca/logging.html > -- yours, Julius Davies 250-592-2284 (Home) 250-893-4579 (Mobile) http://juliusdavies.ca/logging.html From mschwendt at gmail.com Sun Dec 13 12:22:36 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 13 Dec 2009 13:22:36 +0100 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: <598ad5b50912122045s348b08cfv68c3c0666b59fcd6@mail.gmail.com> References: <200912092334.23006.ville.skytta@iki.fi> <20091210112519.1f2c4ad3@gmail.com> <4B22F9EF.9080900@fedoraproject.org> <598ad5b50912122029x4b916b59yaf45e409fc48a7da@mail.gmail.com> <598ad5b50912122045s348b08cfv68c3c0666b59fcd6@mail.gmail.com> Message-ID: <20091213132236.772ba1c8@gmail.com> On Sat, 12 Dec 2009 20:45:11 -0800, Julius wrote: > ps. My email is more of a personal tangential thought I'm having and > not really relevant to Orcan's original questions since it doesn't > have any implications for what to put in the RPM license tag! Still, what to put in the "License:" tag has implications with regard to the compatibility of the programs. It is especially important for the "A may use B" relation which is relevant when linking program A with library B. And when _copying_ code from program A to program B, proper license conversion ought to be applied in the program's source code as explained in the appendix of the license files, and e.g. following the compatibility matrix and other Q&A in the FSF's GPL FAQ: http://www.fsf.org/licensing/licenses/gpl-faq.html You cannot hide "GPLv2 only" files in a GPLv2+ library, for example, and use this with a GPLv3 program. Once more, conversion of licenses is not implicit or automatic. Even if we say our "License:" tags are not legally binding, it is not us to override the actual licensing that is applied to a program in the source files and in accompanying documentation. "GPLv2 only" and LGPL files _may_ be converted to apply the GPLv2+, but somebody needs to do that. Explicitly. And as explained in the appendix to the license terms. Related to Orcan's initial post, the software developer has replied to me. The program is supposed to apply the "GPLv2 only" and any GPLv2+ and LGPL references are not supposed to be there. The author also pointed out that he doesn't like the "or later" clause in general. Whether and when the source code archive will be fixed, is another question. > Here's my attempt at answering Orcan's question: > > 1. If source contains at least one GPL source code file (but let's > ignore header files) That exception is inacceptable already. So-called "header files" are "source code", too, particularly if they contain inline functions and/or define structures and other non-basic types. From rfontana at redhat.com Sun Dec 13 14:27:41 2009 From: rfontana at redhat.com (Richard Fontana) Date: Sun, 13 Dec 2009 09:27:41 -0500 Subject: [Fedora-legal-list] Please define "effective license" (for the love of consistency) In-Reply-To: <598ad5b50912122029x4b916b59yaf45e409fc48a7da@mail.gmail.com> References: <200912092334.23006.ville.skytta@iki.fi> <20091210112519.1f2c4ad3@gmail.com> <4B22F9EF.9080900@fedoraproject.org> <598ad5b50912122029x4b916b59yaf45e409fc48a7da@mail.gmail.com> Message-ID: <20091213092741.4c19efc6@calliope> On Sat, 12 Dec 2009 20:29:57 -0800 Julius Davies wrote: > Hi, > > Maybe the overall "master" copyright license for the Fedora > compilation causes every single GPL+ compatible file inside Fedora to > be licensed as GPL+ ? So every LGPL, BSD, MIT file which *can* be > relicensed in this way *is" even if such a relicensing is unnecessary > for license compliance? > > Take a look at this file on your Fedora > CDROM: > > ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/releases/12/Everything/i386/os/GPL > ----------- > ***************************************************************************** > The following copyright applies to the Fedora compilation and any > portions of Fedora it does not conflict with. Whenever this > policy does conflict with the copyright of any individual portion of > Fedora, it does not apply. > > ***************************************************************************** > GNU GENERAL PUBLIC LICENSE > Version 2, June 1991 > > [Rest of file is verbatim copy of GPLv2 license.] > ----------- I haven't been following this thread closely, but this reference to GPLv2 is a licensing bug - an erroneous holdover from the RHL era, and should not have been included. I can say categorically that any global copyright license for the Fedora compilation is intended to have no effect on the licensing of Fedora packages. - RF -- Richard E. Fontana Open Source Licensing and Patent Counsel Red Hat, Inc. From fabian.deutsch at gmx.de Sun Dec 13 14:31:18 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Sun, 13 Dec 2009 15:31:18 +0100 Subject: [Fedora-legal-list] Legal aspects of fedora based appliances In-Reply-To: <20091210001925.GK9741@victoria.internal.frields.org> References: <1260392230.4492.5.camel@decade.local> <20091209211406.GN9741@victoria.internal.frields.org> <1260393727.4492.9.camel@decade.local> <20091210001925.GK9741@victoria.internal.frields.org> Message-ID: <1260714678.4486.1.camel@decade.local> Am Mittwoch, den 09.12.2009, 19:19 -0500 schrieb Paul W. Frields: > On Wed, Dec 09, 2009 at 10:22:07PM +0100, Fabian Deutsch wrote: > > Am Mittwoch, den 09.12.2009, 16:14 -0500 schrieb Paul W. Frields: > > > On Wed, Dec 09, 2009 at 09:57:10PM +0100, Fabian Deutsch wrote: > > > > Hello. > > > > > > > > Fedora contains various tools for appliance creation. AFAIK it is > > > > intended that Fedora shall be used as a base for various appliances ISVs > > > > or OEMs want to create. But there is there some legal-guide which > > > > summarizes the legal aspects of Fedora based appliances e.g. when I want > > > > to distribute a Fedora AOS with some proprietary software? (As some kind > > > > of media-center). > > > > > > I'm assuming you mean guidance on whether, and how, these types of > > > appliances can use the "Fedora" name and associated trademarks. You > > > can find our full trademark guidelines here: > > > > > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines > > > > > > The particular section on appliances and OS images is here: > > > > > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_unmodified_Fedora_software > > > https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software > > > > The usage of the "Fedora" tardemark is just one point. There are more > > questions (for me at least :) ), like: > > Will a appliance providers have to keep the sources of all distributed > > packages, even if they are official Fedora packages? > > Spot or someone else will correct me if I go wrong here, but because > the Fedora Project ships source pursuant to the requirements of the > GPLv2 section 3(a), downstream remixers cannot simply point to the > Fedora Project for source distribution (as in section 3(c)). This is > intentional and unlikely to change in the near future. Also, section > 3(c) as I understand it is not workable for commercial redistributors. Okay. Thansk to clarify this. > The best solution I can imagine is for downstream remixers to simply > prepare the matching source collection, and offer it at the same point > of distribution under GPL 3(a) as well. IANAL, TINLA, and so forth. But remixers could use the srpms, provided in the official Fedora spins, to build some custom "appliance"-spin? fabian From kwade at redhat.com Mon Dec 14 07:20:45 2009 From: kwade at redhat.com (Karsten Wade) Date: Sun, 13 Dec 2009 23:20:45 -0800 Subject: [Fedora-legal-list] Fedora content downstream at Wikipedia Message-ID: <20091214071957.GI4618@calliope.phig.org> I'm considering the idea[1] of taking (part of) this canonical page: http://fedoraproject.org/wiki/Red_Hat_contributions ... and maintaining it downstream at, e.g.: http://en.wikipedia.org/wiki/Red_Hat_software_contributions On the face of it, the source content is the same license as Wikipedia. Maintaining the Wikipedia page as a downstream is as simple as copy + paste, then watch the canonical page and update the downstream page as appropriate. But there is an additional clause in contributing content to Wikipedia, that it be contributed under the GFDL: http://en.wikipedia.org/wiki/Wikipedia:Copyright#Contributors.27_rights_and_obligations If you contribute text directly to Wikipedia, you thereby license it to the public for reuse under CC-BY-SA and GFDL (unversioned, with no invariant sections, front-cover texts, or back-cover texts). If I were the copyright holder for the Fedora content in question, I would just accept that. However, the [[Red Hat contributions]] page on the Fedora wiki is definitely an aggregate work.[2] Interestingly, it appears the vast majority of the contributions are from Red Hat employees. If copyright holder permission is required or preferred, we could obtain it and put a notice on the page that future contributions are going to be relicensed at Wikipedia under ... the GFDL specifically? Yeah, specifics make more sense. How to handle all this? Thanks - Karsten [1] Not being sure about the cultural stance of being @redhat.com and doing this, I've requested help on the subject here: http://iquaid.org/2009/12/14/how-can-we-share-some-love-about-red-hat-with-wikipedia [2] Full history for this page on this wiki: https://fedoraproject.org/w/index.php?title=Red_Hat_contributions&limit=500&action=history There is a copyright history that goes back to the previous wiki. We can obtain that list, if needed. :) -- name: Karsten 'quaid' Wade, Sr. Community Gardener team: Red Hat Community Architecture uri: http://quaid.fedorapeople.org gpg: AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From luis at tieguy.org Mon Dec 14 07:28:54 2009 From: luis at tieguy.org (Luis Villa) Date: Sun, 13 Dec 2009 23:28:54 -0800 Subject: [Fedora-legal-list] Fedora content downstream at Wikipedia In-Reply-To: <20091214071957.GI4618@calliope.phig.org> References: <20091214071957.GI4618@calliope.phig.org> Message-ID: <2cb10c440912132328h7e225de2h1cf0075a060dfd29@mail.gmail.com> On Sun, Dec 13, 2009 at 11:20 PM, Karsten Wade wrote: > But there is an additional clause in contributing content to > Wikipedia, that it be contributed under the GFDL: > > http://en.wikipedia.org/wiki/Wikipedia:Copyright#Contributors.27_rights_and_obligations > > ?If you contribute text directly to Wikipedia, you thereby license it > ?to the public for reuse under CC-BY-SA and GFDL (unversioned, with > ?no invariant sections, front-cover texts, or back-cover texts). "If you want to import text that you have found elsewhere or that you have co-authored with others, you can only do so if it is available under terms that are compatible with the CC-BY-SA license. ***You do not need to ensure or guarantee that the imported text is available under the GNU Free Documentation License, unless you are its sole author.***" ***emphasis mine That's the second paragraph of your own link... given that the content is already CC-BY-SA, it should just be importable straight into wikipedia (doesn't need to be GFDL), unless I'm missing something? Or to put it more clearly: * it is my understanding that all content in the fedora wiki is CC-BY-SA * it is my understanding that wikipedia can accept all CC-BY-SA content. (GFDL is no longer required.) therefore: * it is my understanding that all content in the fedora wiki can be exported over to wikipedia. Quite possibly I'm wrong on all of these; it is late and I am tired :) Luis From rfontana at redhat.com Mon Dec 14 14:46:12 2009 From: rfontana at redhat.com (Richard Fontana) Date: Mon, 14 Dec 2009 09:46:12 -0500 Subject: [Fedora-legal-list] Fedora content downstream at Wikipedia In-Reply-To: <2cb10c440912132328h7e225de2h1cf0075a060dfd29@mail.gmail.com> References: <20091214071957.GI4618@calliope.phig.org> <2cb10c440912132328h7e225de2h1cf0075a060dfd29@mail.gmail.com> Message-ID: <20091214094612.437644cc@calliope> On Sun, 13 Dec 2009 23:28:54 -0800 Luis Villa wrote: > On Sun, Dec 13, 2009 at 11:20 PM, Karsten Wade > wrote: > > But there is an additional clause in contributing content to > > Wikipedia, that it be contributed under the GFDL: > > > > http://en.wikipedia.org/wiki/Wikipedia:Copyright#Contributors.27_rights_and_obligations > > > > ?If you contribute text directly to Wikipedia, you thereby license > > it to the public for reuse under CC-BY-SA and GFDL (unversioned, > > with no invariant sections, front-cover texts, or back-cover texts). > > "If you want to import text that you have found elsewhere or that you > have co-authored with others, you can only do so if it is available > under terms that are compatible with the CC-BY-SA license. ***You do > not need to ensure or guarantee that the imported text is available > under the GNU Free Documentation License, unless you are its sole > author.***" > > ***emphasis mine > > That's the second paragraph of your own link... given that the content > is already CC-BY-SA, it should just be importable straight into > wikipedia (doesn't need to be GFDL), unless I'm missing something? > > Or to put it more clearly: > * it is my understanding that all content in the fedora wiki is > CC-BY-SA > * it is my understanding that wikipedia can accept all CC-BY-SA > content. (GFDL is no longer required.) > > therefore: > * it is my understanding that all content in the fedora wiki can be > exported over to wikipedia. > > Quite possibly I'm wrong on all of these; it is late and I am tired :) I think Luis is correct, but in any event, to the extent that Red Hat is the CC-BY-SA licensor here (by virtue of the Fedora CLA, and/or of the contributions by Red Hat employees qua Red Hat employees), and unless there are obligations to other licensors/copyright holders that would prevent this (which seems not to be the case here), and unless non-Red-Hat contributors do not object as to their copyrightable contributions, such content is also available under the much-maligned GFDL. That can be regarded as a general policy. - RF -- Richard E. Fontana Open Source Licensing and Patent Counsel Red Hat, Inc. From tmz at pobox.com Sat Dec 19 19:28:29 2009 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 19 Dec 2009 14:28:29 -0500 Subject: [Fedora-legal-list] Creating a trusted sha256sum.exe binary for verifying *-CHECKSUM files on Windows In-Reply-To: <20091124153316.GU4509@inocybe.localdomain> Message-ID: <20091219192829.GY5004@inocybe.localdomain> Greetings, Some of you might be aware that the instructions for verifying our *-CHECKSUM files on Windows have been broken since we moved to SHA256. Previously, we linked users to a sha1sum.exe built by the GnuPG project?. With SHA256, we don't have that ability. There is an open bug to provide a sha256sum.exe which we can point to for Windows who don't have any other tools to verify SHA256 checksums?. Packages are ready and referenced in bug 527060?. The idea is to build these packages in koji, though not for inclusion in any Fedora release (as the packages are mostly a bit of a hack to build a small subset of coreutils for Windows). What I'm wondering about is what do we need to do in order to ensure GPL compliance here? Knowing that will help me move this forward with the folks on the infrastructure team. We discussed this a bit on the infrastructure list? a month back, though the discussion got off on a few tangents. I'd like to revive it and I think that having some insight from the legal team will help. Bruno Wolff III had some interesting questions regarding GPL compliance and MingW binaries at the end of the infra-list thread?. Thanks for any help and guidance! ? http://docs.fedoraproject.org/readme-burning-isos/en_US/sn-validating-files.html ? https://bugzilla.redhat.com/show_bug.cgi?id=527060 ? https://bugzilla.redhat.com/show_bug.cgi?id=527060#c14 ? http://www.redhat.com/archives/fedora-infrastructure-list/2009-November/msg00140.html ? http://www.redhat.com/archives/fedora-infrastructure-list/2009-November/msg00158.html -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Politicians are interested in people. Not that this is always a virtue. Fleas are interested in dogs. -- P.J. O'Rourke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tcallawa at redhat.com Wed Dec 23 15:35:07 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Dec 2009 10:35:07 -0500 Subject: [Fedora-legal-list] Creating a trusted sha256sum.exe binary for verifying *-CHECKSUM files on Windows In-Reply-To: <20091219192829.GY5004@inocybe.localdomain> References: <20091219192829.GY5004@inocybe.localdomain> Message-ID: <4B3238AB.8050506@redhat.com> On 12/19/2009 02:28 PM, Todd Zullinger wrote: > What I'm wondering about is what do we need to do in order to ensure > GPL compliance here? Knowing that will help me move this forward with > the folks on the infrastructure team. Assuming GPLv2, the simplest solution for you would be to do this: In GPLv2, it says: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. So, assuming we will be putting this binary somewhere on the Fedora website, we should put links to download the source code for the sha256 binary (and all statically compiled libraries) right next to it. These links can be to koji, as long as they will not go stale (e.g. no scratch builds). Also, we'll want to put the binary .exe in a zip file with COPYING (GPLv2 license text). hth, ~spot From tcallawa at redhat.com Wed Dec 23 16:54:04 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Dec 2009 11:54:04 -0500 Subject: [Fedora-legal-list] TAPR Open Hardware License In-Reply-To: References: <4B22A96B.6050904@redhat.com> Message-ID: <4B324B2C.4020202@redhat.com> On 12/12/2009 12:54 AM, Shakthi Kannan wrote: > Hi, > > --- On Sat, Dec 12, 2009 at 1:49 AM, Tom "spot" Callaway > wrote: > | Umm... this license isn't a copyright license, nor is it useful for > | software, fonts, or content. What are you trying to do with it? > \-- > > Would like to package and ship open hardware designs that are released > under TAPR with Fedora Electronic Lab (FEL) so people can use the FEL > tools with it. Red Hat Legal thinks this is non-free, because the indemnification clause (7.4) is too broad. ~spot From shakthimaan at gmail.com Wed Dec 23 17:07:48 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 23 Dec 2009 22:37:48 +0530 Subject: [Fedora-legal-list] TAPR Open Hardware License In-Reply-To: <4B324B2C.4020202@redhat.com> References: <4B22A96B.6050904@redhat.com> <4B324B2C.4020202@redhat.com> Message-ID: Hi Tom, --- On Wed, Dec 23, 2009 at 10:24 PM, Tom "spot" Callaway wrote: | Red Hat Legal thinks this is non-free, because the indemnification | clause (7.4) is too broad. \-- Thanks for following this up, and for your reply. SK -- Shakthi Kannan http://www.shakthimaan.com From shakthimaan at gmail.com Wed Dec 30 06:53:28 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 30 Dec 2009 12:23:28 +0530 Subject: [Fedora-legal-list] Trusster Open Source License Message-ID: Hi, Could you please clarify if the Trusster [1] Open Source License is an acceptable Free/Open Source Software License for the Fedora project. The Teal [2] project uses this license: === BEGIN === Trusster Open Source License version 1.0a (TRUST) copyright (c) 2006 Mike Mintz and Robert Ekendahl. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * 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. * Redistributions in any form must be accompanied by information on how to obtain complete source code for this software and any accompanying software that uses this software. The source code must either be included in the distribution or be available in a timely fashion for no more than the cost of distribution plus a nominal fee, and must be freely redistributable under reasonable and no more restrictive conditions. For an executable file, complete source code means the source code for all modules it contains. It does not include source code for modules or files that typically accompany the major components of the operating system on which the executable file runs. THIS SOFTWARE IS PROVIDED BY MIKE MINTZ AND ROBERT EKENDAHL ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL MIKE MINTZ AND ROBERT EKENDAHL OR ITS 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. === END === Thanks! SK [1] Trustter. http://www.trusster.com [2] Teal. A Verification Utility and Connection Library. http://www.trusster.com/products/teal/ -- Shakthi Kannan http://www.shakthimaan.com From tcallawa at redhat.com Wed Dec 30 22:12:04 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 30 Dec 2009 17:12:04 -0500 Subject: [Fedora-legal-list] Trusster Open Source License In-Reply-To: References: Message-ID: <4B3BD034.4000906@redhat.com> On 12/30/2009 01:53 AM, Shakthi Kannan wrote: > Hi, > > Could you please clarify if the Trusster [1] Open Source License is an > acceptable Free/Open Source Software License for the Fedora project. > The Teal [2] project uses this license: The Trusster Open Source License is Free, but GPL incompatible. I've added it to the Fedora approved licenses list, please use: License: TOSL ~spot From shakthimaan at gmail.com Thu Dec 31 03:46:04 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Thu, 31 Dec 2009 09:16:04 +0530 Subject: [Fedora-legal-list] Trusster Open Source License In-Reply-To: <4B3BD034.4000906@redhat.com> References: <4B3BD034.4000906@redhat.com> Message-ID: Hi, --- On Thu, Dec 31, 2009 at 3:42 AM, Tom "spot" Callaway wrote: | The Trusster Open Source License is Free, but GPL incompatible. I've | added it to the Fedora approved licenses list, please use: | | License: TOSL \-- Thanks for your quick and prompt response! SK -- Shakthi Kannan http://www.shakthimaan.com From abo at root.snowtree.se Thu Dec 31 13:17:16 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 31 Dec 2009 14:17:16 +0100 Subject: [Fedora-legal-list] java-gnome: GPLv2 with a classpath exception like statement Message-ID: <1262265436.6749.1564.camel@localhost> Hello, I'd like to ask someone to have a look at the license for java-gnome, the GNOME Java bindings: http://research.operationaldynamics.com/bzr/java-gnome/mainline/LICENCE I'm hoping it can be added to the acceptable licenses list. Presumably after that happens I can put "License: GPLv2 with exceptions" in the corresponding spec file. Is it wrong to fall back to "License: GPLv2" in the meantime? I'd like to have the exception though to hopefully make it GPLv3 compatible. Thanks! /abo From tcallawa at redhat.com Thu Dec 31 15:04:17 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 31 Dec 2009 10:04:17 -0500 Subject: [Fedora-legal-list] java-gnome: GPLv2 with a classpath exception like statement In-Reply-To: <1262265436.6749.1564.camel@localhost> References: <1262265436.6749.1564.camel@localhost> Message-ID: <4B3CBD71.5000502@redhat.com> On 12/31/2009 08:17 AM, Alexander Bostr?m wrote: > Hello, > > I'd like to ask someone to have a look at the license for java-gnome, > the GNOME Java bindings: > > http://research.operationaldynamics.com/bzr/java-gnome/mainline/LICENCE > > I'm hoping it can be added to the acceptable licenses list. Presumably > after that happens I can put "License: GPLv2 with exceptions" in the > corresponding spec file. This is the "Classpath" exception, which is fine for Fedora. Go ahead and use: License: GPLv2 with exceptions (I've added entries for the Classpath exception to the GPL section of the Licensing list to make this clear.) ~spot From Joerg.Schilling at fokus.fraunhofer.de Thu Dec 31 16:31:05 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Thu, 31 Dec 2009 17:31:05 +0100 Subject: [Fedora-legal-list] java-gnome: GPLv2 with a classpath exception like statement In-Reply-To: <1262265436.6749.1564.camel@localhost> References: <1262265436.6749.1564.camel@localhost> Message-ID: <4b3cd1c9.Qi5hPubXJucpk6Hz%Joerg.Schilling@fokus.fraunhofer.de> Alexander Bostr?m wrote: > I'm hoping it can be added to the acceptable licenses list. Presumably > after that happens I can put "License: GPLv2 with exceptions" in the > corresponding spec file. > > Is it wrong to fall back to "License: GPLv2" in the meantime? I'd like > to have the exception though to hopefully make it GPLv3 compatible. This may be impossible, note that GPLv3 allows a downstream to remove permissive exceptions. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily