Re: CUPS GPL → Apache license change, how to proceed?

2018-02-19 Thread Ian Jackson
(Adding d-legal)

Didier 'OdyX' Raboud writes ("CUPS GPL → Apache license change, how to 
proceed?"):
> tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to
> "Apache-2.0"; how should the license incompatibilities be enforced?

This reply is going to be annoying, I fear:

> Some questions at this point (Some for FTP Masters, CC'ed):
> - Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking 
> is unacceptable for Debian main?  In both directions?

I think the answer is "yes, we think that is unacceptable".

ftpmaster seem rarely to reply to these kind of questions.  If you
actually want the answer, I suggest you:
 - search for existing cases and see if they got REJECTed or ACCEPTted
 - upload and see
:-/

> - Can CUPS link against GPL-2-only code?
> - Can GPL-2-only code link against CUPS?

I don't understand how these are different to the previous question.

> - Whose reponsibility is it to check for these incompatibilities, and make 
> sure they are not shipped in Debian?

I think (and this is my personal opinion) that a licence
incompatibility is a bug in the depending package, and it is the
responsibility of the depending package maintainer.

> - What tools should I be using to identify which of these will be
> undistributable constructs?

I'm not aware of any useful tools and I hope someone else will be
able to help.

>  Aka: how, given a list of source
> packages, can I determine which are GPL-2-only in the codepaths that
> link against CUPS?  - What fields could I / should I use in src:cups
> to enforce these?  I was initially thinking of setting versionless
> Breaks: in each src:cups' library against the identified GPL-2-only
> culprits, then mass-filing bugs against these, promising to add
> version constraints when/if the licensing issue gets lifted. Does
> that sound like a good way forward?

I guess.  It seems like a lot of work, and the cups transition would
be blocked.

You might instead consider simply filing bugs against the
dependencies, and setting a deadline by which they will be escalated
to RC.  You will want to discuss this with the release team.

Good luck.

Ian.



CUPS GPL → Apache license change, how to proceed?

2018-02-13 Thread Didier 'OdyX' Raboud
tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to "Apache-2.0"; how 
should the license incompatibilities be enforced?


As you might have heard [lwn][cups-apache], Apple has changed the CUPS license 
away from a "GPL-2/LGPL-2 with exceptions" to plain Apache-2.0, effective in 
the 2.3 branch [23branch] and available from 2.3~b1 on [23b1].

Despite bold attempts from Fedora and Debian community members to try 
clarifying what issues this change causes and the incompatibilities it 
creates, Apple has, so far, unsurprisingly not changed CUPS' license.

The principal issue, as I understand it, is that the Apache-2.0 license is 
incompatible with GPL-2 [apache-gpl2], although compatible with GPL-3 
(therefore compatible with GPL-2+, and with LGPL through LGPL→GPL-3).  See the 
lengthy explanation by Tom Callaway on Fedora's legal list [fedora-tom].

Further, it is my (current) understanding that having Apache-2.0 software (for 
instance, CUPS) in a dynamically-linked construct together with GPL-2-only 
software makes the result undistributable.  This seems to be a situation which 
Debian needs to protect its users from.

One way out, as outlined by Mike Sweet [system-library] as upstream author, is 
for Debian to consider that libcups/libcupsimage qualify as system-supplied 
libraries for the purposes of GPLv2.  Having these two libraries in LSB could 
support that argument, but, using that argument, Debian could have gone away 
for the OpenSSL case long ago, and didn't.  I made it clear to upstream [odyx-
statement] that this was most certainly not going to happen.

Some questions at this point (Some for FTP Masters, CC'ed):
- Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking 
is unacceptable for Debian main?  In both directions?
- Can CUPS link against GPL-2-only code?
- Can GPL-2-only code link against CUPS?
- Whose reponsibility is it to check for these incompatibilities, and make 
sure they are not shipped in Debian?


Now, onto the ways forward. From a quick glance, the libraries CUPS links 
against don't seem to be an issue [CUPS-links-to], so let's focus on the 
libraries linked against CUPS' libraries (libcups2, libcupsmime1, 
libcupsppdc1, libcupsimage2, libcupscgi1).  Using `build-rdeps`, it appears 
there are 5345 packages that (also indirectly) build-depend on these packages 
(attached). I am not going to review all these by hand.  So, new questions:

- What tools should I be using to identify which of these will be 
undistributable constructs?  Aka: how, given a list of source packages, can I 
determine which are GPL-2-only in the codepaths that link against CUPS?
- What fields could I / should I use in src:cups to enforce these?  I was 
initially thinking of setting versionless Breaks: in each src:cups' library 
against the identified GPL-2-only culprits, then mass-filing bugs against 
these, promising to add version constraints when/if the licensing issue gets 
lifted. Does that sound like a good way forward?

Many thanks in advance for your insights!

Cheers,
OdyX

(
  A build-ready package is available from CUPS' Vcs-Git, in branch
  debian/experimental [cups-deb], just `dch -v2.3~b3-1local0` before building
)

[lwn] https://lwn.net/Articles/738531/
[cups-apache] https://lists.cups.org/pipermail/cups-devel/2017-November/
017085.html
[23branch] https://github.com/apple/cups/tree/master
[23b1] https://github.com/apple/cups/releases/tag/v2.3b1
[apache-gpl2] https://www.apache.org/licenses/GPL-compatibility.html
[fedora-tom] https://lists.fedoraproject.org/archives/list/
le...@lists.fedoraproject.org/message/NEQDL6V4RBRQTPI3YYBSZH5CTZG257F2/
[system-library] https://lists.cups.org/pipermail/cups-devel/2017-November/
017095.html
[odyx-statement] https://lists.cups.org/pipermail/cups-devel/2017-December/
017097.html
[cups-deb] https://salsa.debian.org/printing-team/cups/tree/debian/
experimental

[CUPS-links-to] CUPS dynamically links against
(excluding 'system libraries' such as libc, libgcc, libstdc++)
- cups → libusb-1.0-0 (LGPL-2.1)
- libcups2 → libavahi-client3 & libavahi-common3 (GPL-2+)
- libcups2 → libc6 (GPL-2+)
- libcups2 → libgnutls30 (LGPL-2.1+)
- libcups2 → libgssapi-krb5-2 (MIT)
- libcups2 → zlib1g (Zlib)0ad
2048-qt
389-admin-console
389-console
389-ds-console
3depict
3dldf
4pane
4ti2
a2ps
aac-tactics
abego-treelayout
abgate
abinit
abiword
ableton-link
abntex
aboot
abx
accerciser
access-modifier-checker
accessodf
ace
acedb
ace-link
ace-popup-menu
acetoneiso
ace-window
acl2
aclock.app
actiona
activemq
activemq-activeio
activemq-protobuf
actor-framework
adacontrol
ada-reference-manual
adasockets
addresses-for-gnustep
adql
adun.app
advi
adwaita-icon-theme
adwaita-qt
aegisub
aeskulap
aespipe
aether
aether-ant-tasks
aewm
afew
affiche
afterburner.fx
afterstep
agda
agenda.app
aggressive-indent-mode
aghermann
aiksaurus
airlift-airline
airlift-slice
airport-utils
aiscm
aisleriot
akonadi