The CDDL — short for Common Development and Distribution License — is a weak copyleft open source software license initially published by Sun Microsystems. The CDDL has similar provisions to the Mozilla Public License 2.0 and the Eclipse Public License.
As a weak copyleft license, the CDDL carries more requirements on the use of the licensed code than permissive licenses but offers more freedoms than strong copyleft licenses.
In this blog, we’ll discuss the CDDL’s requirements and provisions, compare CDDL v 1.0 to v 1.1, and explain how it’s different from other weak copyleft licenses.
CDDL 1.0 vs. CDDL 1.1
There are two versions of the CDDL — 1.0 and 1.1 — but there are only a few, minor differences between them. These include:
- CDDL 1.0 lists Sun Microsystems as the initial license steward. CDDL 1.1 lists Oracle (which acquired Sun in 2009) instead.
- CDDL 1.1 adds a choice of law provision stating litigation related to the license will be under the jurisdiction of the federal courts of the Northern District of California and the California state courts.
- CDDL 1.0 is an OSI-approved license, but CDDL 1.1 is not. We have not been able to find a confirmed explanation for this, but the best guess is simply that Oracle (the v 1.1 license steward) never submitted it for OSI approval.
Note: Because CDDL 1.0 and 1.1 are so similar, all analysis for the remainder of the blog will apply to both versions.
CDDL Requirements and Permissions
As a weak copyleft license, the CDDL is a middle ground of sorts between permissive options (like the MIT License or Apache License 2.0) and strong copyleft licenses (like GPL v2 and GPL v3.)
The CDDL does require that derivative works (“Covered Software”) of CDDL-licensed code also be licensed under the CDDL. As such, anyone who distributes a derivative work must also make their source code available.
However, the copyleft nature of the CDDL is more limited in scope than licenses like the AGPL or GPL. It’s possible to use CDDL-licensed code in your project without being subject to source code sharing requirements — but only if you don’t modify the CDDL-licensed code and keep it in a separate file(s).
You could then combine that CDDL-licensed code with software under another license(s) to create an aggregate “larger work.” The resulting larger work can be kept proprietary or released under a different license.
CDDL Requirements
Key requirements of the CDDL are as follows. You must:
- Include a copy of the full license text and the original copyright notice.
- Make available your source code when you distribute a derivative work (“Covered Software”) based on the licensed code.
CDDL users are also required to license any derivative works of the CDDL-licensed component under the same or later version of the CDDL — unless the initial developer includes a notice in the initial software prohibiting re-licensing to a later version of the CDDL.
Using CDDL-Licensed Code
Users of CDDL-licensed code may:
- Use the code commercially: The CDDL imposes no conditions on using the code in software that’s sold commercially
- Change the code: Users can rework the code, but if they distribute these modifications, they must make them available in source code form.
- Place warranty: You can offer a warranty on your version of CDDL-licensed software.
- Practice patentable inventions: Contributors to the licensed code provide an explicit grant of patent rights to users.
- Sublicense binaries: A developer may place binaries under a different license if that binary meets the definition for a “larger work” — the CDDL-licensed component is kept in a separate file from software under another license(s). The source code for the CDDL-licensed component must still be made available under CDDL in source code form.
The CDDL does not grant trademark rights, meaning that users of CDDL-licensed code cannot use the trademarks, names, logos, etc. of the original project or its contributors.
CDDL vs. Other Weak Copyleft Licenses
As discussed, the Common Development and Distribution License has a lot in common with the MPL and EPL. But there are a few notable differences, which we’ll explore below.
CDDL vs. MPL
Sun Microsystems drafted the CDDL (Common Development and Distribution License) in 2004 based on the Mozilla Public License 1.1. But there are a handful of differences between the two weak copyleft licenses.
Effect of new versions: The MPL (all versions) allows for derivative works to be licensed under the same — or any future version — of the license. For example, in the hypothetical where the MPL 3.0 is created, you could license a derivative of an MPL 2.0 component under MPL 2.0 or MPL 3.0.
In contrast, the CDDL gives the initial developer the right to specify which version of the CDDL derivative works can be licensed under. For example, the initial developer can require derivative works of a CDDL-licensed component to be licensed under the current CDDL version — even if new versions of the CDDL are released.
(However, if the initial developer doesn’t include a notice, you are free to distribute derivative works under the current CDDL 1.1 or any later version.)
Patent peace: The CDDL and the MPL 1.0 and 1.1 include what’s known as a “patent peace” clause that aims to discourage patent infringement claims. The difference is in the scope of these provisions. The MPL 1.1 (but not 2.0) is quite broad — your license to use and distribute MPL-licensed code is revoked if you file a patent infringement claim against the initial contributor for “software, hardware, or device.” In contrast, the CDDL covers only software.
Another significant difference between the CDDL and the MPL 1.1 is that the latter has a provision that requires derivative works to state the nature of code modifications. You are required to create a file that documents code changes and the dates when those changes were made. Notably, this “state changes” clause is not in the MPL 2.0.
Finally, the MPL 2.0 is compatible with GPL v2 or later, LGPL 2.1 or later, and/or AGPL 3.0 or later, while the CDDL and earlier versions of the MPL are not.
CDDL vs. EPL
There are a few significant differences between the CDDL and the EPL. For one, if you commercially distribute a product that includes an EPL-licensed program, you are required to defend that program’s contributors from any lawsuits/legal damages that may arise involving your product. There is no such clause in the CDDL.
Another is the EPL’s secondary license provision, which is not part of the CDDL. The secondary license allows code licensed under the EPL to be combined with code covered by an incompatible license — specifically GPL v2 or later. So, code licensed under EPL with a GPL v2 Secondary License could be combined with code licensed under GPL v2 and then distributed as a combined program under GPL v2.
The Present and Future of the CDDL
The Open Source Initiative lists the CDDL as one of eight particularly popular and/or well-supported licenses. But the CDDL isn’t used nearly as often as other licenses on that list (such as the MIT or GPL Licenses).
Still, some large open source projects do use it, including the Papayra Server, OpenDJ, OpenZFS, and illumos. And, certainly, one potential benefit of licensing an open source project under the CDDL is its “effect of new versions clause.” This helps open source creators guard against the possibility that the future version of an open source license has markedly different terms than a previous one.