Re: License change for ghostscript
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
On Wed, Aug 5, 2009 at 6:32 PM, Chris Adams wrote: > Once upon a time, Tom spot Callaway 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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
Once upon a time, Tom spot Callaway 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 Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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, gives permission > to link the code of its release of 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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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, gives permission to link the code of its release of 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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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 jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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.)
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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.
*/
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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.
*/
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
License change for ghostscript
Beginning with the 8.70 release, Ghostscript will be licensed as GPLv3+. Tim. */ signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
