Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » General (non-technical) » Eclipse Foundation » Derivative works and common sense
Derivative works and common sense [message #16746] Sat, 05 March 2005 20:49 Go to next message
Eclipse UserFriend
Originally posted by: bob.objfac.com

I'm not a lawyer and even if I were I wouldn't be _your_ lawyer, but the
question "What is a 'derivative work'?" comes up often, and the
questioners usually go away not very satisifed because they can never
get an "official" answer in terms that programmers can understand. Mike
Milinkovich once proposed to deal with this, and I hope he does. In the
meantime, every developer has to make up his or her own mind. Could this
be a problem for me?

As I'm currently involved in ripping out chunks of Eclipse for use in a
commercial RCP app, the question once again raised its head. So I had to
make a stab at answering it for myself. The following is offered in the
spirit of sharing some thinking, not as any sort of definitive answer.

Two things are certain:

1) If you modify EPL-licensed code, the modified code is a derivative work.

2) If you just "link" to EPL-licensed code, it isn't. (This is very
different than the GPL take on derivative works and some people get all
hung up on that, but most Eclipse developers have that part sorted out.)

But what about the gray areas?

3) If you modify EPL-licensed code in such a way that it now requires
some of your own code to build, is your own code now a derivative work?
I'm pretty sure it is.

4) If you modify EPL-licensed code in such a way that it now requires
some of your own code to work in an extended mode but the actual
dependency is on an interface, is your own code now a derivative work?
My personal take is, the interface is a derivative work (see 3) but the
possible implementations of the interface are not.

My reasoning is that dependency injection is just a case of linking.
Since your code that implements any of the other interfaces supported by
the EPL code does not thereby become derivative, it follows that the
same rule applies to your extensions.

5) If you do 4 in such a way that the modified EPL code is no longer
functional without an implementation of your newly-injected dependency,
does the (or at least an) implementation a derivative work? Fairness
dictates that it is. Besides, it is too easy to implement an extension
so the issue doesn't come up (e.g., if the interface object isn't
present, the extension does nothing). If you can't think of any way to
write it like that, then your extension probably is derivative.

6) If you write or use a program that modifies EPL source code and you
compile the resulting source code and distribute the result, is the
modified source code a derivative work? Of course it is. It doesn't make
any difference how you modify code, with your fingers or using trained
seals, the fact is you modified it. Even though it may seem silly to
publish the modified source I think the EPL requires you to do so.

7) If you write or use a program that modifies the object code resulting
from compiling EPL source code, is the modified object code a derivative
work? Of course it is. But the fact is, you are already distributing the
modified object code under the EPL. Your obligation should end there.
You are not required to somehow decompile the modified object code and
distribute it as source. You are not required to distribute the source
of the program that modified the code. (Otherwise, how would you ever be
able to use a third party object code optimizer, or obfuscator?)

Rabbis and lawyers can probably come up with a dozen other gray areas,
but these answers suffice for me. If you don't agree, fine, maybe I'm
wrong. But one has to put a stake in the ground somewhere.

Bob
Re: Derivative works and common sense [message #16749 is a reply to message #16746] Tue, 08 March 2005 22:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Yes, there are a million ways to connect to java code. The GPL folks
said the heck with it and declared anything required in you class path
to compile, you are a derivative work of.(I think that is the correct
decision, but its a big duscussion) You can get around this by creating
an abstraction layer, but that trick only works for the LGPL/EPL, not
the GPL. (this is why the GPL is called viral IMHO)

Personally I have created a layer of abstraction for my app since the
EPL like the LGPL will allow this. But this does mean I consider about
1/2 of my code will require EPL since the GUI classes you cant abstract
from without basically rewriting them. To each his own...


CL


Bob Foster wrote:
> I'm not a lawyer and even if I were I wouldn't be _your_ lawyer, but the
> question "What is a 'derivative work'?" comes up often, and the
> questioners usually go away not very satisifed because they can never
> get an "official" answer in terms that programmers can understand. Mike
> Milinkovich once proposed to deal with this, and I hope he does. In the
> meantime, every developer has to make up his or her own mind. Could this
> be a problem for me?
>
> As I'm currently involved in ripping out chunks of Eclipse for use in a
> commercial RCP app, the question once again raised its head. So I had to
> make a stab at answering it for myself. The following is offered in the
> spirit of sharing some thinking, not as any sort of definitive answer.
>
> Two things are certain:
>
> 1) If you modify EPL-licensed code, the modified code is a derivative work.
>
> 2) If you just "link" to EPL-licensed code, it isn't. (This is very
> different than the GPL take on derivative works and some people get all
> hung up on that, but most Eclipse developers have that part sorted out.)
>
> But what about the gray areas?
>
> 3) If you modify EPL-licensed code in such a way that it now requires
> some of your own code to build, is your own code now a derivative work?
> I'm pretty sure it is.
>
> 4) If you modify EPL-licensed code in such a way that it now requires
> some of your own code to work in an extended mode but the actual
> dependency is on an interface, is your own code now a derivative work?
> My personal take is, the interface is a derivative work (see 3) but the
> possible implementations of the interface are not.
>
> My reasoning is that dependency injection is just a case of linking.
> Since your code that implements any of the other interfaces supported by
> the EPL code does not thereby become derivative, it follows that the
> same rule applies to your extensions.
>
> 5) If you do 4 in such a way that the modified EPL code is no longer
> functional without an implementation of your newly-injected dependency,
> does the (or at least an) implementation a derivative work? Fairness
> dictates that it is. Besides, it is too easy to implement an extension
> so the issue doesn't come up (e.g., if the interface object isn't
> present, the extension does nothing). If you can't think of any way to
> write it like that, then your extension probably is derivative.
>
> 6) If you write or use a program that modifies EPL source code and you
> compile the resulting source code and distribute the result, is the
> modified source code a derivative work? Of course it is. It doesn't make
> any difference how you modify code, with your fingers or using trained
> seals, the fact is you modified it. Even though it may seem silly to
> publish the modified source I think the EPL requires you to do so.
>
> 7) If you write or use a program that modifies the object code resulting
> from compiling EPL source code, is the modified object code a derivative
> work? Of course it is. But the fact is, you are already distributing the
> modified object code under the EPL. Your obligation should end there.
> You are not required to somehow decompile the modified object code and
> distribute it as source. You are not required to distribute the source
> of the program that modified the code. (Otherwise, how would you ever be
> able to use a third party object code optimizer, or obfuscator?)
>
> Rabbis and lawyers can probably come up with a dozen other gray areas,
> but these answers suffice for me. If you don't agree, fine, maybe I'm
> wrong. But one has to put a stake in the ground somewhere.
>
> Bob
Re: Derivative works and common sense [message #24925 is a reply to message #16746] Wed, 05 October 2005 06:00 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: allan.hardy.com

Bob thanks for those guidelines.
Now it be wonderful if we could assume that silence by the eclipse
foundation folks implied they find no objections to these working models?

Allan Hardy
Re: Derivative works and common sense [message #24933 is a reply to message #24925] Wed, 05 October 2005 13:32 Go to previous messageGo to next message
Mike Milinkovich is currently offline Mike MilinkovichFriend
Messages: 260
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C5C98F.BDB79AC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FWIW, I have found this article by Larry Rosen to be quite helpful: =
http://rosenlaw.com/html/GPL.PDF=20

There is lots of useful information in there.=20

The article also contains a paragraph that I think aptly explains why =
the Foundation does not attempt to provide blanket definitions for what =
is a derivative work.
"One important word of caution. There are subtle differences among the =
courts about the meaning of the term "derivative work." If you are a =
software developer, you should review the specific characteristics of =
your software with a knowledgeable attorney to see if, based on the case =
law in your jurisdiction, your "combined program" could be deemed a =
derivative work..."

Note that IANAL.

"AllanH" <allan@hardy.com> wrote in message =
news:dhvq5g$j2a$1@news.eclipse.org...
> Bob thanks for those guidelines.
> Now it be wonderful if we could assume that silence by the eclipse=20
> foundation folks implied they find no objections to these working =
models?
>=20
> Allan Hardy=20
>=20
>
------=_NextPart_000_002F_01C5C98F.BDB79AC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>FWIW, I have found this article by =
Larry Rosen to=20
be quite helpful: </FONT><A =
href=3D"http://rosenlaw.com/html/GPL.PDF"><FONT=20
face=3DArial size=3D2>http://rosenlaw.com/html/GPL.PDF</FONT></A><FONT =
face=3DArial=20
size=3D2> </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>There is lots of useful information in =
there.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The article also contains a paragraph =
that I think=20
aptly explains why the Foundation does not attempt to provide blanket=20
definitions for what is a derivative work.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P align=3Dleft><FONT face=3DArial size=3D2>"<EM>One important word of =
caution.=20
There are subtle differences among the courts about the meaning of the =
term=20
"derivative work." If you are a software developer, you should review =
the=20
specific characteristics of your software with a knowledgeable =
attorney to see=20
if, based on the case law in your jurisdiction, your "combined =
program" could=20
be deemed a derivative work..."</EM></FONT></P></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>Note that IANAL.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"AllanH" &lt;</FONT><A=20
href=3D"mailto:allan@hardy.com"><FONT face=3DArial=20
size=3D2>allan@hardy.com</FONT></A><FONT face=3DArial size=3D2>&gt; =
wrote in message=20
</FONT><A href=3D"news:dhvq5g$j2a$1@news.eclipse.org"><FONT face=3DArial =

size=3D2>news:dhvq5g$j2a$1@news.eclipse.org</FONT></A><FONT face=3DArial =

size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>&gt; Bob thanks for =
those=20
guidelines.<BR>&gt; Now it be wonderful if we could assume that silence =
by the=20
eclipse <BR>&gt; foundation folks implied they find no objections to =
these=20
working models?<BR>&gt; <BR>&gt; Allan Hardy <BR>&gt;=20
<BR>&gt;</FONT></BODY></HTML>

------=_NextPart_000_002F_01C5C98F.BDB79AC0--
Re: Derivative works and common sense [message #24935 is a reply to message #24933] Wed, 05 October 2005 14:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: allan.hardy.com

Mike, thanks

I am familiar with Rosens work and his position that FSF is basically trying
merge the copyright definitions of derivative works and collective works.
FSF would not agree with Rosens assertion that merely running, without
modification, a GPL program from another program does not create a new
combined work - and a derived work.

The Eclipse Foundation can 'define' derived works in terms of copyright law.
That is a matter for the courts in the end, and as we know, various courts
have their own methods, while others haven't described any methods for
defining derived works at all.

But as the copyright holder for Eclipse software, you are in a position to
define in some way what you would considered as types of integration that
are considered derived and others that are not. For example as much as FSF
has stated that dynamic linking could create a derived work, you could state
that linking 3rd party code via the Eclipse plugin mechanism is not
something you would pursue as a derived work. You could state that any
modification of eclipse code it self would be something you would consider a
derived work. Things along that line.

"We want to build a symbiotic relationship with commercial software
companies," Milinkovich said in an interview following his keynote. "We
don't want to see a situation where nobody is making money building software
anymore." In fact, speaking as he displayed a slide entitled "Eclipse
Economics 101," Milinkovich said, "This is not about taking commercial
opportunities away from vendors; this is about providing them with a
platform to build on top of. Eclipse is a level playing field."

So mike, level the playing field. I am particularly interested in
clarifying RCP based solutions. It appears that Eclipse Foundation wants to
promote commercial applications, look at IBMs Workplace Client. So let me
ask this, it seems that if I build a RCP application that modifies no
source, only interfaces with RCP via published interfaces, I can sell that
application as a commercial product, under a single license (The license
would point out the eclipse pieces, etc), right? It seems everyone wants
that kind of model to happen. So tell me, other then modifying the RCP
source, is there anything else I could do that would get me in trouble?
Push me in a direction you would consider a derived work?

Allan Hardy
IANAL
Re: Derivative works and common sense [message #25192 is a reply to message #24935] Fri, 07 October 2005 21:26 Go to previous messageGo to next message
Mike Milinkovich is currently offline Mike MilinkovichFriend
Messages: 260
Registered: July 2009
Senior Member
Allan,

To me, this question is answered directly and succinctly by answer #17 in
the EPL FAQ at http://www.eclipse.org/legal/eplfaq.html. Further clarity can
be found by looking at #15, #21 and #22.

What am I missing? I don't really know how I could answer the question more
clearly than what's already in the FAQ. Going into greater detail than
what's already there, starts to cross the line into the realm of where you
need your own lawyer.

The second sentence of section 4 of the EPL starts with " While this license
is intended to facilitate the commercial use of the Program, ...". So yes,
we definitely want this model to happen. And as far as I can tell there are
no impediments preventing it from happening.

"AllanH" <allan@hardy.com> wrote in message
news:di0pcs$2aa$1@news.eclipse.org...
> So mike, level the playing field. I am particularly interested in
> clarifying RCP based solutions. It appears that Eclipse Foundation wants
> to promote commercial applications, look at IBMs Workplace Client. So
> let me ask this, it seems that if I build a RCP application that modifies
> no source, only interfaces with RCP via published interfaces, I can sell
> that application as a commercial product, under a single license (The
> license would point out the eclipse pieces, etc), right? It seems
> everyone wants that kind of model to happen. So tell me, other then
> modifying the RCP source, is there anything else I could do that would get
> me in trouble? Push me in a direction you would consider a derived work?
Re: Derivative works and common sense [message #25314 is a reply to message #24935] Tue, 11 October 2005 15:07 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

AllanH wrote:
> Mike, thanks
>
> I am familiar with Rosens work and his position that FSF is basically trying
> merge the copyright definitions of derivative works and collective works.
> FSF would not agree with Rosens assertion that merely running, without
> modification, a GPL program from another program does not create a new
> combined work - and a derived work.
>
> The Eclipse Foundation can 'define' derived works in terms of copyright law.
> That is a matter for the courts in the end, and as we know, various courts
> have their own methods, while others haven't described any methods for
> defining derived works at all.
>
> But as the copyright holder for Eclipse software, you are in a position to
> define in some way what you would considered as types of integration that
> are considered derived and others that are not. For example as much as FSF
> has stated that dynamic linking could create a derived work, you could state
> that linking 3rd party code via the Eclipse plugin mechanism is not
> something you would pursue as a derived work. You could state that any
> modification of eclipse code it self would be something you would consider a
> derived work. Things along that line.
>
> "We want to build a symbiotic relationship with commercial software
> companies," Milinkovich said in an interview following his keynote. "We
> don't want to see a situation where nobody is making money building software
> anymore." In fact, speaking as he displayed a slide entitled "Eclipse
> Economics 101," Milinkovich said, "This is not about taking commercial
> opportunities away from vendors; this is about providing them with a
> platform to build on top of. Eclipse is a level playing field."
>
> So mike, level the playing field. I am particularly interested in
> clarifying RCP based solutions. It appears that Eclipse Foundation wants to
> promote commercial applications, look at IBMs Workplace Client. So let me
> ask this, it seems that if I build a RCP application that modifies no
> source, only interfaces with RCP via published interfaces, I can sell that
> application as a commercial product, under a single license (The license
> would point out the eclipse pieces, etc), right? It seems everyone wants
> that kind of model to happen. So tell me, other then modifying the RCP
> source, is there anything else I could do that would get me in trouble?
> Push me in a direction you would consider a derived work?
>

Thats not 'safe.' By the FSF's definition you would be a derivative
work because you used the interfaces. its the same when you use a c
header file. You are now derived. And I believe the GPL rests on this
principle as its means of protecting GPLed code. For this reason, and
as you pointed out above, FSF favors broad definition of the term. The
LGPL recognizing this gives you rights even when/if your code is found
to be derived; the LGPL purpose is to be as a library and how you gonna
do that without headers/interfaces? Which is what you are trying to get
by using only interfaces here.

Yet the EPL does not recognize this line. FSF would say use GPL on your
core code and LGPL on your interfaces. EPL says use EPL on both and
claims it works both ways.

Whatever the definition of derived work turns out to be, can it really
be both?


CL
Re: Derivative works and common sense [message #25766 is a reply to message #25192] Tue, 18 October 2005 00:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: allan.hardy.com

Mike,

Thanks for the response.

#17 When I incorporate a portion of a Program licensed under the EPL into my
own proprietary product distributed in object code form, can I use a single
license for the full product, in other words, covering the portion of the
Program plus my own code? Yes. The object code for the product may be
distributed under a single license as long as it references the EPL portion
and complies, for that portion, with the terms of the EPL.

Should you add a caveat here - "as long as the manner of incorporation does
not create a derived work" ?
Unless you are saying that no manner of incorporating works together can
lead to a derived work?
If this is your position I welcome it, but suspect its not the case.

In short, this does indicate that there are possibily ways to 'incorporate'
EPL and proprietary works such that the proprietary portion can stay
proprietary, but it does nothing much to help one understand when the
incorporation / combining has crossed into a derived work.

#15 Can I take a Program licensed under the EPL, compile it without
modification, and commercially license the result?
Yes. You may compile a Program licensed under the EPL without modification
and commercially license the result in accordance with the terms of the EPL.

This does nothing in terms of helping understand what is a derived work. I
am unclear why you pointed it out?

Should you complete #15 by also adding that they still ahev the requirement
for providing source code for the commercially licensed product, and that
the commercial license must have terms which comply with the EPL.

#21 If I write a module to add to a Program licensed under the EPL and
distribute the object code of the module along with the rest of the Program,
must I make the source code to my module available in accordance with the
terms of the EPL?
No, as long as the module is not a derivative work of the Program.

Right, so when is it a derived work? When is it not?

This tells me that its possible to have modules that are derived works.
Going back to 17, we now can see that there are ways to incoprporate
different works, a tleast as modules, that could lead to a derive work.

In short, all 21 does is show the unclarity of 17, and it tells us that you
consider that soemtimes 'modules' (using a plug-in or modular interface)
could be derived works. Which times?


In short, I am not clear on how you can claim these points as providing
clarity, or even really touching at all on the Eclipse Foundation's view of
a derived work. Not to be pejoritive, but what am I missing? I don't see
how you could hold these points out as making any statements at all about
derived works, never mind saying you can't make it any clearer.

Allan Hardy
IANAL

Mike Milinkovich" <mike.milinkovich@eclipse.org> wrote in message
news:di6p6h$sjd$1@news.eclipse.org...
> Allan,
>
> To me, this question is answered directly and succinctly by answer #17 in
> the EPL FAQ at http://www.eclipse.org/legal/eplfaq.html. Further clarity
> can be found by looking at #15, #21 and #22.
>
> What am I missing? I don't really know how I could answer the question
> more clearly than what's already in the FAQ. Going into greater detail
> than what's already there, starts to cross the line into the realm of
> where you need your own lawyer.
>
> The second sentence of section 4 of the EPL starts with " While this
> license is intended to facilitate the commercial use of the Program, ...".
> So yes, we definitely want this model to happen. And as far as I can tell
> there are no impediments preventing it from happening.
>
> "AllanH" <allan@hardy.com> wrote in message
> news:di0pcs$2aa$1@news.eclipse.org...
>> So mike, level the playing field. I am particularly interested in
>> clarifying RCP based solutions. It appears that Eclipse Foundation wants
>> to promote commercial applications, look at IBMs Workplace Client. So
>> let me ask this, it seems that if I build a RCP application that modifies
>> no source, only interfaces with RCP via published interfaces, I can sell
>> that application as a commercial product, under a single license (The
>> license would point out the eclipse pieces, etc), right? It seems
>> everyone wants that kind of model to happen. So tell me, other then
>> modifying the RCP source, is there anything else I could do that would
>> get me in trouble? Push me in a direction you would consider a derived
>> work?
>
>
Re: Derivative works and common sense [message #25782 is a reply to message #25314] Tue, 18 October 2005 00:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: allan.hardy.com

"CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
news:434BD52B.2070207@rigidsoftware.com...
> Thats not 'safe.' By the FSF's definition you would be a derivative work
> because you used the interfaces. its the same when you use a c header
> file. You are now derived. And I believe the GPL rests on this principle
> as its means of protecting GPLed code. For this reason, and as you
> pointed out above, FSF favors broad definition of the term. The LGPL
> recognizing this gives you rights even when/if your code is found to be
> derived; the LGPL purpose is to be as a library and how you gonna do that
> without headers/interfaces? Which is what you are trying to get by using
> only interfaces here.
>
> Yet the EPL does not recognize this line. FSF would say use GPL on your
> core code and LGPL on your interfaces. EPL says use EPL on both and
> claims it works both ways.
>
> Whatever the definition of derived work turns out to be, can it really be
> both?
>
>
> CL

Hmm, not really. I mean saying to use LGPL on 'interfaces', I mean by most
copyright models 'interfaces' are not copyrightable. But I think thats to
literal a definition of what you mean by interface. You probably meant that
one should use LGPL where you want to be able to integrate / interface with
other products without affecting them legally.

LGPL, like GPL, preserves the products GPL heritage by not allowing forking,
release under new licenses, etc.
LGPL, like GPL, ensures availability of the products source code.
LGPL, unlike GPL, does not push the copyleft, reciprocity ideal, not as much

We know that FSF via thier view of GPL pushes the definiton of derived work
beyond any boundry thats ever been tested or ruled on by a court.
They needed LGPL to pull back this boundry a little in order to recognize
market realities, though Stallman states he regrets this compromise to this
day.

Perhaps EPL does not need these two different catagories of licenses because
it is not trying to push the boundries of copyright law in the first place.
EPL doesn't require it because it doesn't create this artificial relm of
core work and interfaces.

Your argument seems to be that one must follow the FSF model, ignoring the
fact that the FSF model may be pretty confusing and hosed?
Re: Derivative works and common sense [message #25838 is a reply to message #25782] Mon, 24 October 2005 19:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

I never viewed the FSF model in this way.

What I think should be done is interfaces and abstract classes should be
open licensed. Like what I think the BSD provides. Classes that
Eclipse thinks should be protected in some fashion should be EPL.

The EPL tries to single handedly accomplish both of these things. Free
the interfaces and restrict the core classes. When people say 'what is
a derived work' what they really want to know is the devision between
what then can use and what they can not. In stead the reply tries to
say how they can use and how they can not. Its obvious programmers are
not behind the license. We think in abstract terms but never vague terms.


CL


AllanH wrote:
> "CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
> news:434BD52B.2070207@rigidsoftware.com...
>
>>Thats not 'safe.' By the FSF's definition you would be a derivative work
>>because you used the interfaces. its the same when you use a c header
>>file. You are now derived. And I believe the GPL rests on this principle
>>as its means of protecting GPLed code. For this reason, and as you
>>pointed out above, FSF favors broad definition of the term. The LGPL
>>recognizing this gives you rights even when/if your code is found to be
>>derived; the LGPL purpose is to be as a library and how you gonna do that
>>without headers/interfaces? Which is what you are trying to get by using
>>only interfaces here.
>>
>>Yet the EPL does not recognize this line. FSF would say use GPL on your
>>core code and LGPL on your interfaces. EPL says use EPL on both and
>>claims it works both ways.
>>
>>Whatever the definition of derived work turns out to be, can it really be
>>both?
>>
>>
>>CL
>
>
> Hmm, not really. I mean saying to use LGPL on 'interfaces', I mean by most
> copyright models 'interfaces' are not copyrightable. But I think thats to
> literal a definition of what you mean by interface. You probably meant that
> one should use LGPL where you want to be able to integrate / interface with
> other products without affecting them legally.
>
> LGPL, like GPL, preserves the products GPL heritage by not allowing forking,
> release under new licenses, etc.
> LGPL, like GPL, ensures availability of the products source code.
> LGPL, unlike GPL, does not push the copyleft, reciprocity ideal, not as much
>
> We know that FSF via thier view of GPL pushes the definiton of derived work
> beyond any boundry thats ever been tested or ruled on by a court.
> They needed LGPL to pull back this boundry a little in order to recognize
> market realities, though Stallman states he regrets this compromise to this
> day.
>
> Perhaps EPL does not need these two different catagories of licenses because
> it is not trying to push the boundries of copyright law in the first place.
> EPL doesn't require it because it doesn't create this artificial relm of
> core work and interfaces.
>
> Your argument seems to be that one must follow the FSF model, ignoring the
> fact that the FSF model may be pretty confusing and hosed?
>
>
>
Re: Derivative works and common sense [message #25879 is a reply to message #25766] Mon, 24 October 2005 22:15 Go to previous message
Mike Milinkovich is currently offline Mike MilinkovichFriend
Messages: 260
Registered: July 2009
Senior Member
"AllanH" <allan@hardy.com> wrote in message
news:dj1ftn$63v$1@news.eclipse.org...
> In short, this does indicate that there are possibily ways to
> 'incorporate' EPL and proprietary works such that the proprietary portion
> can stay proprietary, but it does nothing much to help one understand when
> the incorporation / combining has crossed into a derived work.

<IANAL>
Your interpretation is exactly correct, and exactly as designed. As
mentioned previously in this thread and elsewhere, you will need to seek the
advice of your own legal counsel in deciding whether your program
constitutes a derivative work. Ditto for the rest of your responses below
(which I've snipped for clarity).

The Eclipse Foundation does not attempt to define "derivative work". The
Eclipse Foundation interprets the term "derivative work" in a way that is
generally consistent with the definition in the U.S. Copyright Act, as
applicable to computer software. You will need to seek the advice of your
own legal counsel in deciding whether your program constitutes a derivative
work.

Deciding whether something is a derivative work requires the application of
legal knowledge to a specific set of facts. Even if the staff of Eclipse had
the time and skills to talk to everyone about these, as the licensor we
would be in a conflict of interest in giving advice to you, the licensee.

In closing, I would again point you to Larry Rosen's article
(http://www.linuxjournal.com/article/6366) where he says (amongst other
things) that the "... primary indication of whether a new program is a
derivative work is whether the source code of the original program was used,
modified, translated or otherwise changed in any way to create the new
program. If not, then I would argue that it is not a derivative work." He
further says that derivative works "...are not going to encompass plugins
and device drivers that are designed to be linked from off-the-shelf,
unmodified, programs." A few minutes with Google can help you find more
articles of similar clarity.

But I would also remind you of Mr. Rosen's closing statement: "Legal advice
must be provided in the course of an attorney-client relationship
specifically with reference to all the facts of a particular situation and
the law of your jurisdiction. Even though an attorney wrote this article,
the information in this article must not be relied upon as a substitute for
obtaining specific legal advice from a licensed attorney."
</IANAL>
Previous Topic:Register early for EclipseCon and Get an Eclipse RCP Book
Next Topic:Licensing support in Eclipse
Goto Forum:
  


Current Time: Fri Mar 29 06:44:55 GMT 2024

Powered by FUDForum. Page generated in 0.04352 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top