Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » General (non-technical) » Eclipse Foundation » [LICENSE] Definition of "derivative work"
[LICENSE] Definition of "derivative work" [message #8147] Tue, 14 December 2004 17:24 Go to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Myself and another person were having a license discussion in the
platform newsgroup when a helpful poster suggested we bring it here. I
came hear and read a bit and think this is the correct place.

The issue is the definition of derivative work. I will repost my
position from the other forum here.


The GPLs position on derivative work has not changed with the emergence
of Java. For instance when one has a library he intends to be useable
by others he may license it under the LGPL. Which means you can link to
it without being required to release your source provided

1. You link 'dynamically' which means your object code will not contain
any of the libraries code.

2. The header file you use to link dynamically is NOT under the LGPL,
because you are still 'statically' linking to the header, and your end
work is still a derivative of this header.

It seems that many people have historically released their libraries
under the LGPL without releasing the headers under a freer license.
Thus, improperly using the LGPL. The GPL would prevent the use of this
header file in the library without the header being itself GPL
compatable. The LGPL allows the use of this header in the library
without the header being GPL compatible. This is the main reason the
LGPL is better for libraries. With this header one can now dynamically
link to the library _without_ including any part of said library in his
own code.

Jump forward to Java and this same situation is present with the LGPL
and the CPL. Both allow you to link to the work freely (unlike GPL),
but not to become a derivative work freely (just like GPL). The way to
deal with this I believe is as it has been(so I have read): Create a
library of the interfaces, and release that under a freer license. That
is how it is handled historically with c, c++, etc. and the LGPL, that
is how it should be handled in Java.



Summary

One of two things needs to happen;

a.) IBM must specify its own definition of "derivative work" and have
that present in the definitions section of the license, and have that
definition not include "linking" at runtime. But how IBM can do this
and still protect the Eclipse source from exploitation is unclear due to
the myriad ways of 'linking' in Java.

b.) The Eclipse Project must package the interfaces to the Eclipse
Platform (the portions that do not need protection from exploitation) in
seperate jar files, under a seperate freer license.


Needless to say, some do not agree. What is your position?


--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Re: [LICENSE] Definition of "derivative work" [message #8303 is a reply to message #8147] Tue, 14 December 2004 19:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

I posted a bug report for this in bugzilla

https://bugs.eclipse.org/bugs/show_bug.cgi?id=80980

CL


CL [dnoyeb] Gilbert wrote:
> Myself and another person were having a license discussion in the
> platform newsgroup when a helpful poster suggested we bring it here. I
> came hear and read a bit and think this is the correct place.
>
> The issue is the definition of derivative work. I will repost my
> position from the other forum here.
>
>
> The GPLs position on derivative work has not changed with the emergence
> of Java. For instance when one has a library he intends to be useable
> by others he may license it under the LGPL. Which means you can link to
> it without being required to release your source provided
>
> 1. You link 'dynamically' which means your object code will not contain
> any of the libraries code.
>
> 2. The header file you use to link dynamically is NOT under the LGPL,
> because you are still 'statically' linking to the header, and your end
> work is still a derivative of this header.
>
> It seems that many people have historically released their libraries
> under the LGPL without releasing the headers under a freer license.
> Thus, improperly using the LGPL. The GPL would prevent the use of this
> header file in the library without the header being itself GPL
> compatable. The LGPL allows the use of this header in the library
> without the header being GPL compatible. This is the main reason the
> LGPL is better for libraries. With this header one can now dynamically
> link to the library _without_ including any part of said library in his
> own code.
>
> Jump forward to Java and this same situation is present with the LGPL
> and the CPL. Both allow you to link to the work freely (unlike GPL),
> but not to become a derivative work freely (just like GPL). The way to
> deal with this I believe is as it has been(so I have read): Create a
> library of the interfaces, and release that under a freer license. That
> is how it is handled historically with c, c++, etc. and the LGPL, that
> is how it should be handled in Java.
>
>
>
> Summary
>
> One of two things needs to happen;
>
> a.) IBM must specify its own definition of "derivative work" and have
> that present in the definitions section of the license, and have that
> definition not include "linking" at runtime. But how IBM can do this
> and still protect the Eclipse source from exploitation is unclear due to
> the myriad ways of 'linking' in Java.
>
> b.) The Eclipse Project must package the interfaces to the Eclipse
> Platform (the portions that do not need protection from exploitation) in
> seperate jar files, under a seperate freer license.
>
>
> Needless to say, some do not agree. What is your position?
>
>


--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Re: [LICENSE] Definition of "derivative work" [message #8335 is a reply to message #8303] Tue, 14 December 2004 21:03 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: myname(with.between names).lombardisoftware.com

I guess I would disagree on your definition of derivative work and java.
IANAL either, nor an expert in licenses, but that never stopped me from
having an opinion ;)

All use of libraries (jars) in java are dynamicly linked. Your jar/classes
never incorporate the other classes they uses externally (static linking),
they are only linked by names. There is absolutely not a single byte taken
from any eclipse jar into my jars that uses the eclipse jars. So, if I type
(as an example was on eclipse.platform) "import org.eclipse.xx.yy" in my
class does not make my class a derivative work of org.eclipse.xx.yy. if my
class extend org.eclipse.actions.IAction does not make me a derivative work
of IAction either, I'm just dynamicly linking to the jar without using
their source directly into my product. If I change
org.eclipse.actions.IAction or copy and extend the code, it is derivative
work.

So I would disagree with your second statements around java; in java you
don't staticly link to any "header" as you probably would in c/c++. You
always just dynamicly link. So the whole interface thing is not needed.
c/c++ is different as you require .h header files in additions to the
dll/so's.


CL [dnoyeb] Gilbert wrote:

> I posted a bug report for this in bugzilla
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=80980
>
> CL
>
>
> CL [dnoyeb] Gilbert wrote:
>> Myself and another person were having a license discussion in the
>> platform newsgroup when a helpful poster suggested we bring it here. I
>> came hear and read a bit and think this is the correct place.
>>
>> The issue is the definition of derivative work. I will repost my
>> position from the other forum here.
>>
>>
>> The GPLs position on derivative work has not changed with the emergence
>> of Java. For instance when one has a library he intends to be useable
>> by others he may license it under the LGPL. Which means you can link to
>> it without being required to release your source provided
>>
>> 1. You link 'dynamically' which means your object code will not contain
>> any of the libraries code.
>>
>> 2. The header file you use to link dynamically is NOT under the LGPL,
>> because you are still 'statically' linking to the header, and your end
>> work is still a derivative of this header.
>>
>> It seems that many people have historically released their libraries
>> under the LGPL without releasing the headers under a freer license.
>> Thus, improperly using the LGPL. The GPL would prevent the use of this
>> header file in the library without the header being itself GPL
>> compatable. The LGPL allows the use of this header in the library
>> without the header being GPL compatible. This is the main reason the
>> LGPL is better for libraries. With this header one can now dynamically
>> link to the library _without_ including any part of said library in his
>> own code.
>>
>> Jump forward to Java and this same situation is present with the LGPL
>> and the CPL. Both allow you to link to the work freely (unlike GPL),
>> but not to become a derivative work freely (just like GPL). The way to
>> deal with this I believe is as it has been(so I have read): Create a
>> library of the interfaces, and release that under a freer license. That
>> is how it is handled historically with c, c++, etc. and the LGPL, that
>> is how it should be handled in Java.
>>
>>
>>
>> Summary
>>
>> One of two things needs to happen;
>>
>> a.) IBM must specify its own definition of "derivative work" and have
>> that present in the definitions section of the license, and have that
>> definition not include "linking" at runtime. But how IBM can do this
>> and still protect the Eclipse source from exploitation is unclear due to
>> the myriad ways of 'linking' in Java.
>>
>> b.) The Eclipse Project must package the interfaces to the Eclipse
>> Platform (the portions that do not need protection from exploitation) in
>> seperate jar files, under a seperate freer license.
>>
>>
>> Needless to say, some do not agree. What is your position?
>>
>>
>
>
Re: [LICENSE] Definition of "derivative work" [message #8365 is a reply to message #8335] Tue, 14 December 2004 21:18 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 17
Registered: July 2009
Junior Member
Thanks Morten.
I seem to get it now :)

PRASHANT
Re: [LICENSE] Definition of "derivative work" [message #8395 is a reply to message #8335] Tue, 14 December 2004 22:03 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Morten Moeller wrote:
> I guess I would disagree on your definition of derivative work and java.
> IANAL either, nor an expert in licenses, but that never stopped me from
> having an opinion ;)
>
> All use of libraries (jars) in java are dynamicly linked. Your jar/classes
> never incorporate the other classes they uses externally (static linking),
> they are only linked by names. There is absolutely not a single byte taken
> from any eclipse jar into my jars that uses the eclipse jars. So, if I type
> (as an example was on eclipse.platform) "import org.eclipse.xx.yy" in my
> class does not make my class a derivative work of org.eclipse.xx.yy. if my
> class extend org.eclipse.actions.IAction does not make me a derivative work
> of IAction either, I'm just dynamicly linking to the jar without using
> their source directly into my product. If I change
> org.eclipse.actions.IAction or copy and extend the code, it is derivative
> work.
>

If what you claim about dynamic linking were true, than no java class
could be protected because they are all connected in that way. The FSF
does not want to see one sneaking by because they dynamically linked as
opposed to static link. Honestly, this violates the purpose of the
protection. You are using the copyrighted work within your own work.

The FSF does not care if its static or dynamic linking. What they care
about is inclusion;

1. If your object files contain portions from the elements produced by
compiling the copyrighted work, you are derivative.

2. If your source files contain copied code from the copyrighted work,
you are derivative.

3. If your source files contain signatures of the copyrighted work, you
are derivative.

That forms the basis of the FSFs position on what is and is not a
derivative work, right or wrong. Anytime the class must be present for
your class to compile you are derivative. When you compile your class
with this imported class, the signature of the imported class will be
present in your class file. You can check this with "javap." Thus you
have the signature of a copyrighted work, present in your generated
..class file. You have a derivative work.


That is my interpretation of how one can reach this conclusion,
nevertheless, the conclusion is certainly reached by the FSF see
http://www.gnu.org/licenses/lgpl-java.html


> So I would disagree with your second statements around java; in java you
> don't staticly link to any "header" as you probably would in c/c++. You
> always just dynamicly link. So the whole interface thing is not needed.
> c/c++ is different as you require .h header files in additions to the
> dll/so's.

there is no difference. java requires interfaces or classes, c/c++
requires headers. In c if you dynamically link, but you include the
header which is under the LGPL, you are still derivative. To
effectively use the LGPL you must have a header that is not under the
LGPL. That is my interpretation, and I believe consistent with the FSF.
I could be wrong.

It is up to the creator of the work to draw the line of useability vs,
extensibility based on what license he puts on what file.




--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Re: [LICENSE] Definition of "derivative work" [message #8426 is a reply to message #8395] Tue, 14 December 2004 22:47 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: myname(with.between names).lombardisoftware.com

Interesting link. You might be right on the FSF and linking, but I don't see
how that document matches your original statement about how java needed to
split libraries into two parts with an interface part with a less
restrictive license.. I found this statement in there:

"FSF's position has remained constant throughout: the LGPL works as intended
with all known programming languages, including Java. Applications which
link to LGPL libraries need not be released under the LGPL. Applications
need only follow the requirements in section 6 of the LGPL: allow new
versions of the library to be linked with the application; and allow
reverse engineering to debug this."

and

"If you distribute a Java application that imports LGPL libraries, it's easy
to comply with the LGPL. Your application's license needs to allow users to
modify the library, and reverse engineer your code to debug these
modifications. This doesn't mean you need to provide source code or any
details about the internals of your application. Of course, some changes
the users may make to the library may break the interface, rendering the
library unable to work with your application. You don't need to worry about
that -- people who modify the library are responsible for making it work."

So if I "link" to a LGPL library, I do not need to LGPL my application. And
hence, from this writeup you refer to, it doesn't sound like its needed to
split all code into two parts with different licenses. I would assume
CPL/EPL would work similarly.

CL [dnoyeb] Gilbert wrote:

> Morten Moeller wrote:
>> I guess I would disagree on your definition of derivative work and java.
>> IANAL either, nor an expert in licenses, but that never stopped me from
>> having an opinion ;)
>>
>> All use of libraries (jars) in java are dynamicly linked. Your
>> jar/classes never incorporate the other classes they uses externally
>> (static linking), they are only linked by names. There is absolutely not
>> a single byte taken from any eclipse jar into my jars that uses the
>> eclipse jars. So, if I type (as an example was on eclipse.platform)
>> "import org.eclipse.xx.yy" in my class does not make my class a
>> derivative work of org.eclipse.xx.yy. if my class extend
>> org.eclipse.actions.IAction does not make me a derivative work of IAction
>> either, I'm just dynamicly linking to the jar without using their source
>> directly into my product. If I change org.eclipse.actions.IAction or copy
>> and extend the code, it is derivative work.
>>
>
> If what you claim about dynamic linking were true, than no java class
> could be protected because they are all connected in that way. The FSF
> does not want to see one sneaking by because they dynamically linked as
> opposed to static link. Honestly, this violates the purpose of the
> protection. You are using the copyrighted work within your own work.
>
> The FSF does not care if its static or dynamic linking. What they care
> about is inclusion;
>
> 1. If your object files contain portions from the elements produced by
> compiling the copyrighted work, you are derivative.
>
> 2. If your source files contain copied code from the copyrighted work,
> you are derivative.
>
> 3. If your source files contain signatures of the copyrighted work, you
> are derivative.
>
> That forms the basis of the FSFs position on what is and is not a
> derivative work, right or wrong. Anytime the class must be present for
> your class to compile you are derivative. When you compile your class
> with this imported class, the signature of the imported class will be
> present in your class file. You can check this with "javap." Thus you
> have the signature of a copyrighted work, present in your generated
> .class file. You have a derivative work.
>
>
> That is my interpretation of how one can reach this conclusion,
> nevertheless, the conclusion is certainly reached by the FSF see
> http://www.gnu.org/licenses/lgpl-java.html
>
>
>> So I would disagree with your second statements around java; in java you
>> don't staticly link to any "header" as you probably would in c/c++. You
>> always just dynamicly link. So the whole interface thing is not needed.
>> c/c++ is different as you require .h header files in additions to the
>> dll/so's.
>
> there is no difference. java requires interfaces or classes, c/c++
> requires headers. In c if you dynamically link, but you include the
> header which is under the LGPL, you are still derivative. To
> effectively use the LGPL you must have a header that is not under the
> LGPL. That is my interpretation, and I believe consistent with the FSF.
> I could be wrong.
>
> It is up to the creator of the work to draw the line of useability vs,
> extensibility based on what license he puts on what file.
>
>
>
>
Re: [LICENSE] Definition of "derivative work" [message #8457 is a reply to message #8426] Wed, 15 December 2004 04:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Morten Moeller wrote:
> Interesting link. You might be right on the FSF and linking, but I don't see
> how that document matches your original statement about how java needed to
> split libraries into two parts with an interface part with a less
> restrictive license.. I found this statement in there:
>
> "FSF's position has remained constant throughout: the LGPL works as intended
> with all known programming languages, including Java. Applications which
> link to LGPL libraries need not be released under the LGPL. Applications
> need only follow the requirements in section 6 of the LGPL: allow new
> versions of the library to be linked with the application; and allow
> reverse engineering to debug this."
>

Well contrary to what i said before, the LGPL does make special
provisions for derivative works

(Section 5 "... If such an object file uses only numerical parameters,
data structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object file
is unrestricted, regardless of whether it is legally a derivative work.
(Executables containing this object code plus portions of the Library
will still fall under Section 6.)

Note that they do not claim it is NOT a derivative work, just that it
can be used regardless.


> and
>
> "If you distribute a Java application that imports LGPL libraries, it's easy
> to comply with the LGPL. Your application's license needs to allow users to
> modify the library, and reverse engineer your code to debug these
> modifications. This doesn't mean you need to provide source code or any
> details about the internals of your application. Of course, some changes
> the users may make to the library may break the interface, rendering the
> library unable to work with your application. You don't need to worry about
> that -- people who modify the library are responsible for making it work."
>
> So if I "link" to a LGPL library, I do not need to LGPL my application. And
> hence, from this writeup you refer to, it doesn't sound like its needed to
> split all code into two parts with different licenses. I would assume
> CPL/EPL would work similarly.
>

No, see below;

Section 5 "...However, linking a "work that uses the Library" with the
Library creates an executable that is a derivative of the Library
(because it contains portions of the Library), rather than a "work that
uses the library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables..."

Again, they are clear in their considering this linked executable a
derivative work. They just have special provisions to allow the
distribution of this as described in section 6.

Since the CPL lacks any special provisions for the distribution of
derivative works...



The crux of our issue is stated in section 5

"... When a "work that uses the Library" uses material from a header
file that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be linked
without the Library, or if the work is itself a library. The threshold
for this to be true is not precisely defined by law..."

The split I am asking for is that the work not even use the library. My
business logic does not import or use any eclipse classes. But my GUI
classes are steeped.

It is interesting to note that this question is according to the LGPL
legally unresolved.

--
Respectfully,


CL Gilbert

"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber."

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D

For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
Re: [LICENSE] Definition of "derivative work" [message #8518 is a reply to message #8147] Fri, 17 December 2004 21:39 Go to previous messageGo to next message
Mike Milinkovich is currently offline Mike MilinkovichFriend
Messages: 260
Registered: July 2009
Senior Member
CL,

As discussed in the bugzilla entries, the definition of "derivative work" is
ambiguous.

We here at the Foundation are looking into whether it would make sense to
have our own explicit definition of what we mean by the term. But given
holidays, etc. it will take us some time to complete this. Stay tuned.

"CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
news:cpn7kv$bjj$1@www.eclipse.org...
> Myself and another person were having a license discussion in the platform
> newsgroup when a helpful poster suggested we bring it here. I came hear
> and read a bit and think this is the correct place.
>
> The issue is the definition of derivative work. I will repost my position
> from the other forum here.
>
>
> The GPLs position on derivative work has not changed with the emergence of
> Java. For instance when one has a library he intends to be useable by
> others he may license it under the LGPL. Which means you can link to it
> without being required to release your source provided
>
> 1. You link 'dynamically' which means your object code will not contain
> any of the libraries code.
>
> 2. The header file you use to link dynamically is NOT under the LGPL,
> because you are still 'statically' linking to the header, and your end
> work is still a derivative of this header.
>
> It seems that many people have historically released their libraries under
> the LGPL without releasing the headers under a freer license. Thus,
> improperly using the LGPL. The GPL would prevent the use of this header
> file in the library without the header being itself GPL compatable. The
> LGPL allows the use of this header in the library without the header being
> GPL compatible. This is the main reason the LGPL is better for libraries.
> With this header one can now dynamically link to the library _without_
> including any part of said library in his own code.
>
> Jump forward to Java and this same situation is present with the LGPL and
> the CPL. Both allow you to link to the work freely (unlike GPL), but not
> to become a derivative work freely (just like GPL). The way to deal with
> this I believe is as it has been(so I have read): Create a library of the
> interfaces, and release that under a freer license. That is how it is
> handled historically with c, c++, etc. and the LGPL, that is how it should
> be handled in Java.
>
>
>
> Summary
>
> One of two things needs to happen;
>
> a.) IBM must specify its own definition of "derivative work" and have
> that present in the definitions section of the license, and have that
> definition not include "linking" at runtime. But how IBM can do this and
> still protect the Eclipse source from exploitation is unclear due to the
> myriad ways of 'linking' in Java.
>
> b.) The Eclipse Project must package the interfaces to the Eclipse
> Platform (the portions that do not need protection from exploitation) in
> seperate jar files, under a seperate freer license.
>
>
> Needless to say, some do not agree. What is your position?
>
>
> --
> Respectfully,
>
>
> CL Gilbert
>
> "Verily, verily, I say unto you, He that entereth not by the door() into
> the sheepfold{}, but climbeth up some other *way, the same is a thief and
> a robber."
>
> GnuPG Key Fingerprint:
> 82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
>
> For a free Java interface to Freechess.org see
> http://www.rigidsoftware.com/Chess/chess.html
Re: [LICENSE] Definition of "derivative work" [message #14972 is a reply to message #8147] Wed, 16 February 2005 17:06 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bob.objfac.com

CL [dnoyeb] Gilbert wrote:

> Myself and another person were having a license discussion in the
> platform newsgroup when a helpful poster suggested we bring it here. I
> came hear and read a bit and think this is the correct place.
>
> The issue is the definition of derivative work. I will repost my
> position from the other forum here.
>
> The GPLs position on derivative work has not changed with the emergence
> of Java. For instance when one has a library he intends to be useable
> by others he may license it under the LGPL. Which means you can link to
> it without being required to release your source provided

This question seems to start off on the wrong foot, trying to figure out
what the CPL/EPL mean by "derived work" by looking at what the GPL/LGPL
mean by it. The GPL/LGPL's position on derived work are irrelevant.

Bob Foster

>
> 1. You link 'dynamically' which means your object code will not contain
> any of the libraries code.
>
> 2. The header file you use to link dynamically is NOT under the LGPL,
> because you are still 'statically' linking to the header, and your end
> work is still a derivative of this header.
>
> It seems that many people have historically released their libraries
> under the LGPL without releasing the headers under a freer license.
> Thus, improperly using the LGPL. The GPL would prevent the use of this
> header file in the library without the header being itself GPL
> compatable. The LGPL allows the use of this header in the library
> without the header being GPL compatible. This is the main reason the
> LGPL is better for libraries. With this header one can now dynamically
> link to the library _without_ including any part of said library in his
> own code.
>
> Jump forward to Java and this same situation is present with the LGPL
> and the CPL. Both allow you to link to the work freely (unlike GPL),
> but not to become a derivative work freely (just like GPL). The way to
> deal with this I believe is as it has been(so I have read): Create a
> library of the interfaces, and release that under a freer license. That
> is how it is handled historically with c, c++, etc. and the LGPL, that
> is how it should be handled in Java.
>
>
>
> Summary
>
> One of two things needs to happen;
>
> a.) IBM must specify its own definition of "derivative work" and have
> that present in the definitions section of the license, and have that
> definition not include "linking" at runtime. But how IBM can do this
> and still protect the Eclipse source from exploitation is unclear due to
> the myriad ways of 'linking' in Java.
>
> b.) The Eclipse Project must package the interfaces to the Eclipse
> Platform (the portions that do not need protection from exploitation) in
> seperate jar files, under a seperate freer license.
>
>
> Needless to say, some do not agree. What is your position?
>
>
Re: [LICENSE] Definition of "derivative work" [message #15100 is a reply to message #14972] Thu, 17 February 2005 02:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Bob Foster wrote:
> CL [dnoyeb] Gilbert wrote:
>
>> Myself and another person were having a license discussion in the
>> platform newsgroup when a helpful poster suggested we bring it here.
>> I came hear and read a bit and think this is the correct place.
>>
>> The issue is the definition of derivative work. I will repost my
>> position from the other forum here.
>>
>> The GPLs position on derivative work has not changed with the
>> emergence of Java. For instance when one has a library he intends to
>> be useable by others he may license it under the LGPL. Which means
>> you can link to it without being required to release your source provided
>
>
> This question seems to start off on the wrong foot, trying to figure out
> what the CPL/EPL mean by "derived work" by looking at what the GPL/LGPL
> mean by it. The GPL/LGPL's position on derived work are irrelevant.
>
> Bob Foster
>

Ok, so who's position is relevant? The CPL/EPL? They have yet to
define what the term means. If they don't define the term, it will be
defined resonably by the industry. The answer is for them to define it,
but we are not yet so lucky.

If you had read the whole post you would have seen this expressed within.


CL
Re: [LICENSE] Definition of "derivative work" [message #15127 is a reply to message #15100] Thu, 17 February 2005 06:18 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bob.objfac.com

I did read through this thread, which is what prompted me to back up to
near the beginning. It wasn't going anywhere.

No, the "industry" won't define the terms of a license. The courts will.

I've seen Mike Milinkovich suggest in other threads he would like to
explain "derivative work" in plain language. That can only mean he no
longer has the benefit of IBM's lawyers. ;-}

Bob Foster

CL [dnoyeb] Gilbert wrote:
> Bob Foster wrote:
>
>> CL [dnoyeb] Gilbert wrote:
>>
>>> Myself and another person were having a license discussion in the
>>> platform newsgroup when a helpful poster suggested we bring it here.
>>> I came hear and read a bit and think this is the correct place.
>>>
>>> The issue is the definition of derivative work. I will repost my
>>> position from the other forum here.
>>>
>>> The GPLs position on derivative work has not changed with the
>>> emergence of Java. For instance when one has a library he intends to
>>> be useable by others he may license it under the LGPL. Which means
>>> you can link to it without being required to release your source
>>> provided
>>
>>
>>
>> This question seems to start off on the wrong foot, trying to figure
>> out what the CPL/EPL mean by "derived work" by looking at what the
>> GPL/LGPL mean by it. The GPL/LGPL's position on derived work are
>> irrelevant.
>>
>> Bob Foster
>
> Ok, so who's position is relevant? The CPL/EPL? They have yet to
> define what the term means. If they don't define the term, it will be
> defined resonably by the industry. The answer is for them to define it,
> but we are not yet so lucky.
>
> If you had read the whole post you would have seen this expressed within.
>
>
> CL
Re: [LICENSE] Definition of "derivative work" [message #15213 is a reply to message #15127] Thu, 17 February 2005 13:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Bob Foster wrote:
> I did read through this thread, which is what prompted me to back up to
> near the beginning. It wasn't going anywhere.
>
> No, the "industry" won't define the terms of a license. The courts will.

That is what I mean. The courts will look at how the industry has used
the term, and make a decision.

>
> I've seen Mike Milinkovich suggest in other threads he would like to
> explain "derivative work" in plain language. That can only mean he no
> longer has the benefit of IBM's lawyers. ;-}
>
> Bob Foster
>

The problem is the term is used in the license but not explained _at
all_. Their is not even a loose definition. That way its used, one
would think that the license writers felt that it is such a common term
that it does not need definition. My mention of the GPL/LGPL was mainly
to cite that they used the term AND they define it within their license.
And what that same definition would mean to the EPL/CPL. Also that
they expressed a feeling that the definition may not be sufficient and
gave specific rights to software, even if it is a 'derivative work.'

I have really 2 arguments.

1. the term needs to be defined. If it were defined according to GPL
then it would mean certain architectural changes have to take place in
the code.

2. If you define it in any way other than the GPL's, then you risk
exposing Eclipse to uncredited exploitation. (unless that is ok, in
which case why use EPL just use BSD...)



CL
Re: [LICENSE] Definition of "derivative work" [message #15246 is a reply to message #15213] Fri, 18 February 2005 06:39 Go to previous messageGo to next message
Steve Blass is currently offline Steve BlassFriend
Messages: 121
Registered: July 2009
Senior Member
CL [dnoyeb] Gilbert wrote:
> Bob Foster wrote:
>
>> I did read through this thread, which is what prompted me to back up
>> to near the beginning. It wasn't going anywhere.
>>
>> No, the "industry" won't define the terms of a license. The courts will.
>
>
> That is what I mean. The courts will look at how the industry has used
> the term, and make a decision.
>
>>
>> I've seen Mike Milinkovich suggest in other threads he would like to
>> explain "derivative work" in plain language. That can only mean he no
>> longer has the benefit of IBM's lawyers. ;-}
>>
>> Bob Foster
>>
>
> The problem is the term is used in the license but not explained _at
> all_. Their is not even a loose definition. That way its used, one
> would think that the license writers felt that it is such a common term
> that it does not need definition. My mention of the GPL/LGPL was mainly
> to cite that they used the term AND they define it within their license.
> And what that same definition would mean to the EPL/CPL. Also that
> they expressed a feeling that the definition may not be sufficient and
> gave specific rights to software, even if it is a 'derivative work.'
>
> I have really 2 arguments.
>
> 1. the term needs to be defined. If it were defined according to GPL
> then it would mean certain architectural changes have to take place in
> the code.
>
> 2. If you define it in any way other than the GPL's, then you risk
> exposing Eclipse to uncredited exploitation. (unless that is ok, in
> which case why use EPL just use BSD...)
>
>
>
> CL

In general, when terms are not explicitly defined they are taken at face
value where the fall back is the dictionary definition and the
understanding engendered by general use. GPL is not the only place one
finds use of the term derivative work applied to software.

Some of the US Circuit courts have established some tests for what is a
derivative work in software and US Copyright law has a handful of
paragraphs that apply to derivative works as related to software.
Mileage will vary by jurisdiction regardless.

There is probably more risk attached by defining it explicitly else it
would have been defined in the CPL as published by IBM, eh?

Pay your money, take your choices, don't be a thief and give credit
where it is due.

EPL says you can distribute object code under your own license but that
you must indemnify Contributors and offer source to your licensees. It
also says that when provided, the source must be provided in accordance
with EPL. I think that means that I do not have to give my source away
for free, but that my customer may if they so choose once they get their
hands on it.

IANAL WIACPID
-
Steve
Re: [LICENSE] Definition of "derivative work" [message #15379 is a reply to message #15246] Sat, 19 February 2005 05:46 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bob.objfac.com

Steve Blass wrote:
> EPL says you can distribute object code under your own license but that
> you must indemnify Contributors and offer source to your licensees. It
> also says that when provided, the source must be provided in accordance
> with EPL. I think that means that I do not have to give my source away
> for free, but that my customer may if they so choose once they get their
> hands on it.

Not exactly. The EPL says only that you must offer source for code
licensed under the EPL. It does not say that you must offer source for
your own code, unless it is a modification of EPL code. Just linking
your code to EPL code does not require you to ship source to your code.

You probably already know this, but I mention it because it seems people
used to the GPL find this a hard concept to grasp.

Bob Foster
Re: [LICENSE] Definition of "derivative work" [message #15445 is a reply to message #15246] Sat, 19 February 2005 14:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Steve Blass wrote:
> CL [dnoyeb] Gilbert wrote:
>
>> Bob Foster wrote:
>>
>>> I did read through this thread, which is what prompted me to back up
>>> to near the beginning. It wasn't going anywhere.
>>>
>>> No, the "industry" won't define the terms of a license. The courts will.
>>
>>
>>
>> That is what I mean. The courts will look at how the industry has
>> used the term, and make a decision.
>>
>>>
>>> I've seen Mike Milinkovich suggest in other threads he would like to
>>> explain "derivative work" in plain language. That can only mean he no
>>> longer has the benefit of IBM's lawyers. ;-}
>>>
>>> Bob Foster
>>>
>>
>> The problem is the term is used in the license but not explained _at
>> all_. Their is not even a loose definition. That way its used, one
>> would think that the license writers felt that it is such a common
>> term that it does not need definition. My mention of the GPL/LGPL was
>> mainly to cite that they used the term AND they define it within their
>> license. And what that same definition would mean to the EPL/CPL.
>> Also that they expressed a feeling that the definition may not be
>> sufficient and gave specific rights to software, even if it is a
>> 'derivative work.'
>>
>> I have really 2 arguments.
>>
>> 1. the term needs to be defined. If it were defined according to GPL
>> then it would mean certain architectural changes have to take place in
>> the code.
>>
>> 2. If you define it in any way other than the GPL's, then you risk
>> exposing Eclipse to uncredited exploitation. (unless that is ok, in
>> which case why use EPL just use BSD...)
>>
>>
>>
>> CL
>
>
> In general, when terms are not explicitly defined they are taken at face
> value where the fall back is the dictionary definition and the
> understanding engendered by general use. GPL is not the only place one
> finds use of the term derivative work applied to software.
>
> Some of the US Circuit courts have established some tests for what is a
> derivative work in software and US Copyright law has a handful of
> paragraphs that apply to derivative works as related to software.
> Mileage will vary by jurisdiction regardless.
>
> There is probably more risk attached by defining it explicitly else it
> would have been defined in the CPL as published by IBM, eh?
>

You assume an awful lot here. In american politics there is the idea
that you either define yourself, or be defined. Nobody wants to be
defined. Why should IBM whish to have others than IBM define the scope
of the license created for and used by IBM?


definition would be better. GPL does it, LGPL does it, why not EPL?

CL
Re: [LICENSE] Definition of "derivative work" [message #15478 is a reply to message #15379] Sat, 19 February 2005 14:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Bob Foster wrote:
> Steve Blass wrote:
>
>> EPL says you can distribute object code under your own license but
>> that you must indemnify Contributors and offer source to your
>> licensees. It also says that when provided, the source must be
>> provided in accordance with EPL. I think that means that I do not
>> have to give my source away for free, but that my customer may if they
>> so choose once they get their hands on it.
>
>
> Not exactly. The EPL says only that you must offer source for code
> licensed under the EPL. It does not say that you must offer source for
> your own code, unless it is a modification of EPL code. Just linking
> your code to EPL code does not require you to ship source to your code.
>
Lol, but this is what this whole discussion is about. What you say is
all true until your program becomes a 'derivative work.'



> You probably already know this, but I mention it because it seems people
> used to the GPL find this a hard concept to grasp.
>
> Bob Foster

The GPL would insist on code release, the LGPL, with architectural
enhancements, would not. There is no ambiguity and that is a good
thing. Its not clear where the EPL sits because the EPL passes the buck
to the term 'derivative work.' The license itself is supposed to define
how the thing can be used, not pass it on to some other entity.


My LGPL point was 2 fold.

1. The LGPL defines the term 'derivative work.'
2. The LGPL mentions that defining the term is somewhat difficult, and
as a result they specifically grant rights to certain programs, even if
they are found later to be derivative works. Looks like they thought it
through all the way.
Re: [LICENSE] Definition of "derivative work" [message #19183 is a reply to message #8518] Fri, 22 April 2005 20:49 Go to previous messageGo to next message
Rob Lintern is currently offline Rob LinternFriend
Messages: 12
Registered: July 2009
Junior Member
Mike Milinkovich wrote:

> CL,

> As discussed in the bugzilla entries, the definition of "derivative work" is
> ambiguous.

> We here at the Foundation are looking into whether it would make sense to
> have our own explicit definition of what we mean by the term. But given
> holidays, etc. it will take us some time to complete this. Stay tuned.

Any progress on this?

We've been advised by a lawyer here at the University of Victoria, BC,
that in absence of a definition of "derivative work" that we treat
anything we produce with eclipse (not just plug-ins etc.) as a derived
work. I have a hard time accepting this advice.

I was very much hoping to get a better indication or guidance from this
thread but...I guess not. I suppose we'll stick with the lawyer's advice
since doing otherwise is "at our own risk!"

Cheers,
Rob
www.thechiselgroup.org




> "CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
> news:cpn7kv$bjj$1@www.eclipse.org...
>> Myself and another person were having a license discussion in the platform
>> newsgroup when a helpful poster suggested we bring it here. I came hear
>> and read a bit and think this is the correct place.
>>
>> The issue is the definition of derivative work. I will repost my position
>> from the other forum here.
>>
>>
>> The GPLs position on derivative work has not changed with the emergence of
>> Java. For instance when one has a library he intends to be useable by
>> others he may license it under the LGPL. Which means you can link to it
>> without being required to release your source provided
>>
>> 1. You link 'dynamically' which means your object code will not contain
>> any of the libraries code.
>>
>> 2. The header file you use to link dynamically is NOT under the LGPL,
>> because you are still 'statically' linking to the header, and your end
>> work is still a derivative of this header.
>>
>> It seems that many people have historically released their libraries under
>> the LGPL without releasing the headers under a freer license. Thus,
>> improperly using the LGPL. The GPL would prevent the use of this header
>> file in the library without the header being itself GPL compatable. The
>> LGPL allows the use of this header in the library without the header being
>> GPL compatible. This is the main reason the LGPL is better for libraries.
>> With this header one can now dynamically link to the library _without_
>> including any part of said library in his own code.
>>
>> Jump forward to Java and this same situation is present with the LGPL and
>> the CPL. Both allow you to link to the work freely (unlike GPL), but not
>> to become a derivative work freely (just like GPL). The way to deal with
>> this I believe is as it has been(so I have read): Create a library of the
>> interfaces, and release that under a freer license. That is how it is
>> handled historically with c, c++, etc. and the LGPL, that is how it should
>> be handled in Java.
>>
>>
>>
>> Summary
>>
>> One of two things needs to happen;
>>
>> a.) IBM must specify its own definition of "derivative work" and have
>> that present in the definitions section of the license, and have that
>> definition not include "linking" at runtime. But how IBM can do this and
>> still protect the Eclipse source from exploitation is unclear due to the
>> myriad ways of 'linking' in Java.
>>
>> b.) The Eclipse Project must package the interfaces to the Eclipse
>> Platform (the portions that do not need protection from exploitation) in
>> seperate jar files, under a seperate freer license.
>>
>>
>> Needless to say, some do not agree. What is your position?
>>
>>
>> --
>> Respectfully,
>>
>>
>> CL Gilbert
>>
>> "Verily, verily, I say unto you, He that entereth not by the door() into
>> the sheepfold{}, but climbeth up some other *way, the same is a thief and
>> a robber."
>>
>> GnuPG Key Fingerprint:
>> 82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
>>
>> For a free Java interface to Freechess.org see
>> http://www.rigidsoftware.com/Chess/chess.html
Re: [LICENSE] Definition of "derivative work" [message #19203 is a reply to message #19183] Mon, 25 April 2005 13:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Rob Lintern wrote:
> Mike Milinkovich wrote:
>
>> CL,
>
>
>> As discussed in the bugzilla entries, the definition of "derivative
>> work" is ambiguous.
>
>
>> We here at the Foundation are looking into whether it would make sense
>> to have our own explicit definition of what we mean by the term. But
>> given holidays, etc. it will take us some time to complete this. Stay
>> tuned.
>
>
> Any progress on this?
> We've been advised by a lawyer here at the University of Victoria, BC,
> that in absence of a definition of "derivative work" that we treat
> anything we produce with eclipse (not just plug-ins etc.) as a derived
> work. I have a hard time accepting this advice.
>

What do you mean by "produce with" Eclipse? Do you mean programs that
run ontop of Eclipse in some way, or are you including general Java
programs that run in the absence of Eclipse?



> I was very much hoping to get a better indication or guidance from this
> thread but...I guess not. I suppose we'll stick with the lawyer's advice
> since doing otherwise is "at our own risk!"
>

Risk can be measured by how many lawyers you can afford :)


CL



> Cheers,
> Rob
> www.thechiselgroup.org
>
>
>
>
>> "CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in
>> message news:cpn7kv$bjj$1@www.eclipse.org...
>>
>>> Myself and another person were having a license discussion in the
>>> platform newsgroup when a helpful poster suggested we bring it here.
>>> I came hear and read a bit and think this is the correct place.
>>>
>>> The issue is the definition of derivative work. I will repost my
>>> position from the other forum here.
>>>
>>>
>>> The GPLs position on derivative work has not changed with the
>>> emergence of Java. For instance when one has a library he intends to
>>> be useable by others he may license it under the LGPL. Which means
>>> you can link to it without being required to release your source
>>> provided
>>>
>>> 1. You link 'dynamically' which means your object code will not
>>> contain any of the libraries code.
>>>
>>> 2. The header file you use to link dynamically is NOT under the LGPL,
>>> because you are still 'statically' linking to the header, and your
>>> end work is still a derivative of this header.
>>>
>>> It seems that many people have historically released their libraries
>>> under the LGPL without releasing the headers under a freer license.
>>> Thus, improperly using the LGPL. The GPL would prevent the use of
>>> this header file in the library without the header being itself GPL
>>> compatable. The LGPL allows the use of this header in the library
>>> without the header being GPL compatible. This is the main reason the
>>> LGPL is better for libraries. With this header one can now
>>> dynamically link to the library _without_ including any part of said
>>> library in his own code.
>>>
>>> Jump forward to Java and this same situation is present with the LGPL
>>> and the CPL. Both allow you to link to the work freely (unlike GPL),
>>> but not to become a derivative work freely (just like GPL). The way
>>> to deal with this I believe is as it has been(so I have read):
>>> Create a library of the interfaces, and release that under a freer
>>> license. That is how it is handled historically with c, c++, etc.
>>> and the LGPL, that is how it should be handled in Java.
>>>
>>>
>>>
>>> Summary
>>>
>>> One of two things needs to happen;
>>>
>>> a.) IBM must specify its own definition of "derivative work" and
>>> have that present in the definitions section of the license, and have
>>> that definition not include "linking" at runtime. But how IBM can do
>>> this and still protect the Eclipse source from exploitation is
>>> unclear due to the myriad ways of 'linking' in Java.
>>>
>>> b.) The Eclipse Project must package the interfaces to the Eclipse
>>> Platform (the portions that do not need protection from exploitation)
>>> in seperate jar files, under a seperate freer license.
>>>
>>>
>>> Needless to say, some do not agree. What is your position?
>>>
>>>
>>> --
>>> Respectfully,
>>>
>>>
>>> CL Gilbert
>>>
>>> "Verily, verily, I say unto you, He that entereth not by the door()
>>> into the sheepfold{}, but climbeth up some other *way, the same is a
>>> thief and a robber."
>>>
>>> GnuPG Key Fingerprint:
>>> 82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
>>>
>>> For a free Java interface to Freechess.org see
>>> http://www.rigidsoftware.com/Chess/chess.html
>
>
>
Re: [LICENSE] Definition of "derivative work" [message #24853 is a reply to message #15379] Wed, 05 October 2005 05:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: allan.hardy.com

I to am learning/struggling with understanding of its 'ok' to develop an RCP
based solution and not be considered a derived work.



Derived work is not a defined term, not in any license. Anyone arguing the
GPL folks have a working definition are simply wrong. Understanding what a
derived work under GPL is can be an extremely complex task, one that looks
at not only the "technical form of the integration but also the semantics of
the communication between applications". The quoted comments made directly
from the FSF Compliancy Lab. Imagine a staffed lab is needed to try and
figure out if a product is a derived work. Trust me when I say I have met
with lawyers at FSF, been in training classes by their engineers/legal staff
and know that in cases other then flat out copying, defining derivative work
can be like nailing jelly to a tree.



Ok, sorry for the FSF / GPL rant.



Now another point made earlier - that a judge will decide, is basically spot
on.

However, 11 Federal district courts have come up with at least 4 test /
procedures to define a derived software work, so even when one court
defines, it's not all courts.



All in all does not the first step sit with the copyright owner? They are
the only ones that can take any action, put a restraining order from me
distributing my work, sue for statuary damages under copyright law, etc.



For now I am assuming this is the eclipse foundation (RCP) assuming they get
assignments from contributors (but I don't know this is the case)



So it seems to me that knowing what the Eclipse Foundation says about a
derivative work could provide significant guidance to us folks that want to
play fair. Establishing at least two end post, what is a clear derived
work, what is clearly not a derived work (with rational) could be a start.
There will always be the desire for us to pin down everything else in
between. Which can never happen of course, but over time might get better..



In the studying I have done to date of eclipse plugins and RCP based
solutions I conclude so far that the eclipse foundation/community is more
open to having commercial/proprietary licensed works using the eclipse
technologies then say the FSF community. I say this because I see
commercial eclipse plugins from IBM and many others that are active Eclipse
contributors. In the RCP space I've seen a NASA application that offers no
open source and uses a non commercial terms (non EPL terms) for a RCP
application. This all shows to me that since the eclipse foundation isn't
in discussion with these folks then they don't believe a violation is
happening.



Now Bob Foster made a very specific definition earlier:



-The EPL says only that you must offer source for code licensed under the
EPL.

-It does not say that you must offer source for your own code, unless it is
a modification of EPL code.

-Just linking your code to EPL code does not require you to ship source to
your code.



I don't know if Bob speaks for the eclipse foundation, but this adds some
clarity not found in GPL land, that linking does not invoke derived work.
This is cool for plugins.



The use of RCP as a middleware does seem to confuse things. Consider, I
deliver a standalone solution that has at it's core a direct copy of the
eclipse EPL code, where if a court compares my application to RCP they would
find direct copies, perhaps for a substantial part of the final solution.
That could easily be seen as a derived work. But on the other hand, if my
final solution is built through adding in plugin modules, perhaps the
plugin/just linking rule comes in?



In short, while eclipse foundation cannot define derive work for the court,
they can tell us where they draw the line - as guidance, and I can then
decide if I want to follow their line, or push it etc.



What kind of commercial market do you want to see built up around RCP?



Allan Hardy
Re: [LICENSE] Definition of "derivative work" [message #24941 is a reply to message #24853] Wed, 05 October 2005 15:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

AllanH wrote:
> I to am learning/struggling with understanding of its 'ok' to develop an RCP
> based solution and not be considered a derived work.
>
>
>
> Derived work is not a defined term, not in any license. Anyone arguing the
> GPL folks have a working definition are simply wrong. Understanding what a
> derived work under GPL is can be an extremely complex task, one that looks
> at not only the "technical form of the integration but also the semantics of
> the communication between applications". The quoted comments made directly
> from the FSF Compliancy Lab. Imagine a staffed lab is needed to try and
> figure out if a product is a derived work. Trust me when I say I have met
> with lawyers at FSF, been in training classes by their engineers/legal staff
> and know that in cases other then flat out copying, defining derivative work
> can be like nailing jelly to a tree.
>
>
>
> Ok, sorry for the FSF / GPL rant.
>
>
>
> Now another point made earlier - that a judge will decide, is basically spot
> on.
>
> However, 11 Federal district courts have come up with at least 4 test /
> procedures to define a derived software work, so even when one court
> defines, it's not all courts.
>
>
>
> All in all does not the first step sit with the copyright owner? They are
> the only ones that can take any action, put a restraining order from me
> distributing my work, sue for statuary damages under copyright law, etc.
>
>
>
> For now I am assuming this is the eclipse foundation (RCP) assuming they get
> assignments from contributors (but I don't know this is the case)
>
>
>
> So it seems to me that knowing what the Eclipse Foundation says about a
> derivative work could provide significant guidance to us folks that want to
> play fair. Establishing at least two end post, what is a clear derived
> work, what is clearly not a derived work (with rational) could be a start.
> There will always be the desire for us to pin down everything else in
> between. Which can never happen of course, but over time might get better..
>
>
>
> In the studying I have done to date of eclipse plugins and RCP based
> solutions I conclude so far that the eclipse foundation/community is more
> open to having commercial/proprietary licensed works using the eclipse
> technologies then say the FSF community. I say this because I see
> commercial eclipse plugins from IBM and many others that are active Eclipse
> contributors. In the RCP space I've seen a NASA application that offers no
> open source and uses a non commercial terms (non EPL terms) for a RCP
> application. This all shows to me that since the eclipse foundation isn't
> in discussion with these folks then they don't believe a violation is
> happening.
>
>
>
> Now Bob Foster made a very specific definition earlier:
>
>
>
> -The EPL says only that you must offer source for code licensed under the
> EPL.
>
> -It does not say that you must offer source for your own code, unless it is
> a modification of EPL code.
>
> -Just linking your code to EPL code does not require you to ship source to
> your code.
>
>
>
> I don't know if Bob speaks for the eclipse foundation, but this adds some
> clarity not found in GPL land, that linking does not invoke derived work.
> This is cool for plugins.
>
>
>
> The use of RCP as a middleware does seem to confuse things. Consider, I
> deliver a standalone solution that has at it's core a direct copy of the
> eclipse EPL code, where if a court compares my application to RCP they would
> find direct copies, perhaps for a substantial part of the final solution.
> That could easily be seen as a derived work. But on the other hand, if my
> final solution is built through adding in plugin modules, perhaps the
> plugin/just linking rule comes in?
>
>
>
> In short, while eclipse foundation cannot define derive work for the court,
> they can tell us where they draw the line - as guidance, and I can then
> decide if I want to follow their line, or push it etc.
>
>
>
> What kind of commercial market do you want to see built up around RCP?
>
>
>
> Allan Hardy
>
>
>
>


I have been over this here and have given up. Undefined terms like
'derivative work' favor those with enough lawyers to define the term
when they feel the need. Thus, I don't expect the major players in
Eclipse to care much.

As for the GPL I can't comment, but the LGPL explicitely states the term
is somewhat vague and continues on to grant you specific rights _even
if_ your program is found to be a derivative work, under spelled out
conditions. So GPL folks at least acknowledge the issue.

If you take the GPLs definition of derivative work (which they designed
to be very broad) then any class required on your classpath to compile,
makes you a derivative work of that class. The GPL would extend this
logic to include runtime linking I believe, whereas the LGPL would not.




CL
Re: [LICENSE] Definition of "derivative work" [message #25233 is a reply to message #24941] Sat, 08 October 2005 17:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bob.objfac.com

Still riding the old hobby horse, eh. ;-}

The GPL/LGPL's definitions of "derived work" have nothing to do with the
EPL. The term will continue to be slippery and subject to legal opinion.

My comment was to the effect that I am absolutely certain that if you
modify EPL-licensed code, the result is a derived work.

I also believe, based on common sense and a sense of fair play, that the
source for the derived work should compile and, if it is a patch to a
larger entity, it should not leave the larger entity less functional
than before. Any files needed to satisfy these conditions would also be
derived. But that's just my opinion.

I know for a fact that some lawyers think "derived work" has something
to do with packaging, e.g., that EPL code should be in separate
"modules", whatever those are. Regardless of the merits of that theory I
understand why a lawyer would want to make the rule, as a safeguard
against commingling proprietary and EPL code to the point it is hard
(that is, too hard for a judge and jury) to sort them out.

Regards,

Bob

CL [dnoyeb] Gilbert wrote:
> AllanH wrote:
>
>> I to am learning/struggling with understanding of its 'ok' to develop
>> an RCP based solution and not be considered a derived work.
>>
>>
>>
>> Derived work is not a defined term, not in any license. Anyone
>> arguing the GPL folks have a working definition are simply wrong.
>> Understanding what a derived work under GPL is can be an extremely
>> complex task, one that looks at not only the "technical form of the
>> integration but also the semantics of the communication between
>> applications". The quoted comments made directly from the FSF
>> Compliancy Lab. Imagine a staffed lab is needed to try and figure out
>> if a product is a derived work. Trust me when I say I have met with
>> lawyers at FSF, been in training classes by their engineers/legal
>> staff and know that in cases other then flat out copying, defining
>> derivative work can be like nailing jelly to a tree.
>>
>>
>>
>> Ok, sorry for the FSF / GPL rant.
>>
>>
>>
>> Now another point made earlier - that a judge will decide, is
>> basically spot on.
>>
>> However, 11 Federal district courts have come up with at least 4 test
>> / procedures to define a derived software work, so even when one court
>> defines, it's not all courts.
>>
>>
>>
>> All in all does not the first step sit with the copyright owner? They
>> are the only ones that can take any action, put a restraining order
>> from me distributing my work, sue for statuary damages under copyright
>> law, etc.
>>
>>
>>
>> For now I am assuming this is the eclipse foundation (RCP) assuming
>> they get assignments from contributors (but I don't know this is the
>> case)
>>
>>
>>
>> So it seems to me that knowing what the Eclipse Foundation says about
>> a derivative work could provide significant guidance to us folks that
>> want to play fair. Establishing at least two end post, what is a
>> clear derived work, what is clearly not a derived work (with rational)
>> could be a start. There will always be the desire for us to pin down
>> everything else in between. Which can never happen of course, but
>> over time might get better..
>>
>>
>>
>> In the studying I have done to date of eclipse plugins and RCP based
>> solutions I conclude so far that the eclipse foundation/community is
>> more open to having commercial/proprietary licensed works using the
>> eclipse technologies then say the FSF community. I say this because I
>> see commercial eclipse plugins from IBM and many others that are
>> active Eclipse contributors. In the RCP space I've seen a NASA
>> application that offers no open source and uses a non commercial terms
>> (non EPL terms) for a RCP application. This all shows to me that
>> since the eclipse foundation isn't in discussion with these folks then
>> they don't believe a violation is happening.
>>
>>
>>
>> Now Bob Foster made a very specific definition earlier:
>>
>>
>>
>> -The EPL says only that you must offer source for code licensed under
>> the EPL.
>>
>> -It does not say that you must offer source for your own code, unless
>> it is a modification of EPL code.
>>
>> -Just linking your code to EPL code does not require you to ship
>> source to your code.
>>
>>
>>
>> I don't know if Bob speaks for the eclipse foundation, but this adds
>> some clarity not found in GPL land, that linking does not invoke
>> derived work. This is cool for plugins.
>>
>>
>>
>> The use of RCP as a middleware does seem to confuse things. Consider,
>> I deliver a standalone solution that has at it's core a direct copy of
>> the eclipse EPL code, where if a court compares my application to RCP
>> they would find direct copies, perhaps for a substantial part of the
>> final solution. That could easily be seen as a derived work. But on
>> the other hand, if my final solution is built through adding in plugin
>> modules, perhaps the plugin/just linking rule comes in?
>>
>>
>>
>> In short, while eclipse foundation cannot define derive work for the
>> court, they can tell us where they draw the line - as guidance, and I
>> can then decide if I want to follow their line, or push it etc.
>>
>>
>>
>> What kind of commercial market do you want to see built up around RCP?
>>
>>
>>
>> Allan Hardy
>>
>>
>>
>>
>
>
> I have been over this here and have given up. Undefined terms like
> 'derivative work' favor those with enough lawyers to define the term
> when they feel the need. Thus, I don't expect the major players in
> Eclipse to care much.
>
> As for the GPL I can't comment, but the LGPL explicitely states the term
> is somewhat vague and continues on to grant you specific rights _even
> if_ your program is found to be a derivative work, under spelled out
> conditions. So GPL folks at least acknowledge the issue.
>
> If you take the GPLs definition of derivative work (which they designed
> to be very broad) then any class required on your classpath to compile,
> makes you a derivative work of that class. The GPL would extend this
> logic to include runtime linking I believe, whereas the LGPL would not.
>
>
>
>
> CL
>
>
>
Re: [LICENSE] Definition of "derivative work" [message #25273 is a reply to message #25233] Tue, 11 October 2005 14:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Bob Foster wrote:
> Still riding the old hobby horse, eh. ;-}

Until my $0.25 runs out :)

>
> The GPL/LGPL's definitions of "derived work" have nothing to do with the
> EPL. The term will continue to be slippery and subject to legal opinion.
>

Not directly, but indirectly as they can and will likely be used in any
court when the question of 'derived work' comes up.

> My comment was to the effect that I am absolutely certain that if you
> modify EPL-licensed code, the result is a derived work.
>

I always agreed with this.

> I also believe, based on common sense and a sense of fair play, that the
> source for the derived work should compile and, if it is a patch to a
> larger entity, it should not leave the larger entity less functional
> than before. Any files needed to satisfy these conditions would also be
> derived. But that's just my opinion.
>

Where the law is concerned I don't believe in common sense or fair play.
But your opinion makes sense.

> I know for a fact that some lawyers think "derived work" has something
> to do with packaging, e.g., that EPL code should be in separate
> "modules", whatever those are. Regardless of the merits of that theory I
> understand why a lawyer would want to make the rule, as a safeguard
> against commingling proprietary and EPL code to the point it is hard
> (that is, too hard for a judge and jury) to sort them out.
>

I have taken the safe route and followed the broad definition given by
the GPL. I guess my view is rather one sided. its safe to me because I
want to use someone else's code. But to protect your code the safe view
may not be the same.

My main plugins are compilable without any support form eclipse
whatsoever. Then I have seperate plugins that do the GUI stuff that do
require eclipse to compile. This is really a natural seperation for an
OO design anyway.


> Regards,
>
> Bob
>

I did submit an enhancement request to eclipse for them to seperate
their code.

I would love to see eclipse's interfaces and abstract classes licensed
completely open with something like the BSD license. And the rest with
the EPL. Thats my pefect world.

There can be no argument against this given the stated intentions in the
FAQ. But I'm not holding my breath.

CL
Re: [LICENSE] Definition of "derivative work" [message #25750 is a reply to message #25273] Mon, 17 October 2005 22:59 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: allan.hardy.com

"CL [dnoyeb] Gilbert" wrote

>> I have taken the safe route and followed the broad definition given by
>> the GPL. I guess my view is rather one sided. its safe to me because I
>> want to use someone else's code. But to protect your code the safe view I
>> have taken the safe route and followed the broad definition given by the
>> GPL.

Could you explain?

GPL, well the FSF as a copyright holder for their set of GPL works, would
say that plug-ins create a new combined work and hence the overall work, and
all its components, would be GPL licensed.

They push the definitions of derived works and collective works and get into
the idea that what many considered to be harmless linking (like plugins) of
Application A and Module B create a new work C, and evertything is GPL'd
licensed.

Your assertion that GPL/ FSF has made a clear definition of Derived Work is
way outside of my experience

I do not understand the assertion that Eclispe Foundation has done anything
less then FSF?
Re: [LICENSE] Definition of "derivative work" [message #25758 is a reply to message #15445] Mon, 17 October 2005 23:11 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: allan.hardy.com

As I said elsewhere, GPL nor LGPL, nor the FSF , nor the compliance lab
needed to figure out what a derive work is have defined anything clear.

The FSF explicity states that they are pushing the boundries of Copyright
law in this area. They have no idea other then direct copying what will
ever hold up in court. The compliancy lab exist and if you put in enough
data (answer questions) they will give output in form of thier opinion on
compliancy. They do not, have not, made the decision process transparent.

They in fact say that to determine if copyleft should be invoked in a new
work, one thats uses some part of GPL, that one needs to look at not only
the Technical aspects of integration (static, dynamic, etc) but also the
Semantics of the integration. A plug-in interface, or a dynamic linking
type interface, would not invoke GPL copyleft in one case, if the semantics
were light enough, while in another case, with semantics that were richer, a
plug-in interface could case GPL copyleft.

From comments made we know they even include the developers intent in thier
analysis. If they feel the developer was writting glue layers for the
purpose of avoiding GPL copyleft, that would count against them.

So lets be clear FSF has definetly not done any better and I could, and do
argue that FSF makes the whole area much more confusing then Eclipse
Foundation.


"CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
news:cv7idu$b5u$2@www.eclipse.org...
> definition would be better. GPL does it, LGPL does it, why not EPL?
>
> CL
Re: [LICENSE] Definition of "derivative work" [message #25799 is a reply to message #25750] Sun, 23 October 2005 03:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

AllanH wrote:
> "CL [dnoyeb] Gilbert" wrote
>
>
>>>I have taken the safe route and followed the broad definition given by
>>>the GPL. I guess my view is rather one sided. its safe to me because I
>>>want to use someone else's code. But to protect your code the safe view I
>>>have taken the safe route and followed the broad definition given by the
>>>GPL.
>
>
> Could you explain?
>
> GPL, well the FSF as a copyright holder for their set of GPL works, would
> say that plug-ins create a new combined work and hence the overall work, and
> all its components, would be GPL licensed.
>

Not plugins, but what you do to make a plugin will create a combined
work. When I say "the safe route", what I mean is to have the belief
that any file I use in my classpath causes my product to be a derived
work of that file. That is how the GPL would define it. The LGPL may
or may not be different. But the LGPL exempets you in certain cases
even if you are found to be derived.

> They push the definitions of derived works and collective works and get into
> the idea that what many considered to be harmless linking (like plugins) of
> Application A and Module B create a new work C, and evertything is GPL'd
> licensed.
>

A plugin in and of itself may be harmless, but how many files did you
import in order to make the connection? How were those files licensed?

> Your assertion that GPL/ FSF has made a clear definition of Derived Work is
> way outside of my experience
>

I never once said FSF gave us a clear definition. I say two things;
One, the FSF pushes a broad definition of the term that meets with their
philosophy. I rather be safe by viewing anything my code touches as
potential source of derivation, than view things like 'no worries m8' do
whatever you want, were all friends here...

The second thing I claim is the FSF speaks to the term within their
license and not in an external non-legally relevant FAQ. And even goes
so far as to state when being derived does not matter.

They address the term quite a bit.

> I do not understand the assertion that Eclispe Foundation has done anything
> less then FSF?
>
>

Eclipse Foundation ignores the term.


CL
Re: [LICENSE] Definition of "derivative work" [message #25919 is a reply to message #25273] Tue, 25 October 2005 17:32 Go to previous messageGo to next message
Mike Milinkovich is currently offline Mike MilinkovichFriend
Messages: 260
Registered: July 2009
Senior Member
"CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
news:digit1$i6d$1@news.eclipse.org...
> Not directly, but indirectly as they can and will likely be used in any
> court when the question of 'derived work' comes up.

<IANAL>
How do you figure that? The LGPL/GPL definitions are not the standard legal
definitions under U.S. copyright law, and there is *nothing* linking the EPL
to either of those documents.

I cannot imagine what would lead you to make this assumption. The Free
Software Foundation did *not* invent the term "derivative work". Their
definition of it within their licenses can only be held as applicable within
their licenses.
</IANAL>
Re: [LICENSE] Definition of "derivative work" [message #25960 is a reply to message #25919] Tue, 25 October 2005 21:14 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Lamont_Gilbert.rigidsoftware.com

Mike Milinkovich wrote:
> "CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
> news:digit1$i6d$1@news.eclipse.org...
>
>>Not directly, but indirectly as they can and will likely be used in any
>>court when the question of 'derived work' comes up.
>
>
> <IANAL>
> How do you figure that? The LGPL/GPL definitions are not the standard legal
> definitions under U.S. copyright law, and there is *nothing* linking the EPL
> to either of those documents.
>
> I cannot imagine what would lead you to make this assumption. The Free
> Software Foundation did *not* invent the term "derivative work". Their
> definition of it within their licenses can only be held as applicable within
> their licenses.
> </IANAL>
>
>

What definition of the term applies to GPL? Its up to the courts to decide.

What definition of the term applies to EPL? Its up to the courts to decide.

What definition of the term applies to LGPL? Doesen't matter because
LGPL does not hinge on the term.


This is my non legal opinion.

CL
Re: [LICENSE] Definition of "derivative work" [message #27150 is a reply to message #25960] Mon, 19 December 2005 21:50 Go to previous message
Adrian Cho is currently offline Adrian ChoFriend
Messages: 18
Registered: July 2009
Junior Member
I am not generally monitoring these newsgroups but happened to see this
thread when I was here to reply to another post.

I'm trying not to give advice here but:

How important is it really to nail down the definition of "derivative work"
in the context of the EPL? Let's just say for argument's sake that a
derivative work of EPL code is any work that contains portions of the EPL
code (any part of it - comments, functional code, whatever) except for the
following:

The parts are API references necessary for either:

a) invoking functionality in the EPL code
b) implementing the API for the EPL code (implementing an interface)
c) extending the EPL code (by subclassing but where the subclass doesn't
include any functional EPL code - just the method signature)

then isn't 1 b) ii) (i) in the EPL, the more important bit of information?
That is, the part about the separate modules.

If you think about it - it's not really that complex.

Adrian
Previous Topic:Powers of 2
Next Topic:EclipseCon Very Early Registration Deadline
Goto Forum:
  


Current Time: Thu Mar 28 22:30:06 GMT 2024

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

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

Back to the top