Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epl-discuss] Concrete suggestions for changes to the EPL

I am still interested in this. I am looking at this from a technical perspective, when we attempt to apply the language of EPL to programming languages other than Java. There are two terms in particular that don't make any sense and need clarifying:

1) module - The meaning of module varies with technology. Some languages have several granularities of modularity (class, package, bundle, etc). Something like "source file" would be much clearer across technologies

2) object code - This has no meaning for dynamic/interpreted languages. The MPL language of "Source Code Form" and "Executable Form" are more technology neutral and are easier to interpret in the context of interpreted programming languages. I also like how MPL clearly defines these terms, and their FAQ gives examples on how to interpret it for _javascript_ in particular (Q16 in

I have no opinion on the other proposed changes.


From:        Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx>
To:        epl-discuss@xxxxxxxxxxx
Date:        03/18/2015 04:03 PM
Subject:        [epl-discuss] Concrete suggestions for changes to the EPL
Sent by:        epl-discuss-bounces@xxxxxxxxxxx


This email thread has been quiet for quite some time. But Janet and I would like to restart the discussions.

Changing a widely-used license such as the EPL is a big task, and we would like to focus on a narrow set of pragmatic changes. The initial list that we would propose includes:
  • Definition of Derivative Works: Relying on the term "derivative works" as defined in US law has been an issue in a number of scenarios, particularly in Europe. Changing this to a defined term would help be explicit about what we mean. We would recommend using the definition from the ALv2 license, perhaps with an explicit inclusion of sub-classing. The ALv2's approach to defining "Derivative Work" has demonstrably been well accepted by industry and the open source community.
  • Scope of Copyright License: The applicability of the EPL is restricted to code and documentation, rather than all copyrightable materials.
  • "Module": The use of the term module has been a problem for some. Many seem to prefer the more concrete term "file".
  • Choice of Law: Eclipse has very successful around the world, and particularly in Europe. We have quite a few European research projects which are involved with Eclipse technology. There are many actors in the Eclipse ecosystem who would prefer to see the EPL neutral with regards to a choice of law provision (e.g. "intellectual property laws of the United States of America"). Even in the USA, the choice of New York state law is largely seen as a vestige of IBM's original authorship of the EPL's predecessor license the Common Public License.
  • No Jury Trial: We have had this particular topic come up recently in the context of DoD and US Federal Government procurement policies. We are not aware of any other open source licenses which contain this provision.
Any thoughts or comments?

Mike Milinkovich

+1.613.220.3223 (mobile)
epl-discuss mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top