Oracle Announces Migration of Java EE to Eclipse Foundation

In a pair of Oracle blog posts dated August 17, 2017 and September 12, 2017, Oracle announced that it will move the stewardship of Java EE to the Eclipse Foundation. Java EE refers to Java Enterprise Edition.

According to Oracle’s blog posts, although Java EE is already open source and developed via the participation of Java EE community, the move to Eclipse is aimed at making the process more agile, flexible, and open. Oracle announced it will take the following steps as soon as possible after the completion of Java EE version 8 (the date of which was not announced):

  • Define a process by which existing specifications can evolve and new specifications can be included in the platform.
  • Define a branding strategy for the platform within the Eclipse Foundation, including a new name for Java EE (to be determined). Oracle intends to enable use of existing javax package names and component specification names for existing JSRs to provide continuity.
  • Demonstrate the ability to build a compatible implementation, using Eclipse Foundation sources, that passes existing Java EE 8 TCKs.
  • Recruit and enable developers and other community members and vendors to sponsor platform technologies in order to advance the platform within the Eclipse Foundation.
  • Relicense Oracle-led Java EE technologies and related GlassFish technologies, including RLS TCKs, and associated project documentation to Eclipse.

What is Java EE?

The various elements of Java — platforms, VMs, TCKs, editions, and development kits — can be confusing. To understand the implications of the migration of Java EE to Eclipse, you have to know how Java EE fits into the Java universe.

Java. Java” is a cross-platform programming language which was created to enable “write-once run-anywhere” development of applications. The term Java primarily refers to the programming language. That language uses syntax similar to C, but executes differently. Java executes on various platforms via a “VM” or virtual machine, and applications written in Java are said to run “on top of” the VM. Each application computing environment — such as Windows or Linux — has its own VM. Placing this layer between the execution of the language and the computing environment means that a single application can run in many environments.

Java Editions: Over the years, Oracle (and before it, Sun) developed several editions of Java, the most successful of which is Java SE or Standard Edition. When most people refer to Java software, this is what they mean. Standard Edition is written to deploy Java applications on desktops or servers. Other editions have included Mobile (or Micro) Edition and Java FX (GUI tools). Java Enterprise Edition (discussed below) was previously called J2EE.

Java EE: The Java element involved in the latest announcement is Java “Enterprise Edition” or Java EE. Java EE runs on top of Java SE, meaning it extends the functionality of Java SE. The Java EE platform helps developers create large-scale network applications. Descriptions of Java EE technologies used in each tier of these multi-tiered applications (Client, Web, Business) are here.

Java EE is sometimes referred to as a “platform,” a term used inconsistently in computing, but as used  by Oracle for Java, it has a specific meaning. A Java platform is a set of specifications. The specifications for Java EE version 7, for example, is here(click on the “download spec” link).

How Does the Migration Affect the Java Community?

The move to Eclipse is intended to foster a more community-driven process for development of the Java EE platform. Prior to the move to Eclipse, Oracle has developed specifications via the Java Community Process, or JCP. Anyone can participate in the JCP. However, to join as a full member, a participant must enter into the Java Specification Participation Agreement with Oracle. With the move to Eclipse, development will take place under the participation processes of the Eclipse Foundation.

The move to Eclipse will also result in changes to the TCK process. The TCK is a compatibility test kit intended to confirm that an application works with the Java EE platform. Oracle has long taken the position that only applications that pass the TCK can market themselves accordingly. Before the migration to Eclipse, TCKs were commercially licensed, and this created some complaints in the community. After the migration to Eclipse, the TCK’s for Java EE will become open source. This is helpful to open source developers who cannot or will not agree to proprietary terms.

However, it is important to note that the move announced by Oracle will not change the licensing of Java SE or OpenJDK. Though some have suggested that a complete migration of Java to an independent foundation would be welcome, Oracle has not yet taken that step.

More about Java

For more on the elements of the Java world, and their licensing, see the glossary below.

Java SE or Java Standard Edition. Licensed under a proprietary license.

TCK or Technology Compatibility Kit. The TCK is a suite of tests that checks a particular Java implementation of a specification for compliance with the Java specifications. Proprietary, but the TCK for Java EE will move to open source

RI or Reference Implementation. An RI is developed concurrently with specifications and test suites. It verifies that the specification can be implemented, enables the test suite to be tested, serves as a reference for other implementations, and helps to discover errors or clarify errors in the specification. Glassfish is Oracle’s Java EE reference implementation (see also here for other vendors providing implementations). Glassfish is licensed under CDDL and GPL+CE.

OpenJDK is Oracle’s open source implementation of the Java VM, similar to Standard Edition.* JDK means Java Development Kit. A JDK is a program development environment — a set of tools for developing Java programs. OpenJDK is licensed under GPL+CE.

JVM and JRE are computer packages software packages that enable a computer to run a program written in Java. JVM means Java Virtual Machine; JRE means Java Runtime Environment.

Oracle JDK is abinary release of OpenJDK. It is licensed under the Oracle Binary Code License Agreement (though its counterpart OpenJDK is licensed under GPL/+CE, as described above).

*How similar is a matter of debate. OpenJDK is free software, and Java SE is not. Therefore, users of Java are keenly interested in the additional value represented by Java SE and accordingly, whether a paid license is worthwhile. But this information has always been difficult to pin down. Oracle says it will continue to ship commercial features in Oracle JDK, such as Java Flight Recorder and Mission Control, under a click-through binary license and will offer paid support for these builds. After Oracle JDK 9, Oracle plans to open-source those commercial features, with the long-term goal to make the OpenJDK and Oracle JDK builds interchangeable.

Thanks to Daniel Levy, of O’Melveny & Myers, for his assistance on this post.

Kernel Developers Unite Behind Community Enforcement Pledge

The Linux Foundation released a Community Enforcement Statement, and implemented a means to allow kernel developers to show their commitment to this statement.

Responding to concerns about rogue enforcement by kernel developers who have engaged in copyright profiteering (see my prior post for background), this effort is intended to set community expectation for enforcement of GPL violations relating to the Linux kernel.

An FAQ released by the Foundation explains that the commitment effectively implements opportunities to cure violations, similar to the opportunity available in GPL3, even though the license for the kernel remains under GPL2.

 

Red Hat Shows Promise — Again

Red Hat released an updated and expanded version of its patent promise.

The revised patent pledge extends to “Covered FOSS,” which has a broad definition.  Red Hat’s FAQ says, “While the old Promise covered approximately 35 percent of open source software, the new version will cover more than 99 percent. It applies to all software meeting the free software or open source definitions of the Free Software Foundation or the Open Source Initiative and listed by the FSF or OSI.”  Both pledges cover all Red Hat’s patents.

Patent pledges are promises not to assert patents accusing certain activities or products.  They help manage an apparent (but usually not quite actual) philosophical contradiction between releasing open source software and seeking patent protection.  Red Hat pioneered this approach over a decade ago with its first version of the patent pledge, and other technology companies followed suit.  But the popularity of promulgating patent pledges has waned somewhat, mostly because the fears they addressed have receded; bringing patent infringement claims accusing open source products is a scorched earth strategy.  Over the last decade, few operating entities have demonstrated any appetite for it — Microsoft and Oracle being the most notable exceptions.

Kudos to Red Hat for its new promise!

For some other examples of patent pledges (and similar legal arcana), see:

IBM’s Statement of Non-Assertion of Named Patents Against OSS

Google’s Open Patent Non-Assertion Pledge

Tesla’s All Our Patents Are Belong to You

Twitter’s Innovator’s Patent Agreement

 

 

Equifax Security Hack and Apache Struts

The Equifax security breach has been big news lately. Understandably, there was much concern over a breach that involved sensitive information held by a credit bureau, involving millions of consumers.

One article in Quartz noted that the perpetrators of the breach may have exploited a security vulnerability in Apache Struts, an MVC framework for creating Java web applications with plugins to support REST, AJAX and JSON. The Quartz article mentioned several potential vulnerabilities cited in a William Baird & Co. report, and about one, commented that “the vulnerability announced on Sept. 4” had existed in Struts for many years.

The Apache Software Foundation responded publicly, and pointing that the problem was a so-called Zero Day vulnerability, or a vulnerability that may have existed for some time in a code base, but was not previously known to the developers.  The ASF commented: “Regarding the assertion that especially CVE-2017-9805 is a nine year old security flaw, one has to understand that there is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years.  If the latter was the case, the team would have had a hard time to provide a good answer why they did not fix this earlier.  But this was actually not the case here — we were notified just recently on how a certain piece of code can be misused, and we fixed this ASAP. ”

It may seem, after wide reporting of a few open source vulnerabilities such as Heartbleed, that open source is being publicly linked with security problems with increasing frequency. That might, in turn, seem to imply that open source is not secure. However, given that so much infrastructure software now is open source, and security breaches (or at least detecting them) are increasing in frequency, the reporting of open source security vulnerabilities is probably mostly confirmation bias. It isn’t as big news when a security breach happens due to proprietary software. And all reporting of breaches is to some degree imprecise forensic archeology; it may not always be clear in retrospect which vulnerabilities were actually exploited.  

Infosec professionals would probably say that legacy software is always a potential security problem, whether it is open source or not. Tech security is, in part, a process of continual updating to keep ahead of the villains. But this new incident underscores, again, the need to ensure that widely used open source projects have the resources to stay ahead of security concerns.

Open Source Skills in High Demand

It was interesting to see a recent article in ZDNet on the un-slaked demand for open source professionals.  The article says, “The single most desirable job most hiring managers want to fill is developer (73 percent). Don’t despair if you’re not a programmer; demand is also high for DevOps (60 percent) and Systems Administrators (53 percent).”  The information comes from the 2017 Open Source Jobs Report issued by the Linux Foundation.

Those of use who work in this area also know that experienced open source compliance managers and legal analysts are also in strong demand.