Home » Eclipse Projects » Rich Client Platform (RCP) » Obligations if I copy EPL'd source code and include in commercial product
| Obligations if I copy EPL'd source code and include in commercial product [message #462614] |
Wed, 31 January 2007 00:45  |
Eclipse User |
|
|
|
Originally posted by: rncabral.oi.com.br
Hi,
I'd like to know more details about the case covered on Question 22 at
http://www.eclipse.org/legal/eplfaq.php#SRCREDIST
# What are my obligations if I copy source code obtained
from eclipse.org and licensed under the Eclipse Public
License and include it in my product that I then distribute?
The answer says that source code licensed under the EPL may only be
redistributed under the EPL.
How does that work in practice ? Say, only 2 or 3 classes on my product
are modifications of EPL classes. I only need to release the source code
for these 3 ?
Best regards,
Ricardo.
|
|
|
| Re: Obligations if I copy EPL'd source code and include in commercial product [message #462615 is a reply to message #462614] |
Wed, 31 January 2007 01:18  |
| Eclipse User |
|
|
|
Originally posted by: askme.fake.net
On Tue, 30 Jan 2007 22:45:36 -0200, Ricardo Niederberger Cabral wrote:
> Hi,
>
> I'd like to know more details about the case covered on Question 22 at
> http://www.eclipse.org/legal/eplfaq.php#SRCREDIST
>
> # What are my obligations if I copy source code obtained from eclipse.org
> and licensed under the Eclipse Public License and include it in my
> product that I then distribute?
>
> The answer says that source code licensed under the EPL may only be
> redistributed under the EPL.
>
> How does that work in practice ? Say, only 2 or 3 classes on my product
> are modifications of EPL classes. I only need to release the source code
> for these 3 ?
>
> Best regards,
> Ricardo.
Best to ask such a question on eclipse.foundation
I would say that nobody can answer that question fully though.
For sure those classes must be under EPL now. But as for the rest of
them, who knows really. Not much difference between a jar of classes and
a class itself. What constitutes a 'work'. The EPL leaves this
definition generally up to the courts and outside of the realm of software.
Personally, I would not mix any EPL classes with other classes of my
program. I have done this in one of my plugins, and I consider that
plugin to be borderline requiring EPL. Basically I am not sure about it
and to preserve the integrity of my main code, I keep that stuff seperate.
dnoyeb
|
|
|
| Re: Obligations if I copy EPL'd source code and include in commercial product [message #462633 is a reply to message #462614] |
Wed, 31 January 2007 09:05 |
 Alex Blewitt
Messages: 946
Registered: July 2009 |
Senior Member |
|
|
Firstly, don't trust any answer that you get here (or on the foundation newsgroup) for an answer you can rely on in court :-) You'd need to consult a lawyer for a true answer.
However, I personally believe that you shouldn't mix EPL and non-EPL code in the same plugin. It's fine if you want to bugfix some EPL code or tweak some core plugins, but you then end up redistributing the modified plugin as a whole (with source available, if necessary).
Your non-EPL plugin can then depend on that plugin without needing to be EPL. After all, that's the basic premise that allows commercial tools to be built on top of Eclipse.
Mixing EPL and non-EPL code in the same plugin is a lot trickier. I'd avoid it.
As for the modified source; I'd say that you should make the source of your entire EPL code, rather than just the changes, though from a licensing perspective you may be OK with just the changed source files. If nothing else, it's easier to regenerate the source for all the plugin code which makes sure you've covered your obligation rather than forgetting to include some of it.
But, like I said, IANAL and don't trust any answer that you get :-)
Alex.
|
|
| |
| Re: Obligations if I copy EPL'd source code and include in commercial product [message #462673 is a reply to message #462633] |
Wed, 31 January 2007 12:57 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
On Wed, 31 Jan 2007 04:05:17 -0500, Alex Blewitt wrote:
> Mixing EPL and non-EPL code in the same plugin is a lot trickier. I'd
> avoid it.
>
When you say this, you mean copy-pasted code? What about importing an EPL
class, and calling one of its methods? What about instantiating an EPL
class? Where is this line drawn?
That is why I requested several years back, and even submitted a bug
report that has been open for a few years...
What I requested was that eclipse should expose its interfaces in a
package that is covered by the BSD. So importing and using and calling on
interfaces which are BSD sets a clear boundary. But to no avail. And
ultimately, that technique will just help out with source code mixing, it
does not cover the fact that plugins use extension points exposed by
eclipse and other simplar mixes.
|
|
|
| Re: Obligations if I copy EPL'd source code and include in commercial product [message #462768 is a reply to message #462673] |
Wed, 31 January 2007 23:05 |
Alex Blewitt
Messages: 946
Registered: July 2009 |
Senior Member |
|
|
> > Mixing EPL and non-EPL code in the same plugin is a lot trickier. I'd
> > avoid it.
>
> When you say this, you mean copy-pasted code? What about importing an EPL
> class, and calling one of its methods? What about instantiating an EPL
> class? Where is this line drawn?
Like I said, I would avoid mixing EPL and non-EPL in the same plugin. If it's all in one bundle, I'd put the lot under EPL. If a bundle used another bundle at runtime, I wouldn't be so bothered. The GPL has lots of terms like 'link' which don't really make sense in this situation, but the EPL does talk about 'derived work'. I'd say that the plugin that contains modified code is a 'derived work' but a bundle that uses that is not a 'derived work'. But, like I said, IANAL and I wouldn't trust any answer I read on a newsgroup, especially not from someone who tells you not to trust any answer you read on a newsgroup.
Alex.
|
|
|
| Re: Obligations if I copy EPL'd source code and include in commercial product [message #462830 is a reply to message #462768] |
Thu, 01 February 2007 12:22 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
On Wed, 31 Jan 2007 18:05:00 -0500, Alex Blewitt wrote:
>> > Mixing EPL and non-EPL code in the same plugin is a lot trickier. I'd
>> > avoid it.
>>
>> When you say this, you mean copy-pasted code? What about importing an
>> EPL class, and calling one of its methods? What about instantiating an
>> EPL class? Where is this line drawn?
>
> Like I said, I would avoid mixing EPL and non-EPL in the same plugin. If
> it's all in one bundle, I'd put the lot under EPL. If a bundle used
> another bundle at runtime, I wouldn't be so bothered. The GPL has lots of
> terms like 'link' which don't really make sense in this situation, but the
> EPL does talk about 'derived work'. I'd say that the plugin that contains
> modified code is a 'derived work' but a bundle that uses that is not a
> 'derived work'. But, like I said, IANAL and I wouldn't trust any answer I
> read on a newsgroup, especially not from someone who tells you not to
> trust any answer you read on a newsgroup.
>
If you use Eclipse you can not avoid that. There is no way to implement
an IEditor without importing the interface IEditor, etc. The GPL is clear
that they would not allow any type of linking at all. The EPL has become
more clear that they do support anything that is not a derived work, and
leaves the court to interpret that term. You cant simply say a bundle
that uses it is not derived unless you are the courts. Other licenses use
terms indicating that your work must add substantial functionality. I am
beginning to accept the EPL strategy of leaving it to the court. However,
I still feel that if the interfaces were BSD, there would be NO issue.
> Alex.
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 20:28:44 GMT 2024
Powered by FUDForum. Page generated in 0.03293 seconds |
] 
Search
Help
Register
Login
Home
