What should be possible for some subprojects (they are not even true subprojects Right now ;-) of MP is, that things which clearly fall in the scope of new (config, the JSR leans towards Jakarta EE, there is an existing MP feature with heavy duplication of Code and effort) or existing (JAX-RS Client or MP Concurrency just to Name two) Jakarta EE specs can safely migrate from a „free form“ Project like MicroProfile to Jakarta EE without legal, IP or licensing Problems. Otherwise config alone would end in fragmentation and incompatibility forever and I doubt this is the aim of either Jakarta EE or MicroProfile? ;-/ Sent from Mail for Windows 10 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. 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'll discuss the liability question with Red Hat's lawyer, but he did not feel this was a complicated issue. 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 |
