Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Jakarta EE’ Category

On Patents and Specifications

leave a comment »

We’ve been fielding a number of questions lately about the intersection of our spec process and patents. A couple of these community discussions have gone off in directions that are off target, factually incorrect, or both. Therefore, the purpose of this short FAQ is to explain the patent license options provided by the Eclipse Foundation Intellectual Property Policy for use by specifications developed by specification projects under the Eclipse Foundation Specification Process (EFSP). 

Disclaimer: This is not legal advice. I am not a lawyer. It has not been reviewed by counsel. Consult your own attorney. In addition, this note does not form part of any official Eclipse Foundation policy or process, but rather is provided for informational purposes only to aid those involved in our specification projects to better understand the EFSP and the choices available. I’ll update the content as needed.

One important point to keep in mind when reading this: we believe that the EFSP fully complies with the Open Standards Requirement for Software established by the Open Source Initiative. In other words, the EFSP is designed specifically to be open source friendly.  

Why do specifications require patent licenses?

The purpose of every specification is to stimulate the development of implementations. These implementations may be derived from open source code maintained at the Eclipse Foundation or elsewhere, or they may be independently developed. They may be made available under open source licenses or proprietary. In order to facilitate and encourage these implementations, all specification processes provide some notion of patent licenses from the parties involved in developing the specifications.

What types of patent licenses are used by various specification organizations?

There are a wide variety of specification patent license options available from various sources. 

Some terms that you may hear are:

  • FRAND means fair, reasonable, and non-discriminatory licenses. This means that before you can implement the specification you are required to obtain a license from the patent holders who developed the specification. FRAND is generally considered to be antithetical to open source development, as it requires permission and money to implement a specification or potentially even to use an implementation of such a specification.
  • FRAND-Z is FRAND where the cost of the license is set to zero. Note that although this removes the cost concerns of FRAND, permission may still be required for use and/or implementation. 
  • RF or royalty-free provides a priori royalty-free licenses from the participants developing the specifications to downstream users and implementers. This is considered a best practice for enabling open source implementations of a specification. All Eclipse Foundation specifications are developed on a royalty-free basis. 
  • Non-assert is another legal mechanism which provides a result effectively similar to royalty-free. A non-assert says that a patent holder will not assert their patent rights against an implementer or user. 

Do these licenses mean that an implementer or user can never be sued for patent infringement?

No. The patent licenses are intended to ensure that an implementer or user doesn’t need to be worried about being sued by the parties involved in developing the specifications. It does not provide protection from uninvolved third parties who may believe they have intellectual property rights applicable to the specification. 

Note that the above implies that it is in the interests of the entire community and ecosystem that many participants (particularly patent-owning participants) be involved in developing the specifications. It also explains why it is in the best interest of the community that all participants in the specification process have signed agreements in place documenting their commitment to the patent licensing under the EFSP. 

What patent licenses are granted by the EFSP?

The patent licenses provided via the EFSP apply to all downstream implementations of Final Specifications, including independent implementations. They cover all patents owned by each Participant in the specification project that are essential claims needed by any implementer or user of the specification. Note that the licenses cover the entire specification, not just to the parts of the specification that a participant may have contributed to. We provide our specifications two options for patent licenses: the Compatible Patent License and the Implementation Patent License. The differences between those two are explained below.

But my open source license already has a patent license in it. Why do I need more than that?

The patent licenses provided in open source licenses such as APACHE-2.0 grant a license for contributor-owned patents which apply to their contribution either alone or as combined with the work. The patent license is only to that program/implementation. Note that the APACHE-2.0 patent license  “…applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work…”. Relative to the EFSP, such grants are deficient in both scope (applies only to their contributions) and target (applies only to that implementation). 

What is the difference between the two patent license options provided by the EFSP?

The only difference between the Compatible Patent License and and the Implementation Patent License is the timing of when the patent license grant comes into effect. In the Compatible Patent License, the license grant only happens when the implementation has demonstrated that it is fully compatible with the specification by passing the relevant TCK. The Implementation Patent License provides immediate patent licenses to all implementers, even to partial or work-in-progress implementations. The first choice emphasizes the importance of compatibility. The latter choice emphasizes the importance of open development. Both are valuable options available to Eclipse specification projects. 

I’ve read the EFSP and I don’t see anything about patent licenses. WUWT?

The patent licenses are provided in the Eclipse Foundation Intellectual Property Policy. A future version of the EFSP will make this clearer.

Is the Eclipse Foundation itself granted any licenses to patents? 

No. The Eclipse Foundation itself does not acquire any patent rights in the specifications. The patent licenses are granted from the participating patent owners directly to implementers and users of those specifications. More specifically, the patent license grants are “… to everyone to make, have made, use, sell, offer to sell, and import…” implementations of the specifications.

Written by Mike Milinkovich

May 13, 2021 at 3:20 pm

Jakarta EE Is Taking Off

With the results of the 2020 Jakarta EE survey and the initial milestone release of the Jakarta EE 9, it’s clear the community’s collective efforts are resonating with the global Java ecosystem.

Before I get to the survey results, I want to say a huge thank you to everyone who took the time to participate in the survey. We received nearly 2,200 responses from software developers, architects, and decision-makers around the world — an increase of almost 20 percent over last year’s survey. With your insight, we’ve gained a clear and comprehensive view of enterprise Java strategies and priorities globally, which in turn we are freely sharing with the ecosystem.

Jakarta EE Adoption and Compatible Implementations Are on the Rise

Less than a year after its initial release, Jakarta EE has emerged as the second-place cloud native framework with 35 percent of respondents saying they use it. While the Spring and Spring Boot frameworks are still the leading choices for building cloud native applications, their usage share dropped 13 percent to 44 percent in the 2020 survey results.

Combined, Java EE 8 and Jakarta EE 8 hit the mainstream with 55 percent adoption. Jakarta EE 8 was responsible for 17 percent of that usage, despite only shipping for the first time in September 2019. This is truly significant growth.

We’re also seeing a strong uptick in Jakarta EE 8 compatible products. Companies including IBM, Red Hat, Payara, Primeton, TmaxSoft, and Apusic now have Jakarta EE 8 Full Platform compatible products. Since January 2020, we’ve had four new Full Platform compatible implementations and one new Web Profile compatible implementation. In addition to Eclipse GlassFish 5.1, this brings Jakarta EE 8 adoption to 12 compatible products. This is an outstanding achievement for the Jakarta EE community to have more full platform compatible products in 8 months than Java EE 8 had in over 2 years. You can see the complete list here.

You can also expect to see additional compatible implementations in the coming months as more applications are passing Technology Compatibility Kit (TCK) tests and are well on their way to becoming certified as Jakarta EE 8-compatible products.

Architectural Approaches Are Evolving

This year’s Jakarta EE survey also showed a slight drop in the popularity of using a microservices architecture for implementing Java systems in the cloud compared to last year. At the same time, use of monolithic architectures for implementing Java systems in the cloud nearly doubled since last year’s survey and is now at 25 percent.

These results may indicate that companies are pragmatically choosing to simply “lift and shift” existing applications to the cloud instead of rearchitecting them as microservices.

Interestingly, the survey also indicated the Jakarta EE community would like to see better support for microservices in the platform. When you combine this fact with the rise of Jakarta EE, it’s reasonable to believe developers may be starting to favor vendor-neutral standards for building Java microservices over single-vendor microservices frameworks.

The Industry Is Moving to the New Jakarta EE Namespace

The support we’re seeing for the adoption of the new namespace in Jakarta EE 9 reinforces the value the industry sees in Jakarta EE. Technology leaders are already investing to ensure their software supports the Jakarta EE 9 namespace changes and others have indicated they will do the same. Some of these implementations include:

  • Eclipse GlassFish 6.0 milestone release is available to download
  • Jetty 11.0.0-alpha0 milestone release is available to download
  • Apache Tomcat 10.0 M6 milestone release is available to download
  • Payara Platform 6 milestone release coming in Q4 2020
  • OpenLiberty 20.0.0.7 Beta release is available with basic Web application support to download
  • Apache TomEE 9.0 milestone release using Eclipse Transformer project tools is available to download
  • WildFly 21 is planning a milestone release for fall 2020
  • Piranha Micro p20.6.1 milestone release is available to download.

While the Jakarta EE 9 tooling release doesn’t include new features, it’s a very important and necessary step on the road to Jakarta EE 10 and the next era of innovation using cloud native technologies for Java. With the full Jakarta EE 9 release in fall this year, Jakarta EE will be ideally positioned to drive true open source, cloud native innovation using Java.

Diversity, Achieved

One of the items that I am particularly happy about is the achievement of establishing Jakarta EE as a vendor-neutral, community-led technology platform. When we started the process of moving Java EE from Oracle to the Eclipse Foundation there were some who doubted that it could be accomplished successfully. The numbers tell the story: Oracle’s contributions are still leading the pack at 27%, but the community-at-large is

JakartEEDev v2
now over 40%. Contributions from our other members are led by Payara, VMware (Pivotal), Red Hat, and IBM. Based on these results, it is clear that Jakarta EE has truly achieved its original objective of becoming a vendor-neutral, community-led industry initiative. A lot of people worked very hard to achieve this, and I’m thrilled by the results.

Discover Jakarta EE

Here are three ways to learn more about Jakarta EE and understand why it’s gaining mainstream adoption so quickly:

  • Join the community at the Jakarta EE 9 Milestone Release Virtual Party and networking opportunity on Tuesday, June 23 at 11:00 a.m. EDT. To register for the event, click here.
  • Find out more about the Jakarta EE 9 milestone release here.
  • Review the complete 2020 Jakarta EE Survey results here.

Edit: Reflect IBM’s contributions
Edit #2: Add link to Apache TomEE download

Written by Mike Milinkovich

June 23, 2020 at 7:03 am

Add Your Voice to the 2020 Jakarta EE Developer Survey

Our third annual Jakarta EE Developer Survey is now open and I encourage everyone to take a few minutes and complete the survey before the April 30 deadline. Your input is extremely important.

With your feedback, the entire Java ecosystem will have a better understanding of the requirements, priorities, and perceptions in the global Java developer community. This understanding enables a clearer view of the Java industry landscape, the challenges Java developers are facing, and the opportunities for enterprise Java stakeholders in the cloud native era.

The Jakarta EE Developer Survey is one of the Java industry’s largest developer surveys. Since the survey’s inception, we’ve received thousands of responses from developers around the world, including 1,700 responses in 2019 — a clear indication the Java developer community recognizes the value of the survey results.

Last year, we were able to share critical insight into the state of cloud native innovation for enterprise Java development globally, including expected growth rates for Java apps in the cloud as well as leading architectures, applications, and technologies. We were also able to share the community’s top priorities for Jakarta EE.

This year, we’re asking developers to tell us more about their next steps for Java and cloud native development and their choices for architectures, technologies, and tools as cloud native resources for Java mature.

With this updated information, platform vendors, enterprises, and individual developers in the Java ecosystem will have a better understanding of how the cloud native world for enterprise Java is unfolding and what that means for their strategies and businesses. And the Jakarta EE community at the Eclipse Foundation will have a better understanding of the community’s top priorities for future Jakarta EE releases.

The Jakarta EE Developer Survey is your opportunity to add your voice to the global Java ecosystem and we’re counting on our entire community to help us gain the broadest possible view of the state of cloud native technologies in the context of enterprise Java. Best of all, this year we’ve organized the survey so it takes less than 10 minutes to complete!

To access the survey, click here.

Written by Mike Milinkovich

April 7, 2020 at 8:02 am

Cloud Native for Java Day @ KubeCon EU

Cloud Native for Java (CN4J) Day at KubeCon + CloudNativeCon Europe will be the first time the best and brightest minds from the Java ecosystem and the Kubernetes ecosystem come together at one event to collaborate and share their expertise.

The all-day event on March 30 includes expert talks, demos, and thought-provoking sessions focused on building cloud native enterprise applications using Jakarta EE-based microservices on Kubernetes. CN4J Day is a proud moment for all of us at the Eclipse Foundation as it confirms the Jakarta EE and MicroProfile communities are at the forefront of fulfilling the promise of cloud native Java. We’re excited to be working with our friends at the CNCF to offer this event co-located with KubeCon Europe.

A Unique Opportunity to Engage With Global Experts

The timing of CN4J Day could not be better. With momentum toward the Jakarta EE 9 release building, this event gives all of us an important and truly unique opportunity to:

  •     Learn more about the future of cloud native Java development from industry and community leaders
  •     Gain deeper insight into key aspects of Jakarta EE, MicroProfile, and Kubernetes technologies
  •     Meet and share ideas with global Java and Kubernetes ecosystem innovators

The global Java ecosystem has embraced CN4J day and several of its leading minds will be on-hand to share their insights. Along with keynote addresses from my colleague Tanja Obradovic and IBM Java CTO, Tim Ellison, CN4J Day features informative technical talks from Java experts and Eclipse Foundation community members, such as:

  •     Adam Bien, an internationally recognized Java architect, developer, workshop leader, and author
  •     Sebastian Daschner, lead java developer advocate at IBM
  •     Clement Escoffier, principal software engineer at Red Hat
  •     Ken Finnegan, senior principal engineer at Red Hat
  •     Emily Jiang, liberty architect for MicroProfile and CDI at IBM
  •     Dmitry Kornilov, Jakarta EE and Helidon Team Leader at Oracle
  •     Tomas Langer, Helidon Architect & Developer at Oracle

Major Industry and Ecosystem Endorsement

Leading industry players in the Java ecosystem are also showing their support for CN4J Day through sponsorship. Our sponsors include:

  •     Cloud Native Computing Foundation (CNCF)
  •     IBM
  •     Oracle
  •     Red Hat

The event is being coordinated by an independent program committee composed of Arun Gupta, principal technologist at Amazon Web Services, Reza Rahman, principal program manager for Java on Azure at Microsoft, and Tanja Obradovic, program manager for Jakarta EE at the Eclipse Foundation.

Register Today

To register today, simply add the event to your KubeCon + CloudNativeCon Europe registration. Thanks to the generous support of our sponsors, a limited amount of discounted CN4J Day add-on registrations will be made available to Jakarta EE and MicroProfile community members on a first-come, first-served basis.

For more details about CN4J Day and a link to the registration page, click here. For additional questions regarding this event, please reach out to events-info@eclipse.org.

As additional speakers and sponsors come onboard, we’ll keep you posted, so watch for updates in our blogs and newsletters.

Written by Mike Milinkovich

January 28, 2020 at 7:00 am

Moving Forward With Jakarta EE 9

On behalf of the Jakarta EE Working Group, I am excited to announce the unanimous approval of the plan for Jakarta EE 9, with an anticipated mid-2020 release. Please note that the project team believes this timeline is aggressive, so think of this as a plan of intent with early estimate dates. The milestone dates will be reviewed and possibly adjusted at each release review.

If you have any interest at all in the past, present, or future of Java, I highly recommend that you read that plan document, as Jakarta EE 9 represents a major inflection point in the platform.

The key elements of  this Jakarta EE 9 release plan are to:

  • move all specification APIs to the jakarta namespace (sometimes referred to as the “big bang”);
  • remove unwanted or deprecated specifications;
  • minor enhancements to a small number of specifications;
  • add no new specifications, apart from specifications pruned from Java SE 8 where appropriate; and
  • Java SE 11 support.

What is not in the plan is the addition of any significant new functionality. That is because the goals of this Jakarta EE 9 release plan are to:

  • lower the barrier of entry to new vendors and implementations to achieve compatibility;
  • make the release available rapidly as a platform for future innovation; and
  • provide a platform that developers can use as a stable target for testing migration to the new namespace.

Moving a platform and ecosystem the size and scale of Jakarta EE takes time and careful planning. After a great deal of discussion the community consensus was that using EE 9 to provide a clear transition to the jakarta namespace, and to pare down the platform would be the best path to future success. While work on the EE 9 platform release is proceeding, individual component specification teams are encouraged to innovate in their individual specifications, which will hopefully lead to a rapid iteration towards the Jakarta EE 10 release.

Defining this release plan has been an enormous community effort. A lot of time and energy went into its development. It has been exciting to watch the … ummm passionate…. discussions evolve towards a pretty broad consensus on this approach. I would like to particularly recognize the contributions of Steve Millidge, Kevin Sutter, Bill Shannon, David Blevins, and Scott Stark for their tireless and occasionally thankless work in guiding this process.

The Jakarta EE Working Group has been busy working on creating a Program Plan, Marketing Plan and Budget for 2020. The team has also been very busy with creating a plan for the Jakarta EE 9 release. The Jakarta EE Platform project team, as requested, has delivered a proposal plan to the Steering Committee. With their endorsement, it will be voted on by the Specification Committee at their first meeting in January 2020.

Retrospective

The Jakarta EE 9 release is going to be an important step in the evolution of the platform, but it is important to recognize the many accomplishments that happened in 2019 that made this plan possible.

First, the Eclipse Foundation and Oracle successfully completed some very complex negotiations about how Java EE would be evolved under the community-led Jakarta EE process. Although the Jakarta EE community cannot evolve the specifications under the javax namespace, we were still able to fully transition the Java EE specifications to the Eclipse Foundation. That transition led to the second major accomplishment in 2019: the first release of Jakarta EE. Those two milestones were, in my view, absolutely key accomplishments. They were enabled by a number of other large efforts, such as creating the Eclipse Foundation Specification Process, significant revisions to our IP Policy, and establishing the Jakarta EE compatibility program. But ultimately, the most satisfying result of all of this effort is the fact that we have seven fully compatible Jakarta EE 8 products, with more on the way.

The Jakarta EE community was also incredibly active in 2019. Here are just a few of the highlights:

2019 was a very busy year, and it laid the foundation for a very successful 2020. I, and the entire Jakarta EE community, look forward to the exciting progress and innovation coming in 2020.

Written by Mike Milinkovich

January 16, 2020 at 12:06 pm