Home » General (non-technical) » Eclipse Foundation » Derivative work technique
| Derivative work technique [message #18839] |
Sun, 10 April 2005 12:35  |
Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
I proposed before a way to define a derivative work in Java. This was
_any_ class you require in your classpath you are a derivative work of.
The end result is that Eclipse could put all extendable classes in a
certain place, and put them under no license, or a completely
unrestricted license. These would be interfaces mostly which really
should have no license anyway since they are not an implementation.
I recently had another idea. I have created my own HashMap that fits my
purposes. However, there was a method called HashMap.hash(Object) which
I wanted to use but I could not. This method was package private in the
java.util package. Turns out all I had to do to use this method was put
my class in the java.util package as well. Then it occurred to me that
this could be a good technique for defining a derivative work. Package
private methods would cause your class to have to be in an org.eclipse
package to use them. So I thought derivative work could be easy for
developers to know. That is, if your class is in an org.eclipse package
then its a derivative work.
Seems like a nice idea, but I havent worked out how to keep people from
putting simple clases in org.eclipse to expose the methods they want to
use...
CL
|
|
|
| Re: Derivative work technique [message #18865 is a reply to message #18839] |
Sun, 10 April 2005 22:41  |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
I admire your persistence in trying to define 'derivative work' in a way
programmers can understand. But your definitions also need to match up
with what lawyers understand or they aren't much use. (As before, IANAL
but I may have some glimmering how they might see things. FWIW, which
ain't much.)
Your first proposed definition is essentially the GPL definition. If you
want the GPL in Eclipse-land, fine, but it isn't.
Your second definition is overly simplistic. It includes things as
derived works that shouldn't be and doesn't include things as derived
works that should.
Just putting a class in the same package as another class, if it in no
way modifies the operation of that package except to allow you to call
package private methods and read variable values, should not make your
class a derived work. You are still just using the software as is.
OTOH, if you copy a class out of a package and modify that class so that
it requires another class you wrote, there's a good chance the class you
wrote would be considered a derivative work.
Bob Foster
CL [dnoyeb] Gilbert wrote:
> I proposed before a way to define a derivative work in Java. This was
> _any_ class you require in your classpath you are a derivative work of.
> The end result is that Eclipse could put all extendable classes in a
> certain place, and put them under no license, or a completely
> unrestricted license. These would be interfaces mostly which really
> should have no license anyway since they are not an implementation.
>
> I recently had another idea. I have created my own HashMap that fits my
> purposes. However, there was a method called HashMap.hash(Object) which
> I wanted to use but I could not. This method was package private in the
> java.util package. Turns out all I had to do to use this method was put
> my class in the java.util package as well. Then it occurred to me that
> this could be a good technique for defining a derivative work. Package
> private methods would cause your class to have to be in an org.eclipse
> package to use them. So I thought derivative work could be easy for
> developers to know. That is, if your class is in an org.eclipse package
> then its a derivative work.
>
> Seems like a nice idea, but I havent worked out how to keep people from
> putting simple clases in org.eclipse to expose the methods they want to
> use...
>
>
> CL
|
|
|
| Re: Derivative work technique [message #18888 is a reply to message #18865] |
Mon, 11 April 2005 02:28 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Bob Foster wrote:
> I admire your persistence in trying to define 'derivative work' in a way
> programmers can understand. But your definitions also need to match up
> with what lawyers understand or they aren't much use. (As before, IANAL
> but I may have some glimmering how they might see things. FWIW, which
> ain't much.)
>
Im not trying to define the term per se, but somebody needs to do it.
Its pretty weak to say if you want to know what the license means read
the FAQ and ignore the license text. No lawyer would ever do such a thing.
> Your first proposed definition is essentially the GPL definition. If you
> want the GPL in Eclipse-land, fine, but it isn't.
Not essentially, it is exactly the GPL definition. I didnt propose it,
i just said it was the only definition i could find anywhere and since
Eclipse didnt define it...However, using the definition of derivative
work, and adopting the GPL are two totally different things. The
fundamental principles of the licenses are not tied to the definition of
terms.
>
> Your second definition is overly simplistic. It includes things as
> derived works that shouldn't be and doesn't include things as derived
> works that should.
>
Yes I know. Both 'definitions' are really trying to put the power in
the software architecture to define what is and is not a derivative
work. Neither of my proposals would fit without specific division of
classes. In other words, you have one package of things which are
freely useable without restriction, and another that if you use it you
are a derivative work.
> Just putting a class in the same package as another class, if it in no
> way modifies the operation of that package except to allow you to call
> package private methods and read variable values, should not make your
> class a derived work. You are still just using the software as is.
>
You are missing my point. If I tell you that you can use any classes
from org.eclipse.public freely, then you have no confusion. Then I tell
you thatn any extension of classes in package org.eclipse.core will
cause you to be derivative, then again there is no confusion.
This is not automatic, the packages have to be designed with this in
mind. And this is not a bad software architecture design either.
tbh this is not even dependent upon the license. What I am actually
suggesting is to use the java package structure to define what is and is
not derivative. Its very clean and simple.
> OTOH, if you copy a class out of a package and modify that class so that
> it requires another class you wrote, there's a good chance the class you
> wrote would be considered a derivative work.
>
> Bob Foster
>
> CL [dnoyeb] Gilbert wrote:
>
>> I proposed before a way to define a derivative work in Java. This was
>> _any_ class you require in your classpath you are a derivative work
>> of. The end result is that Eclipse could put all extendable classes
>> in a certain place, and put them under no license, or a completely
>> unrestricted license. These would be interfaces mostly which really
>> should have no license anyway since they are not an implementation.
>>
>> I recently had another idea. I have created my own HashMap that fits
>> my purposes. However, there was a method called HashMap.hash(Object)
>> which I wanted to use but I could not. This method was package
>> private in the java.util package. Turns out all I had to do to use
>> this method was put my class in the java.util package as well. Then
>> it occurred to me that this could be a good technique for defining a
>> derivative work. Package private methods would cause your class to
>> have to be in an org.eclipse package to use them. So I thought
>> derivative work could be easy for developers to know. That is, if
>> your class is in an org.eclipse package then its a derivative work.
>>
>> Seems like a nice idea, but I havent worked out how to keep people
>> from putting simple clases in org.eclipse to expose the methods they
>> want to use...
>>
>>
>> CL
|
|
|
| Re: Derivative work technique [message #18911 is a reply to message #18888] |
Mon, 11 April 2005 06:15 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
CL [dnoyeb] Gilbert wrote:
> Bob Foster wrote:
>> Your first proposed definition is essentially the GPL definition. If
>> you want the GPL in Eclipse-land, fine, but it isn't.
>
> Not essentially, it is exactly the GPL definition. I didnt propose it,
> i just said it was the only definition i could find anywhere and since
> Eclipse didnt define it...However, using the definition of derivative
> work, and adopting the GPL are two totally different things. The
> fundamental principles of the licenses are not tied to the definition of
> terms.
Yes, they are.
> You are missing my point. If I tell you that you can use any classes
> from org.eclipse.public freely, then you have no confusion. Then I tell
> you thatn any extension of classes in package org.eclipse.core will
> cause you to be derivative, then again there is no confusion.
>
> This is not automatic, the packages have to be designed with this in
> mind. And this is not a bad software architecture design either.
>
> tbh this is not even dependent upon the license. What I am actually
> suggesting is to use the java package structure to define what is and is
> not derivative. Its very clean and simple.
Too simple "Derivative work" is a term of art. It's like "consideration"
or "abrogation". You don't get to redefine it just to make it easy for
programmers to understand.
Bob
|
|
|
| Re: Derivative work technique [message #18934 is a reply to message #18911] |
Mon, 11 April 2005 12:02 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Bob Foster wrote:
> CL [dnoyeb] Gilbert wrote:
>
>> Bob Foster wrote:
>>
>>> Your first proposed definition is essentially the GPL definition. If
>>> you want the GPL in Eclipse-land, fine, but it isn't.
>>
>>
>> Not essentially, it is exactly the GPL definition. I didnt propose
>> it, i just said it was the only definition i could find anywhere and
>> since Eclipse didnt define it...However, using the definition of
>> derivative work, and adopting the GPL are two totally different
>> things. The fundamental principles of the licenses are not tied to
>> the definition of terms.
>
>
> Yes, they are.
The GPL and the LGPL use the same terms but are two different licenses
for different purposes. Its not what terms you use but how you use them .
>
>> You are missing my point. If I tell you that you can use any classes
>> from org.eclipse.public freely, then you have no confusion. Then I
>> tell you thatn any extension of classes in package org.eclipse.core
>> will cause you to be derivative, then again there is no confusion.
>>
>> This is not automatic, the packages have to be designed with this in
>> mind. And this is not a bad software architecture design either.
>>
>> tbh this is not even dependent upon the license. What I am actually
>> suggesting is to use the java package structure to define what is and
>> is not derivative. Its very clean and simple.
>
>
> Too simple "Derivative work" is a term of art. It's like "consideration"
> or "abrogation". You don't get to redefine it just to make it easy for
> programmers to understand.
>
> Bob
Then remove the term if that is your point of contention. The LGPL has
places where they disregard the term itself because of the confused
definition. Its stated in the license in plain English this fact.
So simply state you can use and distribute any classes you create which
inherit from classes/interfaces from package org.eclipse.public, but any
you create which inherit from classes/interfaces in org.eclipse.private
become EPLed. Aggregation/composition is completely acceptable.
CL
|
|
| |
| Re: Derivative work technique [message #19000 is a reply to message #18978] |
Tue, 12 April 2005 02:47 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Mike Milinkovich wrote:
> And in lawyer-land, differences of opinion are called lawsuits :-)
Actually, they're called full employment. ;-}
Bob
|
|
|
| Re: Derivative work technique [message #19022 is a reply to message #18978] |
Tue, 12 April 2005 03:21 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Actually, I'm sorry I replied to Mike at all, even if just for a joke.
He summed it up, and that should be the end of this permathread for now.
|
|
|
| Re: Derivative work technique [message #19042 is a reply to message #18978] |
Tue, 12 April 2005 12:58 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Mike Milinkovich wrote:
>>Im not trying to define the term per se, but somebody needs to do it.
>
>
> I think that this accurately states the problem. Saying "...somebody needs
> to do it..." misses the point, which is that deciding whether or not
> something is a derivative work depends entirely on the precise scenario. It
> takes a lawyer to make these determinations with any degree of certainty.
> And in lawyer-land, differences of opinion are called lawsuits :-)
>
>
Thats one way to look at it. Use a vague term and let the best lawyers
win. However, for those of us not working for Billion dollar
corporations that notion is less than inspiring.
Eclipse can easily say, use of classes A,B,C is totally unrestricted.
Use of classes D,E,F requires the using class to be EPL. Simple. But
of course then jobs would be lost ;)
As it stands I have only the protection I can afford from my application
being declared a derivative work and forced to wear the EPL. This is
why I have total business class seperation. Because I'm broke.
In fairness I recognize that what I am proposing at this point is not a
license at all, but a license usage strategy.
CL
|
|
| |
| Re: Derivative work technique [message #19195 is a reply to message #19186] |
Sun, 24 April 2005 01:38 |
 Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Rob,
I can certainly sympathize with your frustration.
I find it difficult to understand your lawyer's logic. To me this is pretty
clear.
In the EPL, the definition of Contribution includes the statement:
"Contributions do not include additions to the Program which: (i) are
separate modules of software distributed in conjunction with the Program
under their own license agreement, and (ii) are not derivative works of the
Program." Clearly if our position was that everything you built on Eclipse
was automatically a derivative work, this definition would be superfluous.
The very essence of the definition is to allow you to create separate
modules built on Eclipse which you can distribute under your own license.
And let's not forget Section 4 "Commercial Distribution" which says amongst
other things "... this license is intended to facilitate the commercial use
of the Program ..."
The EPL FAQ (http://www.eclipse.org/legal/eplfaq.html) in questions #15, 17,
19-21 all discuss the parameters under which you can distribute code under
different licenses, including commercial ones. Again, this contradicts the
advice you're receiving from your lawyer. Why would we have these FAQs if it
was not possible to do so?
I do find it a little surprising when on one hand Eclipse has this rapidly
growing commercial ecosystem around the open source project and yet this
kind of uncertainty still lurks around. This would imply that the legal
departments of IBM, Intel, HP, SAP, QNX, Borland, Wind River, Monta Vista,
Enea, Symbian, Instantiations, Sybase, Oracle and dozens more all got it
wrong. They are all shipping commercially licensed (e.g. differently
licensed) products built on top of Eclipse. Which would clearly be
impossible if your lawyer's assertions were correct.
Obviously, we cannot help your legal advisor define the term "derivative
work" because we cannot give him or her legal advice. As I said in a
previous post, defining a derivative work is a legal question that is
fact-based and needs to be done by a lawyer. And any lawyer who worked for
the Foundation (the licensor) wouldn't be able to give you (the licensee)
advice anyways.
But I think that I am fairly safe in asserting that there are many competent
practitioners who disagree with his or her position.
"Rob Lintern" <rlintern@uvic.ca> wrote in message
news:83c10e6e5d97ee1eb6d1f5b19414d91b$1@www.eclipse.org...
> CL [dnoyeb] Gilbert wrote:
>
>> Thats one way to look at it. Use a vague term and let the best lawyers
>> win. However, for those of us not working for Billion dollar
>> corporations that notion is less than inspiring.
>
>
> Just noticed this thread...below is a repeat of what I just posted to the
> "[LICENSE] Definition of "derivative work" thread:
>
> 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
>
|
|
|
| Re: Derivative work technique [message #19261 is a reply to message #19195] |
Mon, 25 April 2005 14:19 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Mike Milinkovich wrote:
> Rob,
>
> I can certainly sympathize with your frustration.
>
> I find it difficult to understand your lawyer's logic. To me this is pretty
> clear.
I don't understand myself how he concluded that any program produced
with or basically compiled by Eclipse can possible become a derivative
work. If I understand correctly what he is claiming...
>
> In the EPL, the definition of Contribution includes the statement:
> "Contributions do not include additions to the Program which: (i) are
> separate modules of software distributed in conjunction with the Program
> under their own license agreement, and (ii) are not derivative works of the
> Program." Clearly if our position was that everything you built on Eclipse
> was automatically a derivative work, this definition would be superfluous.
> The very essence of the definition is to allow you to create separate
> modules built on Eclipse which you can distribute under your own license.
> And let's not forget Section 4 "Commercial Distribution" which says amongst
> other things "... this license is intended to facilitate the commercial use
> of the Program ..."
>
If there were an 'or' between (i) and (ii) I might be inclined to agree.
> The EPL FAQ (http://www.eclipse.org/legal/eplfaq.html) in questions #15, 17,
> 19-21 all discuss the parameters under which you can distribute code under
> different licenses, including commercial ones. Again, this contradicts the
> advice you're receiving from your lawyer. Why would we have these FAQs if it
> was not possible to do so?
>
> I do find it a little surprising when on one hand Eclipse has this rapidly
> growing commercial ecosystem around the open source project and yet this
> kind of uncertainty still lurks around. This would imply that the legal
> departments of IBM, Intel, HP, SAP, QNX, Borland, Wind River, Monta Vista,
> Enea, Symbian, Instantiations, Sybase, Oracle and dozens more all got it
> wrong. They are all shipping commercially licensed (e.g. differently
> licensed) products built on top of Eclipse. Which would clearly be
> impossible if your lawyer's assertions were correct.
>
> Obviously, we cannot help your legal advisor define the term "derivative
> work" because we cannot give him or her legal advice. As I said in a
> previous post, defining a derivative work is a legal question that is
> fact-based and needs to be done by a lawyer. And any lawyer who worked for
> the Foundation (the licensor) wouldn't be able to give you (the licensee)
> advice anyways.
>
> But I think that I am fairly safe in asserting that there are many competent
> practitioners who disagree with his or her position.
>
That don't work for large corporations? I'd be interested in hearing
how they came to their conclusion.
If you look at the GPL/LGPL, they also use the vague term, but admit it
is vague. With that in mind, the LGPL states certain situations that
exclude your program from license restrictions even if it is found to be
a derivative work. You are suggesting this extra statement in the LGPL
is unnecessary.
For me, the omission of this statement in the EPL stands out as a
glaring difference between the two licenses. I assume the EPL was
written by lawyers. Therefore, I assume the omission was intentional.
Not to be offensive, but for me this makes the FAQ disingenuous. Unless
the FAQ was written later by people who are not lawyers.
>>
>>>Thats one way to look at it. Use a vague term and let the best lawyers
>>>win. However, for those of us not working for Billion dollar
>>>corporations that notion is less than inspiring.
CL
|
|
| | | |
| Re: Derivative work technique [message #19534 is a reply to message #19352] |
Wed, 27 April 2005 17:50 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Mike Milinkovich wrote:
>>That don't work for large corporations? I'd be interested in hearing
>>how they came to their conclusion.
>
>
> Sorry, CL, but I don't think that I can do anything more to help you
> overcome your suspicions. I am quite certain that I am not playing a role in
> some vast corporate conspiracy, but I do not know what else I can say or do
> to allay your fears.
>
> /mike
>
>
I have currently seperated my programs in such a way that the ones I
consider my private work do not require any eclipse classes whatsoever
to be compiled or run. Those are used by other classes that do require
eclipse classes to compile and run. I have given up this 2nd set of
classes as potentially being derivative works. But they are just GUI
classes, and who does not seperate his business methods from his GUI
methods?
The EPL is fortunately like the LGPL in this regard and allows me this
seperation (which the GPL would not).
I am quite happy with the Eclipse platform. I only want to make others
aware of my feelings and get feedback. Maybe the message will get out
and the foundation will give us a definition. Maybe not. I'm still
having fun.
CL
|
|
|
Goto Forum:
Current Time: Fri Apr 19 18:17:02 GMT 2024
Powered by FUDForum. Page generated in 0.04451 seconds |
] 
Search
Help
Register
Login
Home
