From: James Cloos <cloos@jhcloos.com>
To: Johannes Meixner <jsmeix@suse.de>
Cc: Open Printing <printing-architecture@lists.linux-foundation.org>,
Debian-printing@lists.debian.org,
Till Kamppeter <till.kamppeter@gmail.com>
Subject: Re: [Printing-architecture] Upstream future of ippusbxd
Date: Tue, 07 Jul 2015 12:02:36 -0400 [thread overview]
Message-ID: <m38uas552b.fsf@carbon.jhcloos.org> (raw)
In-Reply-To: <alpine.LNX.2.00.1507071604010.29822@nelson.suse.de> (Johannes Meixner's message of "Tue, 7 Jul 2015 16:16:11 +0200 (CEST)")
>>>>> "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
next prev parent reply other threads:[~2015-07-07 16:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-07 1:15 [Printing-architecture] Upstream future of ippusbxd Till Kamppeter
2015-07-07 8:47 ` Johannes Meixner
2015-07-07 12:10 ` James Cloos
2015-07-07 14:16 ` Johannes Meixner
2015-07-07 16:02 ` James Cloos [this message]
2015-07-08 9:12 ` Johannes Meixner
2015-07-08 12:40 ` Ira McDonald
2015-07-08 14:10 ` Tim Waugh
2015-07-08 18:59 ` Till Kamppeter
2015-07-13 10:05 ` Tim Waugh
2015-07-07 15:33 ` Tim Waugh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m38uas552b.fsf@carbon.jhcloos.org \
--to=cloos@jhcloos.com \
--cc=Debian-printing@lists.debian.org \
--cc=jsmeix@suse.de \
--cc=printing-architecture@lists.linux-foundation.org \
--cc=till.kamppeter@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.