CUPS GPL → Apache license change, how to proceed?
(too old to reply)
Ian Jackson
2018-02-19 17:00:56 UTC
(Adding d-legal)
tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to
"Apache-2.0"; how should the license incompatibilities be enforced?
- 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.


Continue reading on narkive: