Re: [Printing-architecture] Upstream future of ippusbxd
>>>>> "JM" == Johannes Meixner <jsmeix@suse.de> writes:
>>>>>>> "TK" == Till Kamppeter <till.kamppeter@gmail.com> writes:
TK> I am thinking about joining [ippusbxd] into the cups-filters
TK> upstream package to not have too many tiny packages to make up the
TK> complete printing stack and cups-filters contains all
TK> manufacturer-independent software for communication with printers
TK> which is not part of CUPS itself.
JC>> Be sure, if you do, to note the licensing issues for all of those who
JC>> packages cups-filters for distributions.
JC>> And also make sure that nothing which derrives from Mike's code ever
JC>> inter-links with anythig which derrives from Daniel's, since the
JC>> licenses are incompatible. (GPL2 vs Apache2).
JM> As far as I know (but I am not a lawyer) the crucial terms here are
JM> "mere aggregation" versus "combining two modules into one program"
JM> in the GPL2, see
JM> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
JM> As far as I know (but I am not a lawyer) it does not make a difference
JM> when GPL2 sources and sources with an incompatible license are in one
JM> same tarball versus when they are in different tarballs.
JM> As far as I know (but I am not a lawyer) one can have GPL2 sources
JM> and sources with an incompatible license in one same tarball without
JM> causing a GPL2 license issue when both parts are separate programs.
The package managers all show each packages' licences. So the
maintainers need to know about any changes so they can update those
lines when packaging a new version.
And a clearly pointed out *link*ing as the thing which needs avoidance.
If, after some time, anyone looks ast the code and thinks that something
can be merged or thst one set of code could be improved by incorporating
something from the other set, they need to know the legal limitations.
I never said “don't do it”; just “take care”.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Reply to: