A guide entitled Starting an Open Source Project was released by the Linux Foundation, with contributions from open source advocates at Facebook, Samsung Research America, Capital One and Autodesk. The guide describes business and technical considerations for businesses contemplating an open source code release, with a handy checklist at the end.
Today, Red Hat and several other major technology companies released a commitment to afford GPLv3-style cure terms to GPLv2 violations, in an effort to “provide greater predictability to users of open source software.”
These commitments represent a consistent community effort to distance enforcers (or potential enforcers) — like Software Freedom Conservancy, the Linux Foundation, and other technology companies — from the kind of copyright trolls reported here. They also represent an effort to resolve the legal questions raised by lack of an express cure provision in GPLv2, and other open source licenses.
UPDATE: Bruce Perens wrote an interesting FAQ on this.
The Software Freedom Law Center (SFLC) and the Software Freedom Conservancy (SFC) have fallen out publicly over a filing by SFLC seeking cancellation of the SFC’s trademark due to confusion between the two.
The SFC posted about it here. The posting says the SFLC took ” the bizarre and frivolous step of filing a legal action…seeking cancellation of Conservancy’s trademark….We are surprised and sad that our former attorneys, who kindly helped our organization start in our earliest days and later excitedly endorsed us when we moved from a volunteer organization to a staffed one, would seek to invalidate our trademark.”
The SFLC’s response is here. It describes the SFC posting as “a puff of near-apocalyptic rhetoric about us…published by SFLC’s former employees, Karen Sandler and Bradley Kuhn, who now manage the Conservancy, which was originally established and wholly funded by SFLC, and still bears our name…”
I will write up some legal analysis of this intermural dispute, right after I have taken care of more important things, like leveling up all of my characters in Disgaea 5.*
*For the benefit of those more sensible than me: the playable characters in this game are essentially unlimited, and the process of leveling them up takes essentially forever.
UPDATE: Here is some interesting additional commentary by Karl Fogel. But I am still leveling up.
UPDATE: Interesting article in the Register describes some background about the differing ideologies of SFC and SFLC.
The Linux Foundation announced the release of a new set of open data licenses. They include a permissive license and a copyleft-type (“sharing”) license. They are both drafted as agreements (and according to the FAQ, also licenses). A context document describes the goal of the effort.
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.
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.
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 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