Eclipse Contributor Agreement 3.0

The Eclipse Contributor Agreement (ECA) is an agreement made by contributors certifying the work they are contributing was authored by them and/or they have the legal authority to contribute as open source under the terms of the project license.

The Eclipse Foundation’s IP Team has been working hard to get the various agreements that we maintain between the Eclipse Foundation and community updated. Our first milestone targeted the ECA, and we’re happy to report that a very significant number of our community members have successfully updated theirs. Today, we retired all of the rest of them. Specifically, we’ve revoked all ECAs that predate the ECA version 3.0.

We’re confident that we’ve managed to connect and update the ECA for everybody who still wants to be a contributor, so there should be no interruption for anybody who is actively contributing. If we missed you, you’ll be asked to sign the new ECA the next time you try to contribute. Or you can just re-sign it now.

We’ve made some changes with the new agreements that make contributing easier, (but explaining harder). Committers who have signed the Individual Committer Agreement (ICA) version 4.0 or work for a company that has signed the Member Committer and Contributor Agreement do not require an ECA.

Contact if you’re having trouble with an agreement.

Posted in Uncategorized | Leave a comment

Specification Scope in Jakarta EE

With the Eclipse Foundation Specification Process (EFSP) a single open source specification project has a dedicated project team of committers to create and maintain one or more specifications. The cycle of creation and maintenance extends across multiple versions of the specification, and so while individual members may come and go, the team remains and it is that team that is responsible for the every version of that specification that is created.

The first step in managing how intellectual property rights flow through a specification is to define the range of the work encompassed by the specification. Per the Eclipse Intellectual Property Policy, this range of work (referred to as the scope) needs to be well-defined and captured. Once defined, the scope is effectively locked down (changes to the scope are possible but rare, and must be carefully managed; the scope of a specification can be tweaked and changed, but doing so requires approval from the Jakarta EE Working Group’s Specification Committee).

Regarding scope, the EFSP states:

Among other things, the Scope of a Specification Project is intended to inform companies and individuals so they can determine whether or not to contribute to the Specification. Since a change in Scope may change the nature of the contribution to the project, a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee.

As a general rule, a scope statement should not be too precise. Rather, it should describe the intention of the specification in broad terms. Think of the scope statement as an executive summary or “elevator pitch”.

Elevator pitch: You have fifteen seconds before the elevator doors open on your floor; tell me about the problem your specification addresses.

The scope statement must answer the question: what does an implementation of this specification do? The scope statement must be aspirational rather than attempt to capture any particular state at any particular point-in-time. A scope statement must not focus on the work planned for any particular version of the specification, but rather, define the problem space that the specification is intended to address.

For example:

Jakarta Batch provides describes a means for executing and managing batch processes in Jakarta EE applications.


Jakarta Message Service describes a means for Jakarta EE applications to create, send, and receive messages via loosely coupled, reliable asynchronous communication services.

For the scope statement, you can assume that the reader has a rudimentary understanding of the field. It’s reasonable, for example, to expect the reader to understand what “batch processing” means.

I should note that the two examples presented above are just examples of form. I’m pretty sure that they make sense, but defer to the project teams to work with their communities to sort out the final form.

The scope is “sticky” for the entire lifetime of the specification: it spans versions. The plan for any particular development cycle must describe work that is in scope; and at the checkpoint (progress and release) reviews, the project team must be prepared to demonstrate that the behavior described by the specifications (and tested by the corresponding TCK) cleanly falls within the scope (note that the development life cycle of specification project is described in Eclipse Foundation Specification Process Step-by-Step).

In addition the specification scope which is required by the Eclipse Intellectual Property Policy and EFSP, the specification project that owns and maintains the specification needs a project scope. The project scope is, I think, pretty straightforward: a particular specification project defines and maintains a specification.

For example:

The Jakarta Batch project defines and maintains the Jakarta Batch specification and related artifacts.

Like the specification scope, the project scope should be aspirational. In this regard, the specification project is responsible for the particular specification in perpetuity. Further the related artifacts, like APIs and TCKs can be in scope without actually being managed by the project right now.

Today, for example, most of the TCKs for the Jakarta EE specifications are rolled into the Jakarta EE TCK project. But, over time, this single monster TCK may be broken up and individual TCKs moved to corresponding specification projects. Or not. The point is that regardless of where the technical artifacts are currently maintained, they may one day be part of the specification project, so they are in scope.

I should back up a bit and say that our intention right now is to turn the “Eclipse Project for …” projects that we have managing artifacts related to various specifications into actual specification projects. As part of this effort, we’ll add Git repositories to these projects to provide a home for the specification documents (more on this later). A handful of these proto-specification projects currently include artifacts related to multiple specifications, so we’ll have to sort out what we’re going to do about those project scope statements.

We might consider, for example, changing the project scope of the Jakarta EE Stable APIs (note that I’m guessing a future new project name) to something simple like:

Jakarta EE Stable APIs provides a home for stable (legacy) Jakarta EE specifications and related artifacts which are no longer actively developed.

But, all that talk about specification projects aside, our initial focus needs to be on describing the scope of the specifications themselves. With that in mind, the EE4J PMC has created a project board with issues to track this work and we’re going to ask the project teams to start working with their communities to put these scope statements together. If you have thoughts regarding the scope statements for a particular specification, please weigh in.

Note that we’re in a bit of a weird state right now. As we engage in a parallel effort to rename the specifications (and corresponding specification projects), it’s not entirely clear what we should call things. You’ll notice that the issues that have been created all use the names that we guess we’re going to end up using (there’s more more information about that in Renaming Java EE Specifications for Jakarta EE).

Posted in EDP, EFSP, Jakarta EE, Java, Uncategorized | Leave a comment

Renaming Java EE Specifications for Jakarta EE

It’s time to change the specification names…

When we first moved the APIs and TCKs for the Java EE specifications over to the Eclipse Foundation under the Jakarta EE banner, we kept the existing names for the specifications in place, and adopted placeholder names for the open source projects that hold their artifacts. As we prepare to engage in actual specification work (involving an actual specification document), it’s time to start thinking about changing the names of the specifications and the projects that contain their artifacts.

Why change? For starters, it’s just good form to leverage the Jakarta brand. But, more critically, many of the existing specification names use trademarked terms that make it either very challenging or impossible to use those names without violating trademark rules. Motivation for changing the names of the existing open source projects that we’ll turn into specification projects is, I think, a little easier: “Eclipse Project for …” is a terrible name. So, while the current names for our proto-specification projects have served us well to-date, it’s time to change them. To keep things simple, we recommend that we just use the name of the specification as the project name. 

With this in mind, we’ve come up with a naming pattern that we believe can serve as a good starting point for discussion. To start with, in order to keep things as simple as possible, we’ll have the project use the same name as the specification (unless there is a compelling reason to do otherwise).

The naming rules are relatively simple:

  • Replace “Java” with “Jakarta” (e.g. “Java Message Service” becomes “Jakarta Message Service”);
  • Add a space in cases where names are mashed together (e.g. “JavaMail” becomes “Jakarta Mail”);
  • Add “Jakarta” when it is missing (e.g. “Expression Language” becomes “Jakarta Expression Language”); and
  • Rework names to consistently start with “Jakarta” (“Enterprise JavaBeans” becomes “Jakarta Enterprise Beans”).

This presents us with an opportunity to add even more consistency to the various specification names. Some, for example, are more wordy or descriptive than others; some include the term “API” in the name, and others don’t; etc.

We’ll have to sort out what we’re going to do with the Eclipse Project for Stable Jakarta EE Specifications, which provides a home for a small handful of specifications which are not expected to change. I’ll personally be happy if we can at least drop the “Eclipse Project for” from the name (“Jakarta EE Stable”?). We’ll also have to sort out what we’re going to do about the Eclipse Mojarra and Eclipse Metro projects which hold the APIs for some specifications; we may end up having to create new specification projects as homes for development of the corresponding specification documents (regardless of how this ends up manifesting as a specification project, we’re still going to need specification names).

Based on all of the above, here is my suggested starting point for specification (and most project) names (I’ve applied the rules described above; and have suggested tweaks for consistency by strike out):

  • Jakarta APIs for XML Messaging
  • Jakarta Architecture for XML Binding
  • Jakarta API for XML-based Web Services
  • Jakarta Common Annotations
  • Jakarta Enterprise Beans
  • Jakarta Persistence API
  • Jakarta Contexts and Dependency Injection
  • Jakarta EE Platform
  • Jakarta API for JSON Binding
  • Jakarta Servlet
  • Jakarta API for RESTful Web Services
  • Jakarta Server Faces
  • Jakarta API for JSON Processing
  • Jakarta EE Security API
  • Jakarta Bean Validation
  • Jakarta Mail
  • Jakarta Beans Activation Framework
  • Jakarta Debugging Support for Other Languages
  • Jakarta Server Pages Standard Tag Library
  • Jakarta EE Platform Management
  • Jakarta EE Platform Application Deployment
  • Jakarta API for XML Registries
  • Jakarta API for XML-based RPC
  • Jakarta Enterprise Web Services
  • Jakarta Authorization Contract for Containers
  • Jakarta Web Services Metadata
  • Jakarta Authentication Service Provider Interface for Containers
  • Jakarta Concurrency Utlities
  • Jakarta Server Pages
  • Jakarta Connector Architecture
  • Jakarta Dependency Injection
  • Jakarta Expression Language
  • Jakarta Message Service
  • Jakarta Batch
  • Jakarta API for WebSocket
  • Jakarta Transaction API

We’re going to couple renaming with an effort to capture proper scope statements (I’ll cover this in my next post). The Eclipse EE4J PMC Lead, Ivar Grimstad, has blogged about this recently and has created a project board to track the specification and project renaming activity (as of this writing, it has only just been started, so watch that space). We’ll start reaching out to the “Eclipse Project for …”  teams shortly to start engaging this process. When we’ve collected all of the information (names and scopes), we’ll engage in a restructuring review per the Eclipse Development Process (EDP) and make it all happen (more on this later).

Your input is requested. I’ll monitor comments on this post, but it would be better to collect your thoughts in the issues listed on the project board (after we’ve taken the step to create them, of course), on the related issue, or on the EE4J PMC’s mailing list.


Posted in EDP, EFSP, Jakarta EE, Java, Uncategorized | Tagged , , | 4 Comments

Progress and Release Reviews

The Eclipse Development Process (EDP) requires that a project team engage in a successful progress or release review before creating a formal release. We use progress and release reviews as an opportunity to validate that a project team is following the open source rules of engagement, and are consistently implementing the EDP and the Eclipse Intellectual Property (IP) Policy.  

Progress and release reviews are fundamentally the same, differing only in timing and intent. A progress review can occur at any time in the development cycle, and there is no immediate expectation that the project team will make a release. In contrast, a release review generally occurs at the end of a release cycle and it is generally expected that a release occurs shortly after the successful completion of the review (though the EDP makes no timing requirements other than that a release review complete successfully before the release). 

Screenshot from 2019-03-18 15-45-37.png

Following a successful progress or release review, a project team may engage in any number of releases for an entire year (though, the project leadership may compel a project team to engage in extra reviews should they be deemed necessary). While a formal review is not required for every release, project teams must ensure that all related due diligence is completed before IP is included in a release. Project teams are required to implement the IP Policy at all times.

The basic framework is the same, but the requirements are a little different for open source projects engaged in specification development (what the Eclipse Foundation Specification Process (EFSP) refers to as “Specification Projects”). These projects must engage in at least one successful progress review midway through their development cycle, and a successful release review prior to every official release. For specification projects, reviews come with extra requirements to validate that that specification process is being consistently implemented, and that the work being done by the project is in scope.

To start a review, a project team assembles review materials and delivers them to their Project Management Committee (PMC) for approval. In parallel, the project team also submits their log of intellectual property contributions to the Eclipse IP Team for their approval. One those approvals have been obtained, the Eclipse Management Organization (EMO) schedules the review and invites the community at large to weigh in.

The EDP requires that review materials be made available to the community for feedback for a minimum of one week. Theoretically, it is during this time that a community member might voice concerns. An Eclipse Foundation member company might, for example, object to a release that they believe infringes on their intellectual property. I say “theoretically”, because this rarely happens… reviews tend to conclude successfully.

Reviews tend to conclude successfully in large part because all of the work is done in accordance with the open source rules of engagement. Frankly, one week is far too short a period of time for a community member, adopter, or other interested party to engage in any sort of comprehensive review. It is helpful to think of progress and release reviews as the end of a review cycle that begins at the start of the development cycle. Since all open source work must be done in an open and transparent manner, anybody may observe the activity of the project team, and join in the conversation at any time. An interested individual or organization can literally engage with the project as long in advance of a review and/or release as they’d like.

In short, if you’re just starting to dig into an open source project during a review, you’ve waited too long.

The release process is described in detail in the Eclipse Project Handbook.

Posted in EDP, EFSP, Uncategorized | Leave a comment

Incubation in the Eclipse Development Process

The Eclipse Development Process has a notion of phases. Two of those phases are Incubation and Mature.

While in both of these phases, an Eclipse open source project operates in basically the same manner: only committers can push content, committers are brought on board by election, committers accept contributions, and projects in the incubation phase can issue major, minor, and service releases. In fact, we strongly encourage all new project teams to engage in at least one release while in the incubation phase as part of learning our process. Traditionally, a project in the incubation phase numbers their releases < 1.0 (e.g. “0.7”), but there is no requirement to do so.

Incubation is a phase, or state, for a project. That a project is in the incubation phase (we oftentimes refer to a project in this phase as “incubating”) is a flag for adopters and the community at large that the project team is still learning the various processes that Eclipse project teams follow, or that the content produced is either unstable or volatile (e.g. APIs are likely to change while a project is in incubation). Note my use of the word “or” in the previous sentence: a project with a stable code base that has just moved to the Eclipse Foundation (with committers who are new to our process) starts in incubation.

To highlight that a project is in the incubation phase, it must implement incubation branding. Primarily, this takes the form of displaying the incubation logo in prominent locations, including the project’s major web properties and including the word “incubation” or warning that products shipped as part of a release “may include incubating components”.

For those readers who are already familiar with our incubating branding, you’ll hopefully be delighted to learn that we’ve selected a logo to replace the venerable old “incubation egg” and will be rolling it out soon (while these sorts of things tend to be a team effort, we give credit to @stephaniejswart for bringing this new logo to life).


The IP process provides some additional flexibility for projects in incubation; the implication being that there may be some modest increase in intellectual property-related risk (especially when combined with a new development team who don’t yet live and breath the Eclipse IP Policy).

To leave incubation, a project team must engage in a graduation review (graduation reviews are typically combined with a progress or release review). During that review, the project team must demonstrate that:

  • The project team understands and implements the EDP and  and related processes, and understands their obligations under the Eclipse IP Policy;
  • The APIs are stable; and
  • The content produced is of “Eclipse Quality”

In practice, this takes the form of a few extra sentences in the documentation associated with the review (after, of course, actually learning the ropes and stabilizing the content quality).

Posted in EDP | Leave a comment

Eclipse Foundation Specification Process Step-by-Step

Scientific progress goes “boink”? – Hobbes

The Eclipse Foundation Specification Process (EFSP) provides a framework and governance model for developers engaged in the process of developing specifications.

Specification: A specification is a collection of related artifacts.

EFSP Step-by-step1.png

The EFSP defines a specification as a “collection of Application Programming Interface (API) definitions, descriptions of semantic behavior, data formats, protocols, and/or other referenced specifications, along with its TCK, intended to enable the development and testing of independent Compatible Implementations.” A specification project is, then, an Eclipse open source project concerned with the creation and maintenance of one or more specifications.

As a matter of practice, we tend to have a one-to-one mapping between specification projects and specifications. But there are examples of specification projects that play host to multiple specifications. The Eclipse Project for Stable Jakarta EE APIs, for example, is the host project for a handful of specifications that are considered stable and in long term maintenance (and not expected to continue to evolve).

Specification Project: A specification project is the composition of a team of committers dedicated to the creation and maintenance of one or more specifications, along with the resources required to create those specifications.

EFSP Step-by-step.png

Resources assigned to a specification project include one or more software repositories that serve as the collaboration point for the development of specification documents and corresponding technical artifacts. A specification project has other resources assigned to it, including space on a download server, build resources, and mailing lists.

A specification project may also be responsible for other related functionality, including TCKs. It’s considered a best practice to keep implementations of a specification separate from the specification itself, but there is no rule that prevents this sort of coupling.

A specification project has one or more project leads who are typically also committers. Project leads have no special powers or authority with regard to development and delivery of specifications. Rather, they are the primary liaison between the project team and the Eclipse Foundation, and form the first link in the leadership chain which includes the Project Management Committee (PMC) and Eclipse Management Organization (EMO). Primarily, project leads are responsible for ensuring that the project team (i.e. the committers) are following the rules.

Specification Versions: A specification project produces versions of a specification, which the EFSP refers to as specification versions. Once ratified, a specification version becomes a final specification.

EFSP Step-by-step (1).png

The differences between a specification version and a final specification are subtle. A specification version is the output from the open source project. While a final build of a specification version can be said to be complete, it cannot be used as the basis for an implementation. The intellectual property rights that are required to implement a specification flow through the final specification (a bit more on this later).

No specific packaging or means of distribution are prescribed by the EFSP, but one can think of a final specification as a complete package that combines a read-only version of the specification document, technical artifacts (e.g. APIs), a TCK, and one or more compatible implementations. Again, the EFSP makes no specific requirements regarding how everything is packaged, so, for example, the TCK and compatible implementations may manifest as pointers.

The Specification Project Persists: A specification project is formed around the idea of producing and maintaining a specification in the general sense. The same specification project will produce multiple versions of a specification. After the final and complete version of a specification is released, the project team will begin the development cycle for the next release.

EFSP Step-by-step (2).png

Members of the team (i.e. the committers and project Leads) may come and go, but the team remains.

A specification project has a well-defined scope that defines the boundaries of their activity. All versions of specifications produced by the project must fall within the scope.

The EFSP does not prescribe how resources associated with specification projects are structured, beyond a requirement that the specification project must be the home for the specification document. For technologies like Java® that have technical artifacts (e.g. interfaces) it is convenient, but not necessary to have the source for those technical artifacts maintained as part of the project.

Strictly speaking, a specification project can also be the home for a TCK and compatible implementation. As mentioned earlier, it is considered a best practice to keep compatible implementations separate (it may even be considered a bad practice to couple an implementation with the specification).

The Project Management Committee: Top-level projects are managed by a Project Management Committee (PMC). A PMC has one or more PMC leads and zero or more PMC members. Together the PMC provides oversight and overall leadership for the projects that fall under their top-level project.

EFSP Step-by-step (3).png

Under the Eclipse Development Process (EDP) open source projects are organized hierarchically. A special type of project, top-level Projects, sit at the top of the hierarchy. Every top-level project contains one or more projects (which are sometime referred to as “subprojects”). As a general rule, top-level projects are primarily an organizational construct, and all real work occurs in subprojects.

Every top-level project has a PMC that supervises the projects under their purview to ensure that they are all working under the rules defined by the EDP, EFSP, and the Eclipse Foundation’s Intellectual Property Policy.

The Specification Committee: A committee of a working group established to manage the EFSP for technologies within the scope of its working group.

EFSP Step-by-step.png

Open source projects are the means by which developers collaborate at the Eclipse Foundation. working groups are a means for companies to work together. The Jakarta EE Working Group, for example, brings companies together to collaborate on marketing, ecosystem development, governance, and (of course) open source software and specification development. As part of their governance activities, a working group must establish a specification committee to define and manage a specification process on behalf of the working group.

The specification committee is responsible for ensuring that that the specification teams keep within their defined scope, and generally ensure that the specification versions created by the specification project are implementable and serve the purposes of the working group.

Overview of the Process: the EFSP extends the EDP by adding a few extra checks and balances.

EFSP Step-by-step (5).png

Each iteration through the development cycle starts with a plan. For the first iteration, the project proposal serves as the plan and the creation review as the approval.

Specification Project Proposal: Specification projects start with a proposal.

EFSP Step-by-step (7).png

A project proposal describes the specification project that will be created. Proposals set out the scope and provide a description of the project and the specifications that the project will produce.

The Eclipse Foundation has a web form for defining project proposals. While a proposal is being drafted, the author and anybody designated as a project lead is able to edit the document. Everybody listed as an initial member of the specification team (i.e. committers) are able to view the document. The proposal becomes publicly accessible after it is opened for community review.

According to the EDP, the proposal must be open for community review for a minimum of two weeks to provide the community and key stakeholders to provide feedback and improve the proposal. The proposal can be modified during the community review period.

While open for community review, the EMO will investigate and approve trademarks associated with the project, which Eclipse Foundation holds on behalf of the project team and community. During this period the EMO will also work to get approval of other exceptions. This includes specification project licensing schemes that fall outside of the pre-approved licensing schemes for the top-level project.

When everything is in place (trademarks, licensing approval when required, identification of a mentor, and the minimum two week community review), the EMO will schedule a creation review.

Creation reviews run for a minimum of one week. The EMO schedules two review periods each month. Reviews are grouped together; they are scheduled according to their end dates which occur on the first and third Wednesdays of every month.

The proposal is locked down during the creation review period and no changes are possible. The creation review period is the last opportunity for the community and stakeholders to provide feedback. The specification committee and the membership-at-large of the Eclipse Foundation can intervene with the creation process. The membership can, should they find cause, request that the EMO fail a creation review and require that the proposal author either make additional changes and restart the review process, or withdraw the proposal completely (for what it’s worth, this has never happened).

Upon successful completion of the creation review, the Eclipse Foundation will engage in a provisioning process to turn the proposal into a live specification project. Provisioning starts with the authorization of committers which is initiated via email requests to all committers listed on the proposal to engage in our paperwork process. The provisioning process is kept on hold until the Eclipse Foundation’s records team has the necessary paperwork from at least one committer.

The proposal document serves as the plan for the first development iteration. Subsequent iterations through the process rely on the creation of a release plan and plan review.

Release Planning: The project team assembles the plan for each release cycle.

EFSP Step-by-step (8).png

Again, note that the proposal and creation review serve as the plan and plan review for the first release.

The plan must be in-scope (i.e. all new work must fall within the bounds defined by the specification project’s scope) and must be developed in consideration of the concerns of stakeholders. It must, for example, take into consideration overarching plans of the PMC or associated working group. It’s worth noting that the concerns of the project team must also be taken into consideration when creating an overarching plan. We’re all in this together.

The plan is delivered to the specification committee via a plan review. The specification committee must vote to approve: a two-thirds majority of positive votes are required to succeed. How the individual members of the specification committee decide to vote varies; but at a minimum, by voting yes, members affirm that they believe that the planned work fits within the project’s scope and that sufficient consultation with the community and stakeholders has occurred.

All reviews, including plan reviews, run for a minimum of one week. They start with the delivery of review materials, and end with the conclusion of the voting period. For a plan review, materials include the plan itself along with a concise description (executive summary) of the plan. For progress and release reviews (which will be discussed shortly), the review materials include a milestone or release candidate build of the project content.

All reviews are run in the open. In addition to the approvals that are required, reviews offer an opportunity for the community and adopters to make their concerns known. As the entire process is run in the open, reviews should be considered as a final opportunity to express concern: parties who have a stake or interest in a specification process should engage early and often via project-specific open channels.

In the event that a review fails, the project team must regroup, incorporate feedback, and re-engage in a new review. The EFSP makes no requirement regarding the timing of re-engagement.

Committers Develop Specifications: Committers have the power and responsibility to push content into the specification project’s Git repositories. Committers hold most of the power and responsibility in the process.

EFSP Step-by-step (9).png

Committer power must be used wisely. Committers have awesome power, but they also have awesome responsibility and are expected to work to the benefit of the community and ecosystem.

Committers Accept Contributions: Committers accept contributions from non-committers. In the GitHub world, this takes the form of committers reviewing and accepting pull requests.

EFSP Step-by-step (10).png

Committers are responsible to ensure that the accepted content is within scope and release plan, and that the Eclipse Foundation’s Intellectual Property Policy is observed and the IP Due Diligence Process is followed.

Contributors must sign the Eclipse Contributor Agreement (ECA).

Technology Compatibility Kit (TCK): While the specification project committers are developing the specification resources, TCK project committers and contributors assemble the TCK.

EFSP Step-by-step (11).png

The EFSP does not make any requirements regarding where the TCK lives. It may be a part of the corresponding specification project, or it may be separate.

When separate, a TCK project is a traditional Eclipse open source software project. Committers and contributors work on a Eclipse open source software project in much the same way they do on a specification project: committers can push directly to the project’s Git repositories, and must review and accept contributions from non-committer contributors.

Produce Milestone Builds: The project team will produce milestone builds.

EFSP Step-by-step (12).png

A milestone build is a pre-release build of a version of the specification (“Specification Version”). Milestone builds are intended for a use only by a limited audience (generally the project team themselves, committers working on candidate compatible implementations, and other early adopters).

All efforts should be undertaken to ensure that a milestone build is technically correct, though it may be incomplete. A compatible implementation cannot be based on a milestone build of a Specification.

Later builds may be labeled as “release candidates”. For the purposes of the EFSP and EDP, the terms “release candidate” and “milestone’ are different only in intent.

Progress Review: The specification project team must engage in at least one progress review during their release cycle.

EFSP Step-by-step (13).png

Progress reviews are a notion that is inherited from the EDP. The intent of a progress review is to ensure that the work is in-scope; that a project is making progress towards a release that will be approved; and that the EDP, EFSP, and Eclipse Foundation Intellectual Property Policy are being followed.

The project’s record of intellectual property contributions (IP Log) must be submitted to the EMO for review and approval before engaging in the review. Supporting materials for a review, including a concise description (executive summary) of the progress made to-date and a milestone build of the project content must be submitted before the start of the one week (minimum) review period. The progress review must be approved by simple +1 from a PMC representative, and by positive two-thirds super-majority vote of the specification committee.

Implementing the Specification: While the specification project’s committers work on the specification content, other teams may work on implementing them.

EFSP Step-by-step (14).png

An implementation cannot be referred to as a compatible implementation until after the particular version of the specification is ratified and declared a final specification (and—of course—fulfills all of the requirements of the TCK associated with the final specification).

The EFSP makes no requirement regarding timing. In a code-first world, the implementation may exist before the specification. In this hypothetical case, an implementation project’s team would instead make refinements to their implementation based on the work-in-progress. It’s expected that implementation teams will interact regularly (via open channels) with the specification project’s team to provide feedback and ask questions.

In order to be declared final, a specification needs to have at least one compatible implementation that implements all aspects of the specification (including any optional parts) and released under one of the open source licenses listed in the EFSP (more below).

This introduces a bit of a “chicken and egg” problem: we can’t have a final specification without a compatible implementation and we can’t have a compatible implementation without a final specification. The specification project, TCK project, and implementation teams need to work together so that at least one implementation will be available and complete in time to be officially released and declared a compatible implementation at the time the final specification is ratified.

Release Review: The specification project team must engage in a release review at the end of their release cycle.

EFSP Step-by-step (15).png

At least one compatible implementation must be distributed under one of the open source licenses specified by the EFSP: EPL-2.0, EDL-1.0 (BSD-3-Clause), Apache-2.0.

As is required for a progress review, the project’s record of intellectual property contributions (IP Log) must be submitted to the EMO for review and approval before engaging in the release review, the review must be approved by simple +1 from a PMC representative, and by positive two-thirds super-majority vote of the specification committee.

Following a successful release review the specification version transmogrifies into a final specification.

Final Specification: With the successful completion of a release review, including approval of the specification committee by a super-majority vote, a specification version is considered ratified and the associated artifacts are promoted and distributed by the specification committee as a final specification.

EFSP Step-by-step (16).png

All versions of specifications that are referenced by a ratified final specification must themselves be ratified. The release review for related specification versions may be run concurrently.

Final Specification Licenses: Final Specifications and their associated artifacts are distributed under specific licenses.

EFSP Step-by-step (17).png

The Specification Document for the Final Specification must be distributed as read-only text under the Eclipse Foundation Specification License. The Ratified TCK in composite is distributed under the Eclipse Foundation TCK License. Other technical artifacts must be distributed under an open source license (normally the specification project’s license).

Compatible Implementations: Implementations may only claim compatibility with a final specification.

EFSP Step-by-step (18).png

As discussed earlier, there must exist at least one compatible implementation of a specification version under one of the designated open source licenses before it can be ratified as a final specification. Other compatible implementations may be created from the final specification and distributed under other licensing terms (as determined by respective vendors).

The intellectual property rights required to build a compatible implementation flow from the final specification. That is, in order to be considered a compatible implementation and benefit from the intellectual property protections provided by the Eclipse Foundation Specification Agreement, an implementation must be based on a final specification. No claims regarding compatibility may be made for an implementation milestone build or unratified specification version.

Posted in Eclipse 101, EDP, EFSP | Leave a comment

The Eclipse Foundation and GSoC 2019

The Eclipse Foundation has been selected as a mentoring organization for Google Summer of Code 2019. This is our fourteenth year participating in this awesome programme that matches (and funds) post-secondary students with open source software projects for the summer term (in the northern hemisphere).

Eclipse Committers: if you’re are interested in participating in the programme as mentors, please send a note to to request an invitation. Candidates need to be existing committers on an Eclipse open source project. Please seed our list of potential student summer projects on our GSoC 2019 Ideas page.

Students: review our ideas page, our list of “help wanted” issues, and the issue trackers for our Eclipse open source projects. Please note that we will only accept projects that have direct relevance with one of our projects (be sure to cite the name of the relevant Eclipse open source project(s) in your proposal). Use the GSoC website to register your project idea with us. Keep in mind that our good friends at Google strictly enforce the deadlines indicated in the timeline. The Student Application Period starts on March 25, 2019 and ends on April 9, 2019. Use the time between now and March 25 to research ideas and connect with our project teams.

Mentors and students: please subscribe to the mailing list. We will use this list for all communication related to the programme. Use this channel to ask questions about the programme or get pointers to project-specific channels.

Posted in GSoC | 2 Comments