Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Foundation’ 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

Eclipse ioFog 2.0 Takes Us to the Next Era of EdgeOps

leave a comment »

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

Open VSX: A Vendor-Neutral Home for VS Code Extensions

With the transition of the Open VSX Registry from TypeFox to the Eclipse Foundation, the industry now has a vendor-neutral and publicly hosted open source alternative to the Microsoft Visual Studio Marketplace for VS Code extensions. The move increases transparency and flexibility for extension users, extension publishers, and tool developers.

Overcoming Single-Vendor Marketplace Restrictions

While the Microsoft Visual Studio Marketplace is a great resource for developers that use Microsoft VS products, its terms of use states that extensions can’t be used with the increasing number of open source tools and technologies that support the VS Code extension API.

In addition, because Microsoft doesn’t provide access to the source code for the Visual Studio Marketplace, there’s no opportunity to contribute new features and enhancements, or to reuse the source code to create an internal extension registry for in-house developers.

The Open VSX Registry is built on the Eclipse Open VSX project. It’s visually and functionally similar to the Microsoft VS Marketplace, but the extensions can be used with any editor that supports VS Code extensions — from VS Code and forks of VS Code like VSCodium, to Eclipse Theia, Eclipse Che, Gitpod, Coder, and SAP Business Application Studio.

The Eclipse Open VSX source code is open to all, so anyone can reuse and enhance the marketplace technology to meet their specific needs. They can even create an internal, private extension repository that’s connected to the upstream public Open VSX Registry.

Providing a Level Playing Field for All

Following a true open source model, all aspects of the Open VSX Registry are guided by the community based on our proven governance framework and processes for entrepreneurial collaboration. These vendor-neutral processes bring important benefits. For example:

  • No single company or vendor owns the Open VSX Registry servers, operates the service, or has more control over the service than any other participant.
  • Any individual or organization can influence how the Open VSX Registry evolves by participating in design discussions and contributing code to the Eclipse Open VSX project.
  • There’s a public record of all extension ownership claims by extension publishers to avoid conflicts over ownership.  

Driving Open VSX Registry Innovation and Collaboration

The Eclipse Cloud DevTools (ECD Tools) Working Group will manage the Open VSX Registry, driving further platform growth and marketplace adoption. With members that include Broadcom, EclipseSource, Ericsson, IBM, Intel, Red Hat, SAP, and Typefox among others, the ECD Tools ecosystem is very well positioned to support and advance the Open VSX Registry over the long term.

I want to thank all of the ECD Tools ecosystem members and Eclipse Foundation staff who worked so tirelessly to enable the smooth transition of the Open VSX Registry to the Eclipse Foundation. And a special word of appreciation to the TypeFox team who built and nurtured the Open VSX Registry from the ground up. Your contribution reflects the true spirit and values of open source communities and will benefit all.

Read the Open VSX Registry White Paper and Get Involved

To help everyone with an interest in the Open VSX Registry fully understand its benefits and potential, the ECD Tools Working Group has created a free white paper you can download here.

I also encourage you to:

Written by Mike Milinkovich

March 30, 2021 at 7:33 am

Posted in Foundation, Open Source

Eclipse Jetty 11 Supports the Big Bang

I’m happy to share the news that Eclipse Jetty 11 has been released and certified as compatible with the Jakarta Servlet v5.0 specification. Released as part of Jakarta EE 9, this new version of the Servlet specification uses the new jakarta.* namespace. Often referred to as the “Big Bang”, this new namespace is a shift that will enable future cloud native Java innovations for the enterprise Java ecosystem. By supporting Servlet 5.0 and the new namespace Jetty is helping accelerate the adoption of Jakarta EE across the ecosystem. 

Jetty is an open source web server and servlet container that is used extensively in production environments around the world. The software’s small footprint, high performance, and scalability have made it the choice of millions of enterprise application developers and open source project contributors, whether they’re using Java, Scala, Kotlin, or another JVM-based programming language.

Today, numerous well-known products and projects include Eclipse Jetty: Apache Hadoop, Apache Maven, Google App Engine, Twitter’s Streaming API, Zimbra, and the Eclipse IDE are just a few examples that demonstrate the depth and breadth of Jetty’s role and value in the Java ecosystem and broader industry.

Developers Helping Developers

Implementing the namespace change from javax.* to jakarta.* in a single Jetty release required a huge effort by many community members. I want to thank everyone involved!

The fact that the Jetty community felt it was important to implement the new namespace as soon as possible after the Jakarta EE 9 release confirms the importance of Jakarta EE as a solid foundation for the evolution of enterprise Java. The move perfectly reflects the Jetty team’s ethos of “by developers, for developers.”

Lowering the Barrier to Entry

Jakarta EE provides the complete set of specifications that define enterprise Java today. But more importantly, it provides the ecosystem a path to innovate for new cloud native APIs, platforms, services, and business models.

Each Jakarta EE specification includes an open source Technology Compatibility Kit (TCK) that allows organizations to self-certify their software with the specification. This straightforward, open process dramatically lowers the barrier to entry for vendors to provide fully certified compatible implementations of Jakarta EE specifications.

Get Involved in the Future of Open Source Java

Over the last few years, the Eclipse Foundation has cemented our role as the vendor-neutral and open source center of gravity for the Java community. We welcome everyone with an interest in the future of open source Java to get involved in Jetty, Jakarta EE, and the other enterprise Java open source projects hosted at the Eclipse Foundation such as MicroProfile, Eclipse GlassFish, Eclipse Vert.x, Eclipse Adoptium, and many more.

Here are a few quick links to help you get started:

  • To download Eclipse Jetty 11 or previous versions, visit the downloads page.
  • To get involved in Jetty, visit the project website.
  • To learn more about the benefits of joining the Jakarta EE Working Group, visit the membership page.

Written by Mike Milinkovich

March 24, 2021 at 8:19 am

Posted in Foundation

Meet Adoptium: Open Source Java Runtimes for Enterprises

Today we announced the creation of the Adoptium Working Group, whose mission is to bring high-quality, open source Java runtimes to millions of developers building the next generation of enterprise applications.

Adoptium was created in collaboration with the AdoptOpenJDK Technical Steering Committee, and supports the Eclipse Adoptium top-level project. The working group provides the vendor-neutral governance, infrastructure, marketing, community building, and developer advocacy work needed to ensure timely releases of Java runtimes and strengthen the project’s community.

The Adoptium project continues the work initiated by the AdoptOpenJDK community. The project gives developers a trusted location where they can download fully compatible, high-quality distributions of Java runtimes based on OpenJDK source code. In a few short years AdoptOpenJDK became the leading provider of OpenJDK-based binaries used to power production workloads in embedded systems, desktops, traditional servers, modern cloud platforms, and mainframes. Adoptium will continue that mission as a vendor-neutral, multi-vendor initiative hosted at the Eclipse Foundation. We appreciate the trust that the AdoptOpenJDK TSC has placed in us as we become the new stewards of this amazing community.  

The founding members of the working group include numerous Java developers, as well as vendors such as Alibaba Cloud, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, and Red Hat. This strong participation clearly shows the value the industry sees in transitioning the widely adopted AdoptOpenJDK technologies and community to the Eclipse ecosystem. I would also like to recognize the efforts of Oracle in negotiating a TCK license agreement with us in support of this initiative.

Benefits for the Global Java Ecosystem

Developers and enterprises need a dependable source of open source, compatible Java runtimes that are fully supported with timely patches and updates. AdoptOpenJDK was created in 2017 to provide a community-based solution to this requirement, delivering open build and test systems for OpenJDK across multiple platforms, and delivering high quality binaries for use. Developers responded enthusiastically, downloading more than 240 million Java binaries from AdoptOpenJDK.

Moving the AdoptOpenJDK technologies and community to the Eclipse Foundation benefits the AdoptOpenJDK community and the many members of the global Java ecosystem:

  • The AdoptOpenJDK community can leverage our governance framework and intellectual property services, as well as our developer advocacy, marketing, legal, and hosting capabilities, to help ensure the AdoptOpenJDK initiative and community continue to flourish. The community can strengthen its vendor independence, while maintaining a strong relationship with existing sponsors and the Java community as a whole.
  • Developers and enterprises in the Java ecosystem have reliable access to fully compatible Java runtimes for hybrid cloud and multi-cloud enterprise development.

Adoptium complements the other Java-based projects already hosted at the Eclipse Foundation, including the Jakarta EE and MicroProfile specification communities, and open source projects such as Eclipse GlassFish, Eclipse Jetty, and Eclipse Vert.x.

I want to thank everyone who was involved in establishing the Adoptium Working Group. I also want to welcome everyone from the AdoptOpenJDK community to the Eclipse Foundation, and encourage you to continue building on the character and spirit of your great community.

Get Involved in Adoptium 

There are a few different ways to get involved in the Adoptium community at the Eclipse Foundation:

Written by Mike Milinkovich

March 23, 2021 at 8:00 am

Posted in Foundation, Open Source

Tagged with ,