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