Hi,
CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups@cups.org .
Is there someone who is influenced by this change?
On 8 November 2017 at 09:42, Zdenek Dohnal zdohnal@redhat.com wrote:
CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd= Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups@cups.org .
Is there someone who is influenced by this change?
Sounds like pycups may need to change license as a result: https://github.com/zdohnal/pycups/blob/master/cupsconnection.c#L8-L9
Tim. */
On Wed, Nov 8, 2017 at 10:42 AM, Zdenek Dohnal zdohnal@redhat.com wrote:
Hi,
CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups@cups.org .
Is there someone who is influenced by this change?
Therefore it should not affect dynamic-linking situations against libcups, right?
-- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Nov 8, 2017 at 7:39 AM, Felipe Borges feborges@redhat.com wrote:
On Wed, Nov 8, 2017 at 10:42 AM, Zdenek Dohnal zdohnal@redhat.com wrote:
Hi,
CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups@cups.org .
Is there someone who is influenced by this change?
Therefore it should not affect dynamic-linking situations against libcups, right?
It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not link to the newer version.
On Wed, Nov 8, 2017 at 1:45 PM, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Nov 8, 2017 at 7:39 AM, Felipe Borges feborges@redhat.com wrote:
On Wed, Nov 8, 2017 at 10:42 AM, Zdenek Dohnal zdohnal@redhat.com wrote:
Hi,
CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses ) or try to argument with CUPS developers against this change on their mailing list cups@cups.org .
Is there someone who is influenced by this change?
Therefore it should not affect dynamic-linking situations against libcups, right?
It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not link to the newer version.
Is dynamic linking "legally" considered some sort of derivative work? If that's the case I can think of cups-pk-helper, gnome-control-center, gtk+ (the print dialog), etc...
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Nov 08, 2017 at 07:45:28AM -0500, Neal Gompa wrote:
It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not link to the newer version.
That will seriously affect Gutenprint if applied strictly.
OTOH, Gutenprint is GPLv2+, so it could be considered GPLv3 for purposes of linking to ASL2.0 CUPS..
- Solomon
On Wed, Nov 08, 2017 at 08:32:50AM -0500, Solomon Peachy wrote:
On Wed, Nov 08, 2017 at 07:45:28AM -0500, Neal Gompa wrote:
It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not link to the newer version.
That will seriously affect Gutenprint if applied strictly.
OTOH, Gutenprint is GPLv2+, so it could be considered GPLv3 for purposes of linking to ASL2.0 CUPS..
Just make sure that Gutenprint doesn't link to any other 3rd party libs that are GPLv2-only - everything it links to would need to be v2-or-later (or otherwise GPLv3 compatible) to allow the combined work to be considered GPLv3
Regards, Daniel
On Wed, Nov 08, 2017 at 01:38:31PM +0000, Daniel P. Berrange wrote:
OTOH, Gutenprint is GPLv2+, so it could be considered GPLv3 for purposes of linking to ASL2.0 CUPS..
Just make sure that Gutenprint doesn't link to any other 3rd party libs that are GPLv2-only - everything it links to would need to be v2-or-later (or otherwise GPLv3 compatible) to allow the combined work to be considered GPLv3
Yeah, it's a headache.
The gutenprint CUPS filters in my dev tree dynamically pull in 41 shared libraries, mostly as passthroughs. I'm auditing them now.
Meanwhile, I've raised this concern on the Gutenprint mailing list and we'll see how the conversation goes.
- Solomon [Heavily involved with Gutenprint BTW]
On Wed, Nov 8, 2017 at 8:51 AM, Solomon Peachy pizza@shaftnet.org wrote:
On Wed, Nov 08, 2017 at 01:38:31PM +0000, Daniel P. Berrange wrote:
OTOH, Gutenprint is GPLv2+, so it could be considered GPLv3 for purposes of linking to ASL2.0 CUPS..
Just make sure that Gutenprint doesn't link to any other 3rd party libs that are GPLv2-only - everything it links to would need to be v2-or-later (or otherwise GPLv3 compatible) to allow the combined work to be considered GPLv3
Yeah, it's a headache.
The gutenprint CUPS filters in my dev tree dynamically pull in 41 shared libraries, mostly as passthroughs. I'm auditing them now.
Meanwhile, I've raised this concern on the Gutenprint mailing list and we'll see how the conversation goes.
Is there anyone who could raise concerns to Apple about the license change? Maybe convince them to dual-license it or something?
On Wed, Nov 08, 2017 at 08:54:03AM -0500, Neal Gompa wrote:
Is there anyone who could raise concerns to Apple about the license change? Maybe convince them to dual-license it or something?
Well, Michael Sweet (mswet AT apple.com) remains the primary developer of CUPS, and this has been raised on the CUPS mailing list in response to the announcement he posted.
Here's the latest response [1] on that thread:
I don't think static linking against libcups is common enough to be a serious concern - CUPS is fairly ubiquitous and easily falls under the "OS-supplied library" exception in the GPL 2. And existing GPL-2-only software that *does* statically link/copy CUPS code can continue to do so with CUPS 2.2.x and earlier.
[1] https://lists.cups.org/pipermail/cups-devel/2017-November/017088.html
- Solomon
On Wed, Nov 08, 2017 at 08:51:22AM -0500, Solomon Peachy wrote:
The gutenprint CUPS filters in my dev tree dynamically pull in 41 shared libraries, mostly as passthroughs. I'm auditing them now.
FWIW, everything that gutenprint links against, and everything they pull in, appears to be compatible with the notion "treat Gutenprint as GPLv3+" for purposes of linking against libcups.
...Assuming the Fedora 26 rpm database's license tags are accurate. :)
(I can't speak for things that link against gutenprint itself)
Meanwhile, I've raised this concern on the Gutenprint mailing list and we'll see how the conversation goes.
So far, the concensus is that this doesn't appear to matter today (thanks to the ability to implicitly promote the GPLv2+ to v3) but it interferes with future plans. It's still being discussed.
- Solomon
Hi,
On 08-11-17 15:06, Solomon Peachy wrote:
On Wed, Nov 08, 2017 at 08:54:03AM -0500, Neal Gompa wrote:
Is there anyone who could raise concerns to Apple about the license change? Maybe convince them to dual-license it or something?
Well, Michael Sweet (mswet AT apple.com) remains the primary developer of CUPS, and this has been raised on the CUPS mailing list in response to the announcement he posted.
Here's the latest response [1] on that thread:
I don't think static linking against libcups is common enough to be a serious concern - CUPS is fairly ubiquitous and easily falls under the "OS-supplied library" exception in the GPL 2. And existing GPL-2-only software that *does* statically link/copy CUPS code can continue to do so with CUPS 2.2.x and earlier.
Someone should reply to that that the OS exception only applies when distributing binaries separate from said OS, not for binaries bundled with the OS, which all Linux distros are (AFAIK, IANAL).
IMHO some sort of ASL / LGPL dual license would be best (if upstream is willing to make such a change).
Regards,
Hans
I have many questions here.
Isn't this going to require relicensing a humongous number of applications? We can't plausibly relicense so much. We would have to remove printing support from GTK+, which is not going to happen.
The system library exception might work for Fedora, but it would be unfair for us to accept a solution that likely won't work for our other friends in the free software ecosystem.
Any idea why upstream seems to think we don't have to follow the license if we use dynamic linking? It seems unlikely that this is accurate, right?
Can upstream be persuaded to go with a BSD or MIT style license instead, to avoid causing unnecessary problems for the free software community?
Do we need to fork CUPS now?
Michael
On Wed, Nov 08, 2017 at 03:53:32PM +0100, Hans de Goede wrote:
I don't think static linking against libcups is common enough to be a serious concern - CUPS is fairly ubiquitous and easily falls under the "OS-supplied library" exception in the GPL 2. And existing GPL-2-only software that *does* statically link/copy CUPS code can continue to do so with CUPS 2.2.x and earlier.
Someone should reply to that that the OS exception only applies when distributing binaries separate from said OS, not for binaries bundled with the OS, which all Linux distros are (AFAIK, IANAL).
I'm willing to reply to this, but before I (or anyone else) does so, I think it highly prudent to have fedora-legal weigh in first.
IMHO some sort of ASL / LGPL dual license would be best (if upstream is willing to make such a change).
Agreed, but even if the CUPS authors are personally in favor of this I suspect that it will never happen, given Apple's heavy anti-GPL bias.
- Solomon
On 08.11.2017 15:53, Hans de Goede wrote:
Hi,
On 08-11-17 15:06, Solomon Peachy wrote:
On Wed, Nov 08, 2017 at 08:54:03AM -0500, Neal Gompa wrote:
Is there anyone who could raise concerns to Apple about the license change? Maybe convince them to dual-license it or something?
Well, Michael Sweet (mswet AT apple.com) remains the primary developer of CUPS, and this has been raised on the CUPS mailing list in response to the announcement he posted.
Here's the latest response [1] on that thread:
I don't think static linking against libcups is common enough to be a serious concern - CUPS is fairly ubiquitous and easily falls under the "OS-supplied library" exception in the GPL 2. And existing GPL-2-only software that *does* statically link/copy CUPS code can continue to do so with CUPS 2.2.x and earlier.
Someone should reply to that that the OS exception only applies when distributing binaries separate from said OS, not for binaries bundled with the OS, which all Linux distros are (AFAIK, IANAL).
apparently Fedora Legal FAQ has a different opinion:
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_d...
"However, we consider that the OpenSSL library is a system library, as defined by the GPL, on Fedora and therefore we are allowed to ship GPL software that links to the OpenSSL library."
On Wed, Nov 8, 2017 at 9:53 AM, Michael Catanzaro mike.catanzaro@gmail.com wrote:
I have many questions here.
Isn't this going to require relicensing a humongous number of applications? We can't plausibly relicense so much. We would have to remove printing support from GTK+, which is not going to happen.
The system library exception might work for Fedora, but it would be unfair for us to accept a solution that likely won't work for our other friends in the free software ecosystem.
Any idea why upstream seems to think we don't have to follow the license if we use dynamic linking? It seems unlikely that this is accurate, right?
Can upstream be persuaded to go with a BSD or MIT style license instead, to avoid causing unnecessary problems for the free software community?
I suspect they want the patent termination clauses. In this age of software patent tomfoolery, I wouldn't blame them. Unfortunately, Apple has an utter hatred of licenses that enforce reciprocity, and it goes even further with licenses that prevent closed devices (aka GNU v3 license family).
Do we need to fork CUPS now?
I don't like this thought, but if this can't be resolved well, then a fork might be needed. Ideally, if they could be convinced of LGPLv2+ or ASL 2.0, then I think everyone would be satisfied.
Hi,
On 08-11-17 16:06, Solomon Peachy wrote:
On Wed, Nov 08, 2017 at 03:53:32PM +0100, Hans de Goede wrote:
I don't think static linking against libcups is common enough to be a serious concern - CUPS is fairly ubiquitous and easily falls under the "OS-supplied library" exception in the GPL 2. And existing GPL-2-only software that *does* statically link/copy CUPS code can continue to do so with CUPS 2.2.x and earlier.
Someone should reply to that that the OS exception only applies when distributing binaries separate from said OS, not for binaries bundled with the OS, which all Linux distros are (AFAIK, IANAL).
I'm willing to reply to this, but before I (or anyone else) does so, I think it highly prudent to have fedora-legal weigh in first.
Right, good idea, as Michal Stahl pointed out: https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_d... indicates that fedora-legal does consider the "OS-supplied library" exception to apply to Fedora pkgs, so it seems I'm wrong here.
Regards,
Hans
On Wed, Nov 08, 2017 at 04:17:20PM +0100, Hans de Goede wrote:
Hi,
On 08-11-17 16:06, Solomon Peachy wrote:
On Wed, Nov 08, 2017 at 03:53:32PM +0100, Hans de Goede wrote:
I don't think static linking against libcups is common enough to be a serious concern - CUPS is fairly ubiquitous and easily falls under the "OS-supplied library" exception in the GPL 2. And existing GPL-2-only software that *does* statically link/copy CUPS code can continue to do so with CUPS 2.2.x and earlier.
Someone should reply to that that the OS exception only applies when distributing binaries separate from said OS, not for binaries bundled with the OS, which all Linux distros are (AFAIK, IANAL).
I'm willing to reply to this, but before I (or anyone else) does so, I think it highly prudent to have fedora-legal weigh in first.
Right, good idea, as Michal Stahl pointed out: https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_d... indicates that fedora-legal does consider the "OS-supplied library" exception to apply to Fedora pkgs, so it seems I'm wrong here.
Well that page only refers to OpenSSL and even then it points out that other distros have differing opinions. Personally I think it is dubious even for OpenSSL, and if you start broadening it further to claim it applies to what are effectively application level libiraries like libcups, where does it end ? You could just claim it applies to any widely used library in Fedora, at which point you're effectively just trying to nullify all licensing rules, whichs is not acceptable IMHO.
Regards, Daniel
On Wed, Nov 08, 2017 at 03:25:22PM +0000, Daniel P. Berrange wrote:
Well that page only refers to OpenSSL and even then it points out that other distros have differing opinions. Personally I think it is dubious even for OpenSSL, and if you start broadening it further to claim it applies to what are effectively application level libiraries like libcups, where does it end ? You could just claim it applies to any widely used library in Fedora, at which point you're effectively just trying to nullify all licensing rules, whichs is not acceptable IMHO.
I've bumped this over to the legal mailing list [1]. We'll see what their far more knowledgable heads have to say.
[1] https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
- Solomon
I'll try to convince Mike to make a dual license.
On 11/08/2017 04:34 PM, Solomon Peachy wrote:
On Wed, Nov 08, 2017 at 03:25:22PM +0000, Daniel P. Berrange wrote:
Well that page only refers to OpenSSL and even then it points out that other distros have differing opinions. Personally I think it is dubious even for OpenSSL, and if you start broadening it further to claim it applies to what are effectively application level libiraries like libcups, where does it end ? You could just claim it applies to any widely used library in Fedora, at which point you're effectively just trying to nullify all licensing rules, whichs is not acceptable IMHO.
I've bumped this over to the legal mailing list [1]. We'll see what their far more knowledgable heads have to say.
[1] https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
- Solomon
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Here is reply from CUPS mailing list:
On 11/08/2017 08:58 PM, Michael Sweet wrote:
Zdenek,
On Nov 8, 2017, at 11:11 AM, Zdenek Dohnal zdohnal@redhat.com wrote: ... would you mind considering dual license - Apache License 2.0 and GPLv2+? Because "OS-supplied library" definition is relative and it could end up that any widely used library can be exception (not mention widely used libraries differs across distributions - so library would be count as "OS-supplied library" on one distro and not on a other) - and that will lead into nullifying existing licensing rules.
IANAL and am not comfortable getting into a legal debate about what constitutes an OS-supplied library or whether GPL2-only software can "legally" link against libcups. But as an example, CUPS had to deal with this when linking against OpenSSL in the past by adding an exception to the license file saying "it is OK to link CUPS against OpenSSL"... I don't see why that approach would not work for any GPLv2-only project, if there was any question about CUPS being a standard OS library after almost 20 years of use...
Anyways, I can certainly forward your dual-licensing request to the appropriate people at Apple, but I'm sure they will want to know which projects/applications you think will be unable to continue using CUPS, and why.
Thanks!
Michael Sweet, Senior Printing System Engineer
cups-devel mailing list cups-devel@cups.org https://lists.cups.org/mailman/listinfo/cups-devel
AFAIK such projects are gutenprint, cups-filters or hplip... does anyone have in mind other projects, which will be unable to use CUPS and reason?
On Wed, Nov 8, 2017 at 3:16 PM, Zdenek Dohnal zdohnal@redhat.com wrote:
AFAIK such projects are gutenprint, cups-filters or hplip... does anyone have in mind other projects, which will be unable to use CUPS and reason?
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
On Wed, Nov 08, 2017 at 09:16:23PM +0100, Zdenek Dohnal wrote:
AFAIK such projects are gutenprint, cups-filters or hplip... does anyone have in mind other projects, which will be unable to use CUPS and reason?
Gutenprint today is okay, as only its CUPS filters/backend link against CUPS and its GPLv2+ license can be treated as v3 to make it all kosher. None of the other Gutenprint compoents (eg libgutenprint, libgutenprintui) currently link against CUPS.
That said, it's likely there are applications out there that directly link to both libgutenprint and libcups.
(This also throws a wrench into some future plans. Discussions are ongoing)
- Solomon
On Wed, Nov 8, 2017 at 2:43 PM, Neal Gompa ngompa13@gmail.com wrote:
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
GTK+
On 11/08/2017 09:43 PM, Neal Gompa wrote:
On Wed, Nov 8, 2017 at 3:16 PM, Zdenek Dohnal zdohnal@redhat.com wrote:
AFAIK such projects are gutenprint, cups-filters or hplip... does anyone have in mind other projects, which will be unable to use CUPS and reason?
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
I didn't find out who maintains libkprint in Fedora, but I found kde-print-manager's maintainer - rdieter (adding him to CC). Rex, would you mind commenting this change?
Adding gtk+ maintainer. Paul, would you mind commenting about this issue?
On 11/09/2017 01:07 AM, Michael Catanzaro wrote:
On Wed, Nov 8, 2017 at 2:43 PM, Neal Gompa ngompa13@gmail.com wrote:
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
GTK+ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Zdenek Dohnal wrote:
On 11/08/2017 09:43 PM, Neal Gompa wrote:
On Wed, Nov 8, 2017 at 3:16 PM, Zdenek Dohnal zdohnal@redhat.com wrote:
AFAIK such projects are gutenprint, cups-filters or hplip... does anyone have in mind other projects, which will be unable to use CUPS and reason?
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
I didn't find out who maintains libkprint in Fedora, but I found kde-print-manager's maintainer - rdieter (adding him to CC). Rex, would you mind commenting this change?
I'm of a mind to urge that cups be considered a system library (as it's upstream also argues)
-- Rex
Zdenek Dohnal wrote:
On 11/08/2017 09:43 PM, Neal Gompa wrote:
On Wed, Nov 8, 2017 at 3:16 PM, Zdenek Dohnal zdohnal@redhat.com wrote:
AFAIK such projects are gutenprint, cups-filters or hplip... does anyone have in mind other projects, which will be unable to use CUPS and reason?
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
I didn't find out who maintains libkprint in Fedora, but I found kde-print-manager's maintainer - rdieter (adding him to CC). Rex, would you mind commenting this change?
Also, kde-print-manager *should* be license compatible (can be shipped as GPLv3) Haven't thoroughly checked though.
-- Rex
Rex, would you mind reporting this change to upstream, if kde-print-manager has incompatible license?
On 11/09/2017 02:38 PM, Rex Dieter wrote:
Zdenek Dohnal wrote:
On 11/08/2017 09:43 PM, Neal Gompa wrote:
On Wed, Nov 8, 2017 at 3:16 PM, Zdenek Dohnal zdohnal@redhat.com wrote:
AFAIK such projects are gutenprint, cups-filters or hplip... does anyone have in mind other projects, which will be unable to use CUPS and reason?
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
I didn't find out who maintains libkprint in Fedora, but I found kde-print-manager's maintainer - rdieter (adding him to CC). Rex, would you mind commenting this change?
Also, kde-print-manager *should* be license compatible (can be shipped as GPLv3) Haven't thoroughly checked though.
-- Rex _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Nov 09, 2017 at 07:30:39AM -0600, Rex Dieter wrote:
kde-print-manager's maintainer - rdieter (adding him to CC). Rex, would you mind commenting this change?
I'm of a mind to urge that cups be considered a system library (as it's upstream also argues)
Possibly this is something we could formally define with Modularity. (That is, all libraries in Platform & Host are "system libraries")?
On Thu, Nov 09, 2017 at 12:23:33PM -0500, Matthew Miller wrote:
I'm of a mind to urge that cups be considered a system library (as it's upstream also argues)
Possibly this is something we could formally define with Modularity. (That is, all libraries in Platform & Host are "system libraries")?
Leaving aside "applications" for now -- What about the case where one of those "system libraries" (say, GTK+) directly depends on another "system library" (say, libcups) which now sports an incompatible license?
Because that's the problem we're actually facing here...
- Solomon
On Wed, 2017-11-08 at 18:07 -0600, Michael Catanzaro wrote:
On Wed, Nov 8, 2017 at 2:43 PM, Neal Gompa ngompa13@gmail.com wrote:
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
GTK+
For GTK+, one possible answer is to rely on the flatpak print portal, which moves the cups interaction out of process. It still requires to figure out a way how to use a gtk with cups support in the portal process.
Once upon a time, Solomon Peachy pizza@shaftnet.org said:
Leaving aside "applications" for now -- What about the case where one of those "system libraries" (say, GTK+) directly depends on another "system library" (say, libcups) which now sports an incompatible license?
Because that's the problem we're actually facing here...
I know zero about CUPS, its internals, and how things work between the client library and the service, but just throwing this out there... would it be feasible to continue to use an older client library with a newer service? Basically like the way MySQL was handled for a while due to its license.
I'm guessing probably not, but just thought I'd mention it.
On 2017-11-09 07:27, Zdenek Dohnal wrote:
Adding gtk+ maintainer. Paul, would you mind commenting about this issue?
On 11/09/2017 01:07 AM, Michael Catanzaro wrote:
On Wed, Nov 8, 2017 at 2:43 PM, Neal Gompa ngompa13@gmail.com wrote:
libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though.
gtk+ isn't linked with cups. However, gtk2 and gtk3 are. Should probably ask Matthias, who maintains the non-legacy gtk libraries.
Cheers, Paul.
Sorry for late bringing up this topic, for whose do not know, Tom answered on Solomon question about new CUPS licensing in:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
To sum it up (from what I understood):
Projects under GPLv2+ are compatible, LGPL, LGPLv2 and LGPLv3 too. In case of GPLv2 only upstream opinion matters and Mike as upstream said CUPS falls under "OS-supplied library", so SWs, which have CUPS dynamically linked, are license compatible.
So project under GPLv2+ and compatible are okay, GPLv2 only should change license or add into license file sentence mentioning about that's okay to link against CUPS, because it is OS-supplied library.
On Wed, 2017-11-08 at 10:42 +0100, Zdenek Dohnal wrote:
Hi,
CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLi censes ) or try to argument with CUPS developers against this change on their mailing list cups@cups.org .
Is there someone who is influenced by this change?
My apologies fr the late response: I have been pretty busy. cups-bjnp was affected as it was GPLv2 only. In versiob 2.0.1 It is now changed to be GPLv2 or later. The new package has been built for Rawhide and f28.
/Louis
On 11/08/2017 01:45 PM, Neal Gompa wrote:
It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not link to the newer version.
On the other hand, libgcc switched to GPLv3+ with exceptions (but those exceptions do not restore GPLv2 compatibility), so under this strict interpretation, we could not ship any GPLv2 userspace software anyway.
So I wonder if we can just declare CUPS a system library and move on.
(It would be a different matter if CUPS itself depended on GPLv2 components. I have not checked that.)
Thanks, Florian
On 11/08/2017 04:25 PM, Daniel P. Berrange wrote:
Well that page only refers to OpenSSL and even then it points out that other distros have differing opinions. Personally I think it is dubious even for OpenSSL, and if you start broadening it further to claim it applies to what are effectively application level libiraries like libcups, where does it end ? You could just claim it applies to any widely used library in Fedora, at which point you're effectively just trying to nullify all licensing rules, whichs is not acceptable IMHO.
We ship source for everything which runs in userspace, and everything is under free software licenses, so I'm not particularly concerned that what we do is evading license terms, especially as far as the big picture is concerned.
The broad interpretation of system libraries simply ensures that Fedora has the same rights the FSF has granted to proprietary operating system vendors, and the same rights as ISVs building software on top of Fedora. The weakening is already part of the license, and it's not up to us to change that.
Thanks, Florian
Thanks Louis!
On 02/21/2018 11:15 PM, Louis Lagendijk wrote:
On Wed, 2017-11-08 at 10:42 +0100, Zdenek Dohnal wrote:
Hi,
CUPS upstream changed license of project to Apache license 2.0, which is now incompatible with GPLv2. This change will be in new minor release of CUPS - 2.3.0, which is currently in developing phase (not in Fedora for now). If someone takes code of CUPS and has its project under GPLv2, please change it to GPLv3 (which should be compatible according https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLi censes ) or try to argument with CUPS developers against this change on their mailing list cups@cups.org .
Is there someone who is influenced by this change?
My apologies fr the late response: I have been pretty busy. cups-bjnp was affected as it was GPLv2 only. In versiob 2.0.1 It is now changed to be GPLv2 or later. The new package has been built for Rawhide and f28.
/Louis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On 02/26/2018 10:41 AM, Florian Weimer wrote:
On 11/08/2017 01:45 PM, Neal Gompa wrote:
It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not link to the newer version.
On the other hand, libgcc switched to GPLv3+ with exceptions (but those exceptions do not restore GPLv2 compatibility), so under this strict interpretation, we could not ship any GPLv2 userspace software anyway.
So I wonder if we can just declare CUPS a system library and move on.
Solomon asked about the issue on legal list https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/... . I concluded from Tom's comment that even declaring CUPS as OS-supplied library needs to be documented in a way (not mention this isn't solution which Debian/Ubuntu would approve). I presented both Tom's solutions (mentioned in his email) to Mike on cups-devel mailing list+github issue, but without any decision yet (pinged him during beta and release candidate). It's sad - I will not package cups 2.3 for Fedora until it is solved...
Github issue: https://github.com/apple/cups/issues/5174
(It would be a different matter if CUPS itself depended on GPLv2 components. I have not checked that.)
I checked requirements in spec - CUPS doesn't need any GPLv2only component for building nor linking.
Thanks, Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, Feb 26, 2018 at 4:43 AM, Zdenek Dohnal zdohnal@redhat.com wrote:
On 02/26/2018 10:41 AM, Florian Weimer wrote:
On 11/08/2017 01:45 PM, Neal Gompa wrote:
It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not link to the newer version.
On the other hand, libgcc switched to GPLv3+ with exceptions (but those exceptions do not restore GPLv2 compatibility), so under this strict interpretation, we could not ship any GPLv2 userspace software anyway.
So I wonder if we can just declare CUPS a system library and move on.
Solomon asked about the issue on legal list https://lists.fedoraproject.org/archives/list/legal@lists. fedoraproject.org/thread/TYGLR34XR6L6MAXMVSDNYT3ZYXUKY7FX/ . I concluded from Tom's comment that even declaring CUPS as OS-supplied library needs to be documented in a way (not mention this isn't solution which Debian/Ubuntu would approve). I presented both Tom's solutions (mentioned in his email) to Mike on cups-devel mailing list+github issue, but without any decision yet (pinged him during beta and release candidate). It's sad - I will not package cups 2.3 for Fedora until it is solved...
I must be missing something.... what is sad? It has been stated that CUPS does not need any GPLv2 only component for building or linking. Tom's comment stated:
"Thus, pretty much everyone is in agreement that GPLv3 + Apache 2.0 is a fine combination. If the combination is GPLv2 or later, then you can resolve any concerns about compatibility between GPLv2 and Apache 2.0 by using the GPLv3 license in situations where that work is combined with an Apache 2.0 work."
and
"As far as LGPL compatibility goes, because the LGPL provides permission for anyone to use the LGPL work under the terms of the GPL (section 3 of the LGPLv2 and section 2.b of the LGPLv3). LGPLv2 permits the terms of GPLv2 or GPLv3 (or any future version of GPL) to be applied in place of the LGPLv2 terms. LGPLv3 permits the terms of GPLv3 to be applied in place of the LGPLv3 terms. Thus, LGPLv2 + Apache 2.0 _and_ LGPLv3 + Apache 2.0 are considered compatible."
So what's the issue?
Hi Gerald,
I'll try to explain how I understood it:
On 02/26/2018 03:45 PM, Gerald B. Cox wrote:
I must be missing something.... what is sad? It has been stated that CUPS does not need any GPLv2 only component for building or linking.
The issue is about packages, which have GPLv2only license and they need CUPS libraries for building or linking.
Tom's comment stated:
"Thus, pretty much everyone is in agreement that GPLv3 + Apache 2.0 is a fine combination. If the combination is GPLv2 or later, then you can resolve any concerns about compatibility between GPLv2 and Apache 2.0 by using the GPLv3 license in situations where that work is combined with an Apache 2.0 work."
and
"As far as LGPL compatibility goes, because the LGPL provides permission for anyone to use the LGPL work under the terms of the GPL (section 3 of the LGPLv2 and section 2.b of the LGPLv3). LGPLv2 permits the terms of GPLv2 or GPLv3 (or any future version of GPL) to be applied in place of the LGPLv2 terms. LGPLv3 permits the terms of GPLv3 to be applied in place of the LGPLv3 terms. Thus, LGPLv2 + Apache 2.0 _and_ LGPLv3 + Apache 2.0 are considered compatible."
So what's the issue?
I think the problem's description lies lower in Tom's email - begins "So, that leaves us with GPL version 2 (only) and Apache 2.0. In this scenario, it is worth noting a few things:"
AA. Fedora is not (at this time) concerned about license compatibility issues arising from the relicensing of CUPS to Apache 2.0, in as much as this applies to linking of components together (our use case).
BB. If you are planning on (or have) copying code from CUPS and including it in a GPLv2 only licensed work, seek legal counsel, that is a more complicated scenario that Fedora does not face right now (as far as I know).
On Tue, Feb 27, 2018 at 3:43 AM, Zdenek Dohnal zdohnal@redhat.com wrote:
On 02/26/2018 03:45 PM, Gerald B. Cox wrote:
I must be missing something.... what is sad? It has been stated that CUPS does not need any GPLv2 only component for building or linking.
The issue is about packages, which have GPLv2only license and they need CUPS libraries for building or linking.
Tom's comment stated:
"Thus, pretty much everyone is in agreement that GPLv3 + Apache 2.0 is a fine combination. If the combination is GPLv2 or later, then you can resolve any concerns about compatibility between GPLv2 and Apache 2.0 by using the GPLv3 license in situations where that work is combined with an Apache 2.0 work."
and
"As far as LGPL compatibility goes, because the LGPL provides permission for anyone to use the LGPL work under the terms of the GPL (section 3 of the LGPLv2 and section 2.b of the LGPLv3). LGPLv2 permits the terms of GPLv2 or GPLv3 (or any future version of GPL) to be applied in place of the LGPLv2 terms. LGPLv3 permits the terms of GPLv3 to be applied in place of the LGPLv3 terms. Thus, LGPLv2 + Apache 2.0 _and_ LGPLv3 + Apache 2.0 are considered compatible."
So what's the issue?
I think the problem's description lies lower in Tom's email - begins "So, that leaves us with GPL version 2 (only) and Apache 2.0. In this scenario, it is worth noting a few things:"
Thanks for the reply. To me however, Tom's summary indicates this isn't really an issue for Fedora and shouldn't hamper the packaging of CUPS 2.3 - As he concludes:
AA. Fedora is not (at this time) concerned about license compatibility issues arising from the relicensing of CUPS to Apache 2.0, in as much as this applies to linking of components together (our use case).
BB. If you are planning on (or have) copying code from CUPS and including it in a GPLv2 only licensed work, seek legal counsel, that is a more complicated scenario that Fedora does not face right now (as far as I know).
As I understand the issue - this is only related to a few projects that are GPLv2 and are using CUPS in such a way that causes license issues. If that is the case they should simply change their license to GPLv2 or later. It's that simple. In other words, the onus to fix the issue lies with the projects that are using GPLv2 - not CUPS. If they don't want to change their license, going forward they shouldn't be using cups.
On 02/27/2018 03:22 PM, Gerald B. Cox wrote:
AA. Fedora is not (at this time) concerned about license compatibility issues arising from the relicensing of CUPS to Apache 2.0, in as much as this applies to linking of components together (our use case).
BB. If you are planning on (or have) copying code from CUPS and including it in a GPLv2 only licensed work, seek legal counsel, that is a more complicated scenario that Fedora does not face right now (as far as I know).
Then I don't quite get A. paragraph, where Tom talks about requirements which need to be done. Tom, would you mind clarify it for me, please?
As I understand the issue - this is only related to a few projects that are GPLv2 and are using CUPS in such a way that causes license issues. If that is the case they should simply change their license to GPLv2 or later.
That's the issue - change of license needs mutual agreement of project owner and all contributors, whose made significant contribution into project (AFAIK) . And it can be difficult.
It's that simple. In other words, the onus to fix the issue lies with the projects that are using GPLv2 - not CUPS. If they don't want to change their license, going forward they shouldn't be using cups.
Yes, I can package cups 2.3 for Fedora, but I don't want to create additional work for packagers, whose components depend on CUPS, without clear steps what to do when their package is GPLv2 only - because it is not clearly clarified by upstream yet.
I would like to package new cups when I can clearly say - "Hi, CUPS moved to Apache 2.0 license in 2.3.0 version, which is incompatible with GPLv2 only. Packages which are GPLv2 only needs to be re-licensed, there is only way.".
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
devel@lists.stg.fedoraproject.org
-
Chris Adams -
Daniel P. Berrange -
Felipe Borges -
Florian Weimer -
Gerald B. Cox -
Hans de Goede -
Louis Lagendijk -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Michael Stahl -
Neal Gompa -
Paul Howarth -
Rex Dieter -
Solomon Peachy -
Tim Waugh -
Zdenek Dohnal