Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for May 2021

Jakarta EE 9.1 Accelerates Open Source Enterprise Java

leave a comment »

Just a little more than five months ago, I was sharing news about the Jakarta EE 9 platform release. Today, I’m very pleased to tell you that the Jakarta EE Working Group has released the Jakarta EE 9.1 Platform and Web Profile specifications and related Technology Compatibility Kits (TCKs). Congratulations and thanks to everyone in the Jakarta EE community who made this release possible.

The accelerated innovation we’re seeing in Jakarta EE, and the growing number of compatible implementations, are clear signs that enterprise Java is experiencing a renaissance.

Enterprises Have New Agility to Develop and Evolve Java Applications

Jakarta EE 9 opened the door to the next era of innovation using cloud native technologies for Java by delivering the “big bang” namespace change to jakarta.*. 

Jakarta EE 9.1 takes that rejuvenation to the next level. The release includes a number of updates and new options, and is compatible with Java SE 11, which is seeing increasing adoption. The 2020 Jakarta EE Developer Survey revealed that 28 percent of respondents were using Java SE 11, compared to 20 percent of respondents in 2019.

Together, the advances in Jakarta EE 9.1 give enterprises the flexibility to make more choices, and to mix and match technologies as needed to meet their unique application development and migration requirements. With Jakarta EE 9.1, enterprises can:

  • Develop and deploy Jakarta EE 9.1 applications on Java SE 11, the most current LTS release of Java SE, as well as Java SE 8
  • Leverage Java SE 11 features that have been added since Java SE 8 in their Jakarta EE 9.1 applications 
  • Take advantage of new technologies that support Java SE 11 in their Jakarta EE 9.1 applications
  • Move existing Jakarta EE 9 applications to Java SE 11 without changes
  • Migrate existing Java EE and Jakarta EE 8 applications to Jakarta EE 9.1 using the same straightforward process available for migration to Jakarta EE 9

With a variety of paths to choose from, every enterprise can develop and migrate Java applications in a way that aligns with their technical objectives and business goals.

There Are Already Five Jakarta EE 9.1-Compatible Applications

As we announce Jakarta EE 9.1, five products from global leaders in the Java ecosystem have already been certified as compatible with the release:

  • IBM’s Open Liberty
  • Eclipse Glassfish
  • Apache TomEE
  • Red Hat’s Wildfly
  • ManageCat’s ManageFish

These implementations are proof positive the Java ecosystem recognizes the value Jakarta EE brings to their business and the technologies they develop.

The rapid technology adoption we’re seeing with Jakarta EE is thanks to the openness of  the Jakarta EE Specification Process. This simplified process dramatically lowers the barrier to entry, making it much easier for organizations of all sizes to have their products certified as a compatible implementation and leverage the Jakarta EE brand for their own business success.

The number of compatible implementations across Jakarta EE releases is growing all the time, so be sure to check the Jakarta EE compatible products webpage for the latest list. To be listed as a Jakarta EE-compatible product, follow the instructions here.

Learn More About Jakarta EE 9.1 and Get Involved

To learn more about the Jakarta EE 9.1 release contents, read the Jakarta EE 9.1 release plan and check out the specifications.

As the focus shifts to Jakarta EE 10, the Jakarta EE Working Group and community welcome all organizations and individuals who want to participate. To learn more and get involved in the conversation, explore the benefits of membership in the Jakarta EE Working Group and connect with the community.

Written by Mike Milinkovich

May 26, 2021 at 7:05 am

Posted in Foundation, Jakarta EE

On Patents and Specifications

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

Eclipse ioFog 2.0 Takes Us to the Next Era of EdgeOps

On Tuesday, the Eclipse ioFog project team announced the release of Eclipse ioFog 2.0, and I invite everyone to join me in congratulating them and the Eclipse Edge Native Working Group for the achievement. Thanks to the community’s efforts, the release delivers new EdgeOps functionality that makes it faster and easier to develop production-grade edge applications and manage edge AI deployments.

The ioFog platform brings cloud native architectures such as Kubernetes to the edge, allowing developers to deploy, orchestrate, and manage microservices on any edge device. It’s unique in the industry because it abstracts the complexities of networking from the edge applications.

The Eclipse ioFog platform is already widely used and proven in the field. Organizations ranging from major service providers to FORTUNE 500 companies all rely on the software in production environments today. The ioFog platform has even been used as the backbone of an edge AI application that monitors children’s temperatures and use of masks in schools to help prevent the spread of COVID-19. It’s a great example of the value and potential the ioFog platform delivers.

EdgeOps Targets Edge Computing Challenges

The new EdgeOps capabilities in Eclipse ioFog 2.0 take that value and potential to the next level.

EdgeOps technologies and tools are built from the ground up to address the unique challenges that arise when developing edge computing applications. They’re needed because traditional DevOps technologies and tools are not well-suited to edge computing. The EdgeOps concept was defined by the Eclipse Edge Native Working Group, and the Eclipse ioFog platform is a key enabling technology.

Here’s a brief look at what the new EdgeOps features in Eclipse ioFog 2.0 mean for developers.

Red Hat’s Skupper Project Simplifies Application Connections

The Eclipse ioFog architecture is based on the concept of an Edge Compute Network (ECN) that’s comprised of a Controller, Agents (more on this later), and a Service Mesh.

In Eclipse ioFog 2.0, the Service Mesh component was replaced with Red Hat’s Skupper project.

Skupper uses the Apache Qpid Dispatch Router for application connectivity between data centers and any type of edge with no need for virtual private networks (VPNs) or special firewall rules. As a result, developers can now set up application connections using a simple yaml configuration file.

New Features Enable More Fluid EdgeOps

Eclipse ioFog 2.0 also includes new features that give developers more flexible and adaptable EdgeOps capabilities.

For example, developers can now add, remove, and move ioFog Agents between ECNs at runtime. Agents are lightweight, universal container runtimes that are installed on edge devices to manage the life cycle of microservices, data volumes, edge resources, and other assets. With Eclipse ioFog 2.0, developers have new agility to take advantage of live orchestration, and to migrate and drain microservices and applications.

Developers also have new abilities to:

·      Prune images based on policies

·      Manage multiple image registries

·      Mount data volumes in microservices containers

Together, these features showcase the Edge Native community’s ability to deliver the production-ready features edge application developers need to support real-world use cases.

Learn More and Get Started With Eclipse ioFog 2.0

Be sure to check out the following for additional insight:

·      For more information on the contents of the Eclipse ioFog 2.0 release, click here.

·      To learn more about EdgeOps, read our recent newsletter article and new white paper.

·      To learn more about the Eclipse Edge Native Working Group, review the working group charter and participation agreement, and visit the website.

Written by Mike Milinkovich

May 13, 2021 at 10:43 am

Posted in Foundation