|
On 2019-01-22 10:52 p.m., Scott Stark
wrote:
It is not even necessarily about the heaviness of
the EFSP. During today's MP hangout we were discussing the
ability of individual MP technologies to come up with new
versions that do not maintain backwards compatibility. We also
discussed there being little point to having such flexibility in
the Jakarta EE specs process.
There is nothing in the EFSP that I am
aware of that says anything about backwards compatibility.
So, perhaps MP technologies are not EFSP compatible
projects and will need to be called something else. As of now,
there is no experience with any EFSP, too many moving parts in
the Jakarta EE spec process, and just not enough inclination to
move MP away from its current process.
I have been very careful to *not* say that MicroProfile needs to
adopt the Jakarta EE process. That is a topic for discussion, not
an assumption.
I completely agree that it makes no sense for MP to join the
Jakarta EE process at this time, because the Jakarta EE process
has not yet been finalized.
I am also not saying that anything needs to happen immediately.
We simply want to conversation to start. Change takes time, but it
never happens if you don't start discussing it.
I'll discuss the liability question with Red Hat's
lawyer, but he did not feel this was a complicated issue.
Please do.
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
_______________________________________________
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
|
