|
Scott,
A few things to keep in mind:
- The Board of Directors approved an Eclipse Foundation
Specification Process for use by Eclipse projects and working
groups that want to do specifications. If MicroProfile is
going to flatly reject using that process, then that is a
Board-level compliance discussion.
- In the event of a problem, it is the Eclipse Foundation that
would bear the liability, not Red Hat or the MicroProfile
community. We have serious concerns about the status quo that
have been raised by our counsel, IP being only one of them.
In situations where there is potential liability to our
institution, I expect that the Board will be seeking the
advice of our own attorney.
- As to the concrete suggestion "...to draft an IP policy
statement requiring royally free licensing for all essential
patents required for MP implementations...". We already have
such a policy. It's called the Eclipse Foundation IP policy.
The patent grants in that policy were drafted by Red Hat's
lawyer. The way to bind people and companies to it is via
working group participation agreements like we're doing with
Jakarta EE. And if you did have such a policy, how do you pass
those license grants along to adopters? By a spec license just
like the Eclipse Foundation Specification License. The
proposal is not simple and would require us to re-invent or
re-use a ton of stuff that is already in the EFSP and related
documents.
The thing that makes me sad about this entire discussion is
that it seems like some of the parties engaged in this process
have already decided that the EFSP is hopelessly heavyweight
before it's even been tried. I, for one, think that is a false
assumption. Is is actually an exceedingly well documented but
relatively modest overlay on the EDP. I honestly don't see why
MicroProfile could not maintain its current velocity while
complying with the EFSP.
On 2019-01-22 2:21 p.m., Scott Stark
wrote:
We (Red Hat) has been discussing this issue and we don't
see an IP issue as anything other than a low probability
event. As you say, there are several ways to address this
independent of moving over to an EFSP based process that is
appropriate for MP. One simple suggestion from our legal
counsel is to draft an IP policy statement requiring royally
free licensing for all essential patents required for MP
implementations.
Due to the MP dependencies on some of the EE4J specs, the
Jakarta Specification Process is what needs to be in a
sufficiently final form to understand if MP can be based on
that EFSP.
On
2019-01-03 7:05 a.m., Richard Monson-Haefel wrote:
MP, on the other hand, is new and
has been running as an agile process since its
beginning. Why change that? My question is: Why is it
so essential that MP adhere to the EFSP? Why is that
required? The only one that can answer that, as far as
I know, is Mike Mlinkovich who I've CCed on this email.
Indeed.
Eclipse MicroProfile has been enormously successful.
From its start in late 2016 it has quickly evolved to a
well-recognized set of industry specifications with
numerous independent commercial implementations. The
roots of this success come from its agility. Rapid
iteration of the specifications developed under a low
ceremony process has pushed MicroProfile forward at a
great pace. But there is no disputing that MicroProfile
is a specification, meant to be implemented by
others. It is not a single open source project like
Spring.
However, the very success of MicroProfile means that
legal issues become a greater concern. In particular,
the status quo could potentially expose the Eclipse
Foundation, its members, and implementers of the
MicroProfile specifications to unnecessary risk. There
are no legal problems with MicroProfile that we know of
at this time, so now is the perfect time to take steps
to mitigate the risk of such problems arising in the
future. Without getting into too much detail, the legal
risks from the current situation could arise from things
like: no formal participation or membership model, no
licensing of patents from contributors to independent
implementations, and no formal compatibility model. The
low ceremony process also increases the risk that
royalty-bearing IP could be inserted into
specifications, exposing the entire MicroProfile
ecosystem to IP litigation.
The reason why formal specification processes exist is
because there could be real legal liabilities associated
with specifications. The formality of specification
processes have evolved to mitigate those risks.
In addition, since the MicroProfile specification
process was established, the Eclipse Foundation has
created an Eclipse Foundation Specification Process. So
we now have specification projects hosted at the Eclipse
Foundation which do not conform to our specification
process. To be clear, MicroProfile is not the only group
that we are having this conversation with. For example,
the Eclipse Tahu
project is the home of the Sparkplug specification. We
are working with them to establish a working group which
will utilize the EFSP.
For the reasons above, we are stating that the
MicroProfile project has risk mitigation issues that
must be addressed. There are many potential solutions to
these issues, and we look forward to working with the
MicroProfile community to come to a solution that best
meets the needs of the community, the implementers of
the MicroProfile specifications, the MicroProfile
ecosystem, and the Eclipse Foundation.
![Avast
logo]()
|
This email has been checked for viruses by
Avast antivirus software.
www.avast.com
|
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
