2:47 p.m.
On Friday 31 July 2009, Tim Waugh wrote:
Beginning with the 8.70 release, Ghostscript will be licensed as
GPLv3+.
This might cause problems for a bunch of packages.
$ repoquery --repoid=rawhide --whatrequires --alldeps ghostscript ghostscript-
gtk --qf="%{NAME}: %{LICENSE}" | grep -vP '\bGPL(v3|\S*\+)' | sort
I'm pretty sure that not all these are problems (I haven't checked license
compatibility of non-GPL licenses with GPLv3+ nor how exactly they use
ghostscript), and on the other hand some might have been problems also with
the current GPLv2 ghostscript, but anyway it's a start for a checklist.
baekmuk-ttf-fonts-ghostscript: Baekmuk
cjkuni-fonts-ghostscript: Arphic
hevea: QPL
HippoDraw: GPLv2
ImageMagick: ImageMagick
libgnomeprint22: LGPLv2+ and BSD
lilypond: GPLv2
printer-filters: Public Domain
redhat-lsb: GPLv2
tetex-prosper: LPPL
tgif: QPL
transfig: MIT
xournal: GPLv2
3:19 p.m.
On Fri, 2009-07-31 at 22:47 +0300, Ville Skyttä wrote:
This might cause problems for a bunch of packages.
$ repoquery --repoid=rawhide --whatrequires --alldeps ghostscript ghostscript-
gtk --qf="%{NAME}: %{LICENSE}" | grep -vP '\bGPL(v3|\S*\+)' | sort
Wouldn't it be packages using the libraries that might pose problems?
$ repoquery --repoid=rawhide --whatrequires --alldeps
'libgs.so.8()(64bit)' 'libijs-0.35.so()(64bit)' --qf="%{NAME}:
%{LICENSE}"
foomatic: GPLv2+
ghostscript-devel: GPLv2 and Redistributable, no modification permitted
libspectre: GPLv2+
ImageMagick: ImageMagick
ghostscript: GPLv2 and Redistributable, no modification permitted
ghostscript-gtk: GPLv2 and Redistributable, no modification permitted
ghostscript-devel: GPLv2 and Redistributable, no modification permitted
gutenprint: GPLv2+
Other packages would be invoking the executable, which (AIUI) is not
considered "based on" ghostscript.
The ImageMagick license seems to be compatible with GPLv3.
Tim.
*/
2:11 p.m.
On Friday 31 July 2009, Tim Waugh wrote:
On Fri, 2009-07-31 at 22:47 +0300, Ville Skyttä wrote:
> This might cause problems for a bunch of packages.
>
> $ repoquery --repoid=rawhide --whatrequires --alldeps ghostscript
> ghostscript- gtk --qf="%{NAME}: %{LICENSE}" | grep -vP
'\bGPL(v3|\S*\+)'
> | sort
Wouldn't it be packages using the libraries that might pose problems?
That's one interpretation (or to be more exact, stuff that _links_ with
ghostscript's libraries - dlopen()ing might be another story). Fedora/Red Hat
legal have the official one as far as Fedora is concerned and I *guess* it is
indeed that one.
The ImageMagick license seems to be compatible with GPLv3.
I'll steal this space to point out that I don't think it's widely enough
understood what "GPL compatibility" means. Personally I've found it helpful
to think of it as "can be GPL-assimilated". (This is nothing new with GPLv3
BTW.)
An ImageMagick build that is linked with GPL'd ghostscript is actually
distributable only as a _GPL'd_ combined work, and is no longer distributable
under the ImageMagick license (otherwise other apps could use ImageMagick as a
proxy to circumvent the ghostscript's GPL). http://www.gnu.org/licenses/gpl-
faq.html#WhatDoesCompatMean
This has nasty cascading effects considering that the ImageMagick license and
GPL are quite different; for example the ImageMagick license does not consider
things that link with ImageMagick as derivative works.
I think/hope the next round of licensing work in Fedora will take stuff like
this into account so we can all "enjoy" GPL's viral/assimilating nature to
its
full extent :P
(I think it goes without saying, but IANAL.)
8:47 a.m.
On 07/31/2009 04:19 PM, Tim Waugh wrote:
On Fri, 2009-07-31 at 22:47 +0300, Ville Skyttä wrote:
> This might cause problems for a bunch of packages.
>
> $ repoquery --repoid=rawhide --whatrequires --alldeps ghostscript ghostscript-
> gtk --qf="%{NAME}: %{LICENSE}" | grep -vP '\bGPL(v3|\S*\+)' | sort
Wouldn't it be packages using the libraries that might pose problems?
$ repoquery --repoid=rawhide --whatrequires --alldeps
'libgs.so.8()(64bit)' 'libijs-0.35.so()(64bit)' --qf="%{NAME}:
%{LICENSE}"
foomatic: GPLv2+
ghostscript-devel: GPLv2 and Redistributable, no modification permitted
libspectre: GPLv2+
ImageMagick: ImageMagick
ghostscript: GPLv2 and Redistributable, no modification permitted
ghostscript-gtk: GPLv2 and Redistributable, no modification permitted
ghostscript-devel: GPLv2 and Redistributable, no modification permitted
gutenprint: GPLv2+
Other packages would be invoking the executable, which (AIUI) is not
considered "based on" ghostscript.
The ImageMagick license seems to be compatible with GPLv3.
I'm really only concerned about these library linking cases, which all
seem to be GPLv3 compatible.
I think it is a reasonable argument that applications which call out to
ghostscript are well separated, thus, can be sanely treated as two
separate programs.
~spot
3:53 p.m.
On Fri, 2009-07-31 at 22:47 +0300, Ville Skyttä wrote:
On Friday 31 July 2009, Tim Waugh wrote:
> Beginning with the 8.70 release, Ghostscript will be licensed as GPLv3+.
This might cause problems for a bunch of packages.
$ repoquery --repoid=rawhide --whatrequires --alldeps ghostscript ghostscript-
gtk --qf="%{NAME}: %{LICENSE}" | grep -vP '\bGPL(v3|\S*\+)' | sort
I'm pretty sure that not all these are problems (I haven't checked license
compatibility of non-GPL licenses with GPLv3+ nor how exactly they use
ghostscript), and on the other hand some might have been problems also with
the current GPLv2 ghostscript, but anyway it's a start for a checklist.
baekmuk-ttf-fonts-ghostscript: Baekmuk
cjkuni-fonts-ghostscript: Arphic
hevea: QPL
HippoDraw: GPLv2
ImageMagick: ImageMagick
libgnomeprint22: LGPLv2+ and BSD
lilypond: GPLv2
printer-filters: Public Domain
redhat-lsb: GPLv2
tetex-prosper: LPPL
tgif: QPL
transfig: MIT
xournal: GPLv2
There is a handy GPL compatibility matrix here:
http://www.fsf.org/licensing/licenses/gpl-faq.html
It makes it clear that GPLv2 code using or linking against GPLv3 code is
a no-no, so all the GPLv2 packages on that list are indeed in trouble,
if their license tags are accurate (if they were really GPLv2+, they'd
be OK, but they'd effectively then becomes GPLv3+).
It says that LGPLv2+ code can use or link against GPLv3 code only if you
can effectively re-license it as GPLv3 (which the LGPL allows, but the
package may have _other_ licensing conflicts if you treat it as GPLv3).
An interesting side-question here is what license tag we should use for
an app whose license text states GPLv2+, but which we are linking
against a GPLv3+ library, effectively meaning that its license for our
purposes is GPLv3+...
ahhh, licensing! Spot will likely have better thoughts on all of this,
plus thoughts on the other license compatibility stuff. I don't think
MIT / BSD licensed stuff has any problem linking against GPL stuff
(unless it's under the _original_ BSD license, with the advertising
clause). Not sure about QPL or LPPL. Public Domain obviously has no
problems.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:11 a.m.
On Fri, 2009-07-31 at 13:53 -0700, Adam Williamson wrote:
> $ repoquery --repoid=rawhide --whatrequires --alldeps
ghostscript ghostscript-
> gtk --qf="%{NAME}: %{LICENSE}" | grep -vP '\bGPL(v3|\S*\+)' | sort
[...]
> baekmuk-ttf-fonts-ghostscript: Baekmuk
> cjkuni-fonts-ghostscript: Arphic
> hevea: QPL
> HippoDraw: GPLv2
> ImageMagick: ImageMagick
> libgnomeprint22: LGPLv2+ and BSD
> lilypond: GPLv2
> printer-filters: Public Domain
> redhat-lsb: GPLv2
> tetex-prosper: LPPL
> tgif: QPL
> transfig: MIT
> xournal: GPLv2
There is a handy GPL compatibility matrix here:
http://www.fsf.org/licensing/licenses/gpl-faq.html
It makes it clear that GPLv2 code using or linking against GPLv3 code is
a no-no, so all the GPLv2 packages on that list are indeed in trouble,
[...]
It says that LGPLv2+ code can use or link against GPLv3 code only if
you
can effectively re-license it as GPLv3 (which the LGPL allows, but the
package may have _other_ licensing conflicts if you treat it as GPLv3).
No, please look more closely. The above is a list of packages that
*use* or *require* ghostscript, not that link to it.
See my most recent contribution to this thread to see the correct list
based on requirements for libgs.so.8 and libijs-0.35.so.
An interesting side-question here is what license tag we should use
for
an app whose license text states GPLv2+, but which we are linking
against a GPLv3+ library, effectively meaning that its license for our
purposes is GPLv3+...
Yes, indeed.
Tim.
*/
4:38 p.m.
On Sat, 2009-08-01 at 12:11 +0100, Tim Waugh wrote:
No, please look more closely. The above is a list of packages that
*use* or *require* ghostscript, not that link to it.
See my most recent contribution to this thread to see the correct
list
based on requirements for libgs.so.8 and libijs-0.35.so.
Yes, I saw that after I'd sent my reply. I had assumed the original list
was correct, and worked on that basis.
> An interesting side-question here is what license tag we should
use for
> an app whose license text states GPLv2+, but which we are linking
> against a GPLv3+ library, effectively meaning that its license for our
> purposes is GPLv3+...
Yes, indeed.
I should probably talk to Spot about that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:15 p.m.
On 08/04/2009 05:38 PM, Adam Williamson wrote:
On Sat, 2009-08-01 at 12:11 +0100, Tim Waugh wrote:
> No, please look more closely. The above is a list of packages that
> *use* or *require* ghostscript, not that link to it.
> See my most recent contribution to this thread to see the correct list
> based on requirements for libgs.so.8 and libijs-0.35.so.
Yes, I saw that after I'd sent my reply. I had assumed the original list
was correct, and worked on that basis.
>> An interesting side-question here is what license tag we should use for
>> an app whose license text states GPLv2+, but which we are linking
>> against a GPLv3+ library, effectively meaning that its license for our
>> purposes is GPLv3+...
> Yes, indeed.
I should probably talk to Spot about that.
So, the rule here is that we don't take outside linking into effect when
marking the package's licensing. We go by what the source in the tarball
tells us. Otherwise, it would become massively too complicated to figure
it out for a lot of packages.
~spot
1:33 p.m.
On Wed, 2009-08-05 at 00:15 -0400, Tom "spot" Callaway wrote:
> I should probably talk to Spot about that.
So, the rule here is that we don't take outside linking into effect when
marking the package's licensing. We go by what the source in the tarball
tells us. Otherwise, it would become massively too complicated to figure
it out for a lot of packages.
I see that, but it presents a rather significant problem.
Say we have something whose own license is LGPLv2+ - let's call it
Component B - linking against something whose license is GPLv3
(Component C).
Component B is then effectively GPLv3, but our license tags will not
reflect that. If there is something _else_ that in turn links against
Component B - call it Component A - and we want to find out whether
there's a license conflict, we will treat Component B, for license
checking purposes, as if it were LGPLv2+. But, for our purposes, it no
longer is - we can only consider it to be GPLv3. So we may say that
there's no problem with Component A linking against Component B, when
actually there is...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:38 p.m.
On Wed, 2009-08-05 at 11:33 -0700, Adam Williamson wrote:
On Wed, 2009-08-05 at 00:15 -0400, Tom "spot" Callaway
wrote:
> > I should probably talk to Spot about that.
>
> So, the rule here is that we don't take outside linking into effect when
> marking the package's licensing. We go by what the source in the tarball
> tells us. Otherwise, it would become massively too complicated to figure
> it out for a lot of packages.
I see that, but it presents a rather significant problem.
Say we have something whose own license is LGPLv2+ - let's call it
Component B - linking against something whose license is GPLv3
(Component C).
Component B is then effectively GPLv3, but our license tags will not
reflect that. If there is something _else_ that in turn links against
Component B - call it Component A - and we want to find out whether
there's a license conflict, we will treat Component B, for license
checking purposes, as if it were LGPLv2+. But, for our purposes, it no
longer is - we can only consider it to be GPLv3. So we may say that
there's no problem with Component A linking against Component B, when
actually there is...
Apropos, what's the license in case a GPL package links against OpenSSL?
GPL with exceptions or what? Or is it even allowed?
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
2:03 p.m.
On 08/05/2009 02:38 PM, Jussi Lehtola wrote:
Apropos, what's the license in case a GPL package links against
OpenSSL?
GPL with exceptions or what? Or is it even allowed?
So, in this specific case, I'm still arguing with Red Hat Legal, and we
have not determined our final stance.
In the interim, if you have a specific instance of this scenario, you
should ask the upstream of the GPL project to add a linking exception
for OpenSSL, something like:
In addition, as a special exception, <COPYRIGHT HOLDER> gives permission
to link the code of its release of <CODE> with the OpenSSL project's
"OpenSSL" library (or with modified versions of it that use the same
license as the "OpenSSL" library), and distribute the linked
executables. You must obey the GNU General Public License in all
respects for all of the code used other than "OpenSSL". If you modify
this file, you may extend this exception to your version of the file,
but you are not obligated to do so. If you do not wish to do so, delete
this exception.
~spot
2:14 p.m.
On Wed, 2009-08-05 at 15:03 -0400, Tom "spot" Callaway wrote:
On 08/05/2009 02:38 PM, Jussi Lehtola wrote:
> Apropos, what's the license in case a GPL package links against OpenSSL?
> GPL with exceptions or what? Or is it even allowed?
So, in this specific case, I'm still arguing with Red Hat Legal, and we
have not determined our final stance.
In the interim, if you have a specific instance of this scenario, you
should ask the upstream of the GPL project to add a linking exception
for OpenSSL, something like:
In addition, as a special exception, <COPYRIGHT HOLDER> gives permission
to link the code of its release of <CODE> with the OpenSSL project's
"OpenSSL" library (or with modified versions of it that use the same
license as the "OpenSSL" library), and distribute the linked
executables. You must obey the GNU General Public License in all
respects for all of the code used other than "OpenSSL". If you modify
this file, you may extend this exception to your version of the file,
but you are not obligated to do so. If you do not wish to do so, delete
this exception.
If you're feeling extra cynical, Debian does have a defined position on
this; they're on the conservative side of the fence, they don't consider
it acceptable for code licensed under the GPL with no exceptions to link
against OpenSSL. So if you don't want to go to the hassle, and the
package in question is in Debian, just notify the Debian maintainer in
some public fashion (file a bug...) and then they're obliged by Debian's
policies to go to all the trouble for you. Then you can steal their
work. =)
ahh, the joys of open source!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:32 p.m.
Once upon a time, Tom spot Callaway <tcallawa(a)redhat.com> said:
On 08/05/2009 02:38 PM, Jussi Lehtola wrote:
>Apropos, what's the license in case a GPL package links against OpenSSL?
>GPL with exceptions or what? Or is it even allowed?
So, in this specific case, I'm still arguing with Red Hat Legal, and we
have not determined our final stance.
This brings up something I've wondered: if you program to an API where
there are multiple implementations, is your program a derived work of
one of them, the other, or both?
A specific example is OpenSSL and GnuTLS (the OpenSSL compatibility
library). The APIs provided are compatible, so how can changing a link
option from "-lssl -lcrypto" to "-lgnutls-openssl -lgnutls" change
the
license I must use?
This gets even more confusing (to me anyway) when you look at libraries
that are ABI compatible (IIRC LessTif vs. Motif). It is't an issue too
much with LessTif, since it is licensed under LGPL, but what if it was
GPL? Would swapping out the libraries make a program a derived work of
LessTif (and thus fall under the GPL)?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
6:15 p.m.
On Wed, Aug 5, 2009 at 6:32 PM, Chris Adams<cmadams(a)hiwaay.net> wrote:
Once upon a time, Tom spot Callaway <tcallawa(a)redhat.com>
said:
> On 08/05/2009 02:38 PM, Jussi Lehtola wrote:
> >Apropos, what's the license in case a GPL package links against OpenSSL?
> >GPL with exceptions or what? Or is it even allowed?
>
> So, in this specific case, I'm still arguing with Red Hat Legal, and we
> have not determined our final stance.
This brings up something I've wondered: if you program to an API where
there are multiple implementations, is your program a derived work of
one of them, the other, or both?
[snip]
So— you make the matter a lot harder to discuss by taking about "your
program (being) a derived work".
The whole notion of the linking boundary creating a derived work is
unnecessary for copyleft, and trying to apply it adds more confusion
than clarity.
Here is a conceptual framework for analyzing the issue which is pretty
robust against corner cases like the multiple APIs:
The licenses of pagkage X is only relevant when you are
using/distributing package X and can only set the conditions under
which you may use/distribute it. However, the license can stipulate
nearly arbitrary conditions: "Can only make copies of this on
tuesday", "This license is void for copies placed on physical media
which have been stored within 15 feet of a microsoft product", "Only
valid for use by women named 'Bob'", etc. None of these should be
understood as effecting things outside of the software in any kind of
direct way: The license hasn't required you to get a sex and name
change, but rather said you can't use the software unless you do.
So if you create a piece of software that can equally link to X or Y,
and you never use/distribute X yourself you are simply not within
reach of X's licensing terms. If someone else takes your software and
X then sticks them on a CD, then they are obligated to follow X's
license, which may include terms that make depends about the licensing
of other software— ... software that links to it... software on the
same media .... software in the same building ... software that starts
with the same letter. Doesn't matter. Whatever the conditions are,
they are the conditions for using X. If you can't simultaneously
satisfy the requirements of X and the requirements of some other
software package you'll have to stop distributing one or the other or
risk litigation from whomevers requirements you're violating.
8:37 a.m.
On 08/05/2009 07:15 PM, Gregory Maxwell wrote:
So if you create a piece of software that can equally link to X or
Y,
and you never use/distribute X yourself you are simply not within
reach of X's licensing terms. If someone else takes your software and
X then sticks them on a CD, then they are obligated to follow X's
license, which may include terms that make depends about the licensing
of other software— ... software that links to it... software on the
same media .... software in the same building ... software that starts
with the same letter. Doesn't matter. Whatever the conditions are,
they are the conditions for using X. If you can't simultaneously
satisfy the requirements of X and the requirements of some other
software package you'll have to stop distributing one or the other or
risk litigation from whomevers requirements you're violating.
This is another reason why in Fedora, we ensure that linked packages are
compatible, but we don't try to label the license of a package based
upon externally "inherited" licensing.
The concept of what makes up a "derived work" in software is extremely
complicated, and widely disputed, depending upon who you ask. There is
also not a lot of case law in the US that would help provide
clarification on how the courts would interpret things. The FSF is
rather outspoken in their opinion that all linking creates a shared
work, but that is simply their opinion. I would argue that there are
probably many situations like the one Chris described where the software
could clearly be argued to not be a derived work of either "crypto" API,
or when a dependent library can be easily replaced with an ABI
compatible alternative (either with a recompile or without). What if an
application dlopens another library to use it?
At the end of the day, the answer that any lawyer worth talking to will
give you is that it depends on the specifics of the situation at hand.
Red Hat Legal is comfortable with the general policies that we've
adopted in Fedora, which is to ensure that there is license
compatibility across shared library linking, with the exception of
"System Libraries". (I'm in the middle of trying to convince them that
OpenSSL consists of a "system library" at this point, but we still
haven't decided whether we're going to adopt that stance or not)
~spot
1:13 p.m.
On Friday 31 July 2009, Adam Williamson wrote:
ahhh, licensing! Spot will likely have better thoughts on all of
this,
plus thoughts on the other license compatibility stuff. I don't think
MIT / BSD licensed stuff has any problem linking against GPL stuff
(unless it's under the _original_ BSD license, with the advertising
clause). Not sure about QPL or LPPL. Public Domain obviously has no
problems.
Depends on what one thinks is a problem and what not, but FWIW I definitely
consider it a problem. Due to GPL's viral nature, I'm fairly certain that the
end result of linking something licensed using the above is a combined work
which is either GPL'd, or a violation of the GPL or the original (MIT, BSD
etc) license.
5377
days inactive
5384
days old
16 comments
7 participants
participants (7)
-
Adam Williamson -
Chris Adams -
Gregory Maxwell -
Susi Lehtola -
Tim Waugh -
Tom Callaway -
Ville Skyttä