Re: CUPS GPL → Apache license change, how to proceed?
On Tue, Feb 20, 2018 at 07:21:21PM +0800, Paul Wise wrote: > adequate has an incompatible-licenses tag that probably could be used > for this. Just install all rdeps of cups and check all packages on the > system with adequate. piuparts.debian.org does this automatically (obviously only for stuff already in the archive...) -- cheers, Holger signature.asc Description: PGP signature
Re: CUPS GPL → Apache license change, how to proceed?
On Tue, Feb 20, 2018 at 3:20 PM, Stuart Prescott wrote: > I thought there might be something that could be done here. adequate has an incompatible-licenses tag that probably could be used for this. Just install all rdeps of cups and check all packages on the system with adequate. -- bye, pabs https://wiki.debian.org/PaulWise
Re: CUPS GPL → Apache license change, how to proceed?
Didier 'OdyX' Raboud wrote: > - 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? > [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) Having looked at python-debian's debian.copyright.Copyright module just the other day, I thought there might be something that could be done here. With 77% of the packages in the rdeps list that have a readable copyright- format/1.0 (or an older format), we can make reasonable progress. * we can say that 3746 (70%) of the packages in the build-rdeps list have no *direct* problem because they are not GPLv2-only. (That is to ignore that they might depend on packages that are themselves in trouble with this licence change) * there are 379 packages that are GPLv2-only; that doesn't mean that they definitely load both GPLv2-only code and libcups* into the same executable, but they need checking. (gplv2-only.txt attached) * 1220 packages haven't been checked; most aren't in copyright-format/1.0 but a few generate parse errors or have sufficiently complicated licence terms that this tool can't figure it out. (unknown.txt attached) These good(ish) looking numbers at least cut down the scope of the checking that is required by 70%. There's still 1600ish packages that need to be looked at in some way. I'm not sure what the next steps would be. Perhaps walking the dependency tree looking at these 1600 packages is what should happen next. We would likely find places where the tree can be pruned because there is no linking involved, merely use of a tool at build time. I'm sure we've got graph walking code in the archive somewhere that might help… For those in need of amusement, code at https://salsa.debian.org/stuart/package-license-checker and all relevant copyright files (current as of unstable today) from the packages analysed at https://people.debian.org/~stuart/copyright.tar.xz Happy for suggestions, merge requests etc! cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7389-admin-console 389-ds-console 4pane abiword aeskulap airport-utils akonadi akonadi-contacts akonadiconsole alsa-tools alt-ergo android-framework-23 android-platform-libcore apophenia ask asterisk asunder audacity baloo bibtex2html bindex blender blktrace blogilo calf calibre calligra cdbs ceph cl-asdf comedilib cpl cups-filters daisy-player dar denemo dia diffoscope djvusmooth doc-linux-fr dogtag-pki dolphin-emu doxygen dozzaqueux dpdk dpmb dpuser drupal7 dtd-parser dune-common dune-geometry dune-grid dune-istl dune-localfunctions edb-debugger edfbrowser eiskaltdcpp espresso evas-loaders exactimage fbpanel felix-framework felix-main felix-osgi-obr ferret-vis fio foomatic-db foxtrotgps frama-c free42-nologo freefem++ freemat frei0r gajim gamera gazebo geany-plugins geg geneweb getdp gfarm gigedit git-cola gkrellm-gkrellmpc gkrellm2-cpufreq gkrelluim gmanedit gmidimonitor gmrun gmsh gmtp gnome-colors gnuais goobox goocanvas-2.0 goocanvasmm-2.0 gpicview gpsprune gpsshogi gpt grace grantlee5 grass groovy gspiceui gtk-sharp3 gtk2-engines-xfce gxmms2 hardinfo haskell-yi-frontend-pango heaptrack hedgewars hhvm highlight.js iio-sensor-proxy ikiwiki imview ini4j instead invesalius isomaster istack-commons jack-mixer jalview java-imaging-utilities java3d javamail jaxb jaxb-api jaxrs-api jd jenkins-htmlunit-core-js jericho-html jersey1 jmol josm jsjac jtharness jtreg juffed kaccounts-integration kajongg kalarm kamailio kcachegrind kdbg kde-dev-scripts kdeconnect kdelibs4support kdepim-addons kdepim-runtime kdepimlibs kdocker keepassx kf5-messagelib kio kio-extras kjots kleopatra kmail kmailtransport kmenuedit kodi korganizer kpimtextedit krita ksirk kstars ksyntax-highlighting ksysguard ktexteditor kturtle ladish lammps latex2html latexdiff ldm ldm-themes libaopalliance-java libemf libexif-gtk libgaminggear libhtmlcleaner-java libitext1-java libj2ssh-java libjgroups-java libjpfcodegen-java libjsr166y-java libjtds-java libkf5calendarsupport libkf5eventviews libkf5grantleetheme libkf5gravatar libkf5incidenceeditor libkf5ksieve libkf5libkdepim libkf5libkleo libkf5mailcommon libkf5mailimporter libkf5pimcommon libnb-javaparser-java libodb-qt libpulse-java librecad libreoffice libsimple-validation-java libswarmcache-java libzypp light-locker lightdm lightdm-gtk-greeter linux-minidisc londonlaw ltsp-docs luckybackup marionnet mate-control-center maven
Re: CUPS GPL → Apache license change, how to proceed?
(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?
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
