| Re: [jakarta.ee-spec.committee] Interaction Between Code-First and Specifications |
On 2018-06-06 12:00 PM, Daniel Bandera wrote:
Unfortunately, I don't think it is that simple (i.e., ...ensure the required IP flow at contribution time). While it is normal on Eclipse and Apache open source projects to provide patent grants to patents embodied in the code held by the contributor of that code at the time of contribution, open standards typically provide patent grants from all involved parties at the time the specification is approved and published. This is because the patent holder(s) involved usually only want to make grants to patent claims that are essential to the implementation of the specification. Code that is contributed prior to the finalization and approval of the specification (possibly prototyping ideas to incorporate into the specification) may express ideas (patents) that never make it into the final specification and thereby are not essential to implement the specification.
I have arranged for IBM's representative to the OASIS Board - Dave Ings - to present to our Jakarta EE Specifications Committee this Friday 6/08 on how OASIS is addressing this and other issues when taking a "Code-First" approach. Dave drove those changes at OASIS in an effort that started almost two years ago (with lots of lawyers) and are now nearly complete. I think we can get some insights on how we can adapt those ideas for the Eclipse Specification process. I am hopeful...
FWIW, our approach to capturing IP at the time of open source contribution is limited to copyrights only. The goal is ensure that the copyrights of the APIs and documentation can be used as the basis for the spec.
Patent rights would be provided by all companies involved in the specification project itself once that is started.
Maybe OASIS has invented the IP anti-gravity device that we've all been waiting for. But absent that, I don't see how you can take patent rights granted to an open source implementation and carry them forward to apply to all downstream clean room implementations of a spec. To repeat: that is not what we have even been trying to accomplish.
This leaves a gap in IP perfection. A patent-holding contributor to an open source project that was not later involved in the specification may have grounds for a claim of infringement. Two ways to mitigate that are:
- Avoid projects which have been contributed to by known patent trolls, or at least by companies known to be competitive to the aims of the specification in question.
- If the project is an Eclipse project, our IP Policy provides a Member company who feels that a release infringes their IP to complain at that time. Definitely not perfect, but helpful.
I look forward to hearing if OASIS has arrived at a superior solution.
Best regards,
Dan
Dan Bandera
(512) 286-5228
Program Director, FaaS, IoT, and Java
IBM Open Technologies, Austin, Texas
The OSGi Alliance ( osgi.org ) President and Board of Directors
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: Jakarta specification committee <jakarta.ee-spec.committee@eclipse.org>
Date: 2018-06-06 04:56 AM
Subject: Re: [jakarta.ee-spec.committee] Interaction Between Code-First and Specifications
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
IANAL (especially not a USA software patent lawyer).
However my perhaps simplistic solution is to modify the standard Eclipse Contributor Agreement and membership agreements to ensure the required IP flow at contribution time. That would at least enable a code first approach within the EF with later standardisation.
Steve