Didier 'OdyX' Raboud writes ("CUPS GPL → Apache license change, how to
> 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
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.