Combining EPL and GPL
Richard Braman - EHR Doctors
AGPL, and EPL, i have continued researching and found this article,
which relates my view of the world: that the combination of modules
with different licenses into a larger system DO NOT create a
DERIVATIVE WORK. If you are of the opinion that linking a library
creates a derivative work, then you need to consider that all programs
on a system are linked in some way, otherwise they would not work.
http://blogs.zdnet.com/Burnette/?p=331
I will leave it to those who feel much more passionate about these
issues than I do to talk to their lawyers about it and then beat each
other senseless arguing about something entirely arbitrary.
My problem with many of these arguments are that they dont include the
facts, but instead focus on feelings and thoughts gleemed from wiki
pages and the FSF views on GPL.
I think you should all familiarize yourselves with Larry Rosen before
you question the logic in the above article, he is much more
knowledgeable about this stuff than your typical legal hack.
http://en.wikipedia.org/wiki/Lawrence_Rosen_%28Attorney%29
In my analysis if it works for RedHat, it works for me.
$5 Billion in market cap doesn't lie.
Ben Mehling
<ehrdo...@gmail.com> wrote:
> After thinking long and hard about the licensing issues between GPL,
> AGPL, and EPL, i have continued researching and found this article,
> which relates my view of the world: that the combination of modules
> with different licenses into a larger system DO NOT create a
> DERIVATIVE WORK. If you are of the opinion that linking a library
> creates a derivative work, then you need to consider that all programs
> on a system are linked in some way, otherwise they would not work.
I do not find this argument relevant to the question of mixing and
conveying AGPL and EPL M code together. In aggregate, I do not see
how you could call mixed Pharmacy code "not by their nature extensions
of the covered work". In other words, if you mix AGPL Pharmacy code
with EPL Pharmacy code, how can you say they are not "extensions" (of
each other)? The RedHat example is more around the mixing of software
packages w/in their distribution.
Further, it is generally held that these two specific licenses are
mutually exclusive due to each placing different limitations around
patents (remember that aggregates "are not (cannot be) used to limit
the access or legal rights of the compilation’s users beyond what the
individual works permit").
The last thing I'd add is that the 'end user' (organization) have very
few limitations as they can mix and match code under different
licenses as they see fit -- my read is that this is more an issue of
"aggregates" and "conveyance" for those building distributions.
- Ben
PS... almost all these arguments should be considered opinion as not
much of it can be considered tested case law.
Richard Braman - EHR Doctors
> conveying AGPL and EPL M code together. In aggregate, I do not see
> how you could call mixed Pharmacy code "not by their nature extensions
> of the covered work". In other words, if you mix AGPL Pharmacy code
> with EPL Pharmacy code, how can you say they are not "extensions" (of
> each other)?
I will agree if the code is in the same module,
but all code is an extension of other code, it depends if the new code
creates a Dervitive Work, which is a new work based on the Original
work, or if it just uses the Original work in the way it was
originally distributed with no modifications. We are talking about
modifications here right? It depends on the facts and circumstances.
The RedHat example is more around the mixing of software
> packages w/in their distribution.
>
> Further, it is generally held that these two specific licenses are
> mutually exclusive due to each placing different limitations around
> patents (remember that aggregates "are not (cannot be) used to limit
> the access or legal rights of the compilation’s users beyond what the
> individual works permit").
again, i think the licenses are incompatible meaning you cannot modify
GPL code and license your derivative work as EPL. Once GPL always
GPL.
>
> The last thing I'd add is that the 'end user' (organization) have very
> few limitations as they can mix and match code under different
> licenses as they see fit -- my read is that this is more an issue of
> "aggregates" and "conveyance" for those building distributions.
>
That i certainly agree with
> - Ben
>
> PS... almost all these arguments should be considered opinion as not
> much of it can be considered tested case law.
That i certainly agree with
I would like to see the major VistA groups come together and have a
licensing agreement amongst each other, maybe even a covenant not to
sue over (certain) licensing. I see a lot of duplication of efforts
coming our way if no agreement can be reached. The reason Linux
groups have been successful is their cooperation. Remember: the enemy
of my enemy is my friend. There are big enough EHR software groups
out there trashing VistA for their own agenda. If we trash and sue
eachother, you can be assured of VistA's failure.
Ben Mehling
<ehrdo...@gmail.com> wrote:
> It depends on the facts and circumstances.
Amen. So much about this system "depends". :-)
> again, i think the licenses are incompatible meaning you cannot modify
> GPL code and license your derivative work as EPL. Once GPL always
> GPL.
This is true regardless of the assigned license. The owner of the
copyright (or an entity with a "license to sub-license") is the only
entity that can change the assigned license.
- Ben
K.S. Bhaskar
EPL and GPL code in the same routine because this would create a
derivative work and the rules are for mixing and redistribution in the
two licenses are as compatible as brake fluid and ketchup. [As noted in
an earlier post, you can do what you want for your own use.]
As long as you are not mixing EPL and GPL code in the same routine,
creating and distributing hybrid VistA blends for use with GT.M is a
non-problem. Just put the EPL licensed routines in one directory and the
GPL licensed routines in another directory. The routines are only ever
linked at run time and within a process, an act which is permitted
without regard to licensing by all FOSS licenses that I am aware of.
Otherwise the routines are simply bundled together in the same archive or
on the same CD - the act of bundling does not create a derivative work.
Where it gets interesting is in the database - for example, what if EPL
licensed VistA 1 creates one Fileman file and GPL licensed VistA 2
creates a different Fileman file? Does putting them in the same database
create a derivative work? I don't know. But this too is easily dealt
with. As long as the two Fileman files don't step on each other, instead
of shipping a database, just include each as a separate .zwr file that
gets loaded into the database when the database is created (you can draw
on http://www.time.com/time/magazine/article/0,9171,742105,00.html for
inspiration & creativity).
Thought for the day: Licensing discussions sometimes generate more heat
than light.
Caution: I am not a lawyer, and don't want to be one when I grow up.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________