Bugzilla – Full Text Bug Listing
| Summary: | [license] Dual License Request for OpenJ9 (EPL-2.0 OR Apache-2.0) | ||
|---|---|---|---|
| Product: | Community | Reporter: | Stephanie Swart <stephanie.swart> |
| Component: | Proposals and Reviews | Assignee: | Eclipse Management Organization <emo> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | heidinga, jonathanw, mike.milinkovich, mstoodle, Paul.White, Peter_Shipton, sharon.corbett, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| URL: | https://projects.eclipse.org/proposals/eclipse-openj9 | ||
| Whiteboard: | |||
| Bug Depends on: | 519789 | ||
| Bug Blocks: | 519049 | ||
|
Description
Stephanie Swart
Note that, in anticipation of receiving approval to go live with the EPL-2.0, I've added it to our license list and have updated the project proposal. We are still waiting for a slide deck with the following: in the slide please provide a paragraph with an executive summary of the project; and a second paragraph describing why the project needs to be licensed in this manner. You can attach the slide deck on this bug. Please avoid providing technical detail; a two or three sentence executive summary will suffice for each of these paragraphs. Sorry for the delay; we had lost sight of this one. We're working on the requested 2 paragraphs, and will update this bug with the text tomorrow (Aug 10). Here's what we came up with: The OpenJ9 project provides an open source and openly governed implementation of a Java Virtual Machine (JVM), analogous to but completely independently developed from the HotSpot JVM maintained by the OpenJDK project. OpenJ9 is built using the language agnostic technology components (garbage collectors, Just In Time compiler, etc) from the existing Eclipse OMR project, which is dual licensed as EPLv1 / AL2. Eclipse OMR and OpenJ9 were once a single code base that has been extensively refactored into these two pieces, but that refactoring is not yet complete. Despite this incomplete refactoring, OpenJ9 is fully functional as a JVM and Eclipse OMR has already proven that it can be reused without taking on any Java semantics in other language runtimes. We don't want to delay open sourcing OpenJ9 just because we still need to move some code around. Because we (the two communities overlap) need to be able to move code from Eclipse OMR to OpenJ9 and vice versa, the projects should have the same license. With different licenses, external contributions become troublesome. Eclipse OMR has had some external contributions and we want to strongly encourage external contribution at OpenJ9. We want to be able to accept any external contribution to either project, even those affecting code locations that require more refactoring and even if we aren't aware at the time that refactoring in that spot would be beneficial. It would be a shame to make external contributions a source of pain for these two projects. If that text is not appropriate or misses on any key ingredients, please let us know! Mark, this should suffice for purposes of submitting the request to the Board. Many thanks for the quick turnaround. On August 16, 2017 this was approved by the board. |