While members of the open source community often bristle at the mention of yet another license, many people have welcomed this one. The EUPL is unique in its encouragement of interoperability, freedom, and lack of license lock-in upon redistribution. By making specific distinctions, it represents a divergence from the typical freedoms afforded by whatever the latest iteration of the GPL may be.

As noted in the Wikipedia entry for the EUPL, the EU had some specific goals in mind when drafting this license:

“With license proliferation a growing problem, the European Union justifies its license as the first open source license to be released by an international governing body. The European Union also wishes to dispel legal uncertainties, real or perceived, in respect of other open-source licenses, such as the GNU General Public License, by creating a software license which takes due account of European Union Law. A third goal of this license is to create an open-source license available into 22 official languages of the European Union, and is sure to conform to the existing copyright laws of each of the 27 Member States of the European Union. Lastly, to dispel fears of license proliferation, the license was developed with other open-source licenses in mind and specifically authorizes covered works to be re-released under the following licenses: GNU General Public License (GPL) v. 2; Open Software License (OSL) v. 2.1, v. 3.0; Common Public License v. 1.0; Eclipse Public License v. 1.0; CeCILL v. 2.0.”

At the same time, the EUPL tries to take a more international view on the enforceability of an agreement that requires oversight in many jurisdictions. Licenses originating in the United States are derivatives of US copyright law, so as far as they’re concerned international considerations are non-existent. While translations of existing FSF licenses are informative and referential, the US English employed is the only contract language.

Why Should You Care?

Both the EUPL and the GPL v3 are copyleft licenses, so some of you may be wondering whether there are any significant differences between them. Choosing the correct license could be as simple as using the GPL v3 if the software is originated in the US, and the EUPL v1.1 if the software is from Europe. Who really cares?

We do, and here’s why: the EUPL v1.1 is conspicuously missing something that could be fairly significant depending upon which side of the Atlantic you happen to live and work. The GPL v3 is not included in the EUPL’s list of “compatible licenses” under which subsequent works can be re-released — a provision included in the EUPL in order to help fight license proliferation. We agree that license proliferation is a growing problem with open source licenses, but why did the EU specifically exclude the GPL v3 from the list?

One explanation for the EUPL’s purposeful incompatibility with the GPL v3 might involve freedom, and what it means to open source licenses. As copyleft licenses, the aim of both the EUPL v1.1 and the GPL v3 is to free the code from proprietary copyright laws. However, the freedoms provided by the GPL v3 may be limited to the US, and so may not be “free” enough for the global community. For example, is it truly freedom if you’re protected from intellectual property claims, but then forced to use a specific license — one not of your own choosing — to distribute your original work? This may be one of the problems that the EU has with the GPL v3. Once a work is created under the GPL v3, all subsequent works will be licensed under it as well. In contrast, works licensed under the EUPL v1.1 can be re-licensed under any of the different licenses on their compatibility list. Perhaps the EU does not want software created under the EUPL v1.1 to be trapped within the confines of the GPL v3 later.

Here’s something else to consider. The GPL was originally derived from US copyright law, which creates a license bias toward issues unique to the United States. It may very well be that the FSF created their license to be specific to the US software community, but that distances it from the global community. There’s a large world of software developers and users outside of the US, and their concerns are different those of US-based developers and users. It makes sense that they want a license that addresses those differences. Many OSI-approved licenses (including but not limited to the GPL v3) do not address a global audience, and it’s a fair assumption that current efforts like the EUPL are just a hint of what is to come in global or regional licensing outside the US.

By excluding the GPL v3 from compatibility with the EUPL, the European Commission is indirectly pushing out the FSF as a presence in open source licenses in Europe. The GPL v3 is the FSF’s license for the 21st century, and it is now incompatible with what may very well become the predominant license in the EU. As the first license to be released by an international governing body, the EUPL has the potential to become widespread not only in Europe but worldwide. The 22 different languages in which the EUPL v1.1 is released also increase the likelihood that usage will spread quite quickly. Given these circumstances, we think it’s pretty significant that the GPL v3 cannot be merged with any code under the EUPL v1.1.

The Players

EUPL v1.1 and the European Union

The European Union Public License (EUPL) v1.1 was released on January 9, 2009. This license was created by the European Commission, the executive branch of the European Union, and is available in all 22 languages of the EU. The European Union, for those who do not know already, is a union of 27 European countries (called Member States) that was established on November 1, 1993. These Member States joined together for various economic and political reasons. Primarily, the partnership allows for easier commerce and trade among the different countries. The creation of the EUPL is another step in unifying and standardizing the products — in this case software products — that are used within the European Union.

By creating a license in multiple languages, with equal validity for all linguistic versions, the EU has created a framework within which future open source projects in the European Union can work. It’s also worth noting that the EUPL is the first license to be released by an international governing body. The original version (EUPL v1.0) was created on January 9, 2007 and its provisions still account for most of the license. Only seven modifications were made to the original license, and these were included primarily for purposes of clarification. The main revisions in the 2009 version of the EUPL allow for other linguistic versions of the license to be created by the European Union, giving it worldwide distribution potential.

GPL v3 and the Free Software Foundation

The GNU General Public License (GPL) v3 was released on June 29, 2007. It was created by the Free Software Foundation (FSF), which is headed by Richard Stallman. The FSF, which was founded on October 4, 1985, is a US-based, non-profit corporation that promotes the free software movement — an ideology that combats US copyright law to allow for modification and redistribution of software code without restriction. According to Richard Stallman: “The free software movement is not merely personal. It is a political movement like the environmental movement, the civil rights movement, etc.”

The original GPL license was released in January of 1989 and we’ve seen two subsequent versions since then. The GPL v3 is considerably different from the GPL v2 (which makes sense, since the GPL has been around much longer than the EUPL). In each version, the FSF attempts to maintain their values while adapting to the current technological situation. The main revisions and concerns in the GPL v3 involve modern topics such as time-shifting restrictions, Digital Millennium Copyright Act (DCMA) specifics, and “tivoization”.

The Differences – An Overview

The primary differences between the EUPL v1.1 and the GPL v3 can be summarized in the following points:

• An EU commission created the EUPL license to be enforceable in the native languages of all the member countries.
• The EUPL’s defined compatibility with other licenses avoids certain downstream licensing conditions.
• The EUPL is purposely incompatible with the GPL v3, although it does allow under certain conditions re-licensing under CeCILL v. 2.0, which is GPL v.3 compatible.
• The EUPL does not contain language on time-shifting restrictions or DCMA-specific language, and it doesn’t address issues of tivoization.
  • Time-shifting is the recording of programming to a storage medium to be viewed or listened to at a time more convenient to the consumer. Typically, this refers to TV programming but can also refer to radio shows via podcasts.
  • The Digital Millennium Copyright Act (DMCA) is a United States copyright law that implements two 1996 treaties of the World Intellectual Property Organization (WIPO). It criminalizes the production and dissemination of technology, devices, or services intended to circumvent measures (commonly known as Digital Rights Management or DRM) that control access to copyrighted works. It also criminalizes the act of circumventing an access control, whether or not there is actual infringement of copyright itself.
  • Tivoization is the creation of a system that incorporates software under the terms of a copyleft software license, but uses hardware to prevent users from running modified versions of the software on that hardware.
• The EU’s license contains none of the GPL’s explicit (and US-biased) patent language.
• The EUPL doesn’t enforce a time limit (like 3 years) for the required distribution of source code — it’s more open-ended. As long as the program is being distributed, the source code will be available.
• The EUPL appears to be simple, clear, and less restrictive than the GPL v3 license. It reads more like the Apache license than the GPL v3. It’s simply formatted, with 15 explicit sections that say what needs to be said, and it contains little apparent excess.

Compatible Licenses

According to article 5 of the EUPL, the “compatible licenses” are:

• GNU General Public License (GNU GPL) v. 2
• Open Software License (OSL) v. 2.1, v. 3.0
• Common Public License v. 1.0
• Eclipse Public License v. 1.0
• Cecill v. 2.0

Summary

Original work, licensing for redistribution, and freedom are concepts that have legal and financial ramifications throughout the world. With the ever-increasing popularity of open source software and the need to protect such works and their associated freedoms, many open source licenses need to evolve in order to address global — or, as in the case of the EUPL, regional — concerns. The EUPL seems to have adapted to this open source climate and has the potential to challenge the GPL by differentiating on a few important key points:

• Some people feel that the FSF is too political, and regional users clearly feel that the organization is overly focused on the United States.
• The EUPL stands up to what some view as prohibitive and confusing constraints of the GPL licenses. Here is a license that appears more friendly to the intention of software openness, without the many constraints (patent, tivioization, US jurisdiction, etc.) that can make licenses too localized, and thus difficult to embrace and support on a broad scale.
• Lastly, in the EUPL there is no mention at all of money or freedom. Freedom means never having to be told you are free.

The EUPL v1.1 is a legal instrument, simple and clear to interpret, with less baggage than the GPL v3, and with the intent to enforce locally while inter-operating with certain key licenses. As the world increasingly sees the value of transparency in code development, it can be argued that licensing needs to be less about a “movement” and more about the proper identification of rights, restrictions, and obligations for use of third party software.

This brings to the forefront concerns about the complexity of open source licensing, and a need for much more clarity. Perhaps the community needs global license templates that can be used across borders, that will span language and continental gaps while still allowing local enforcement and understanding. The EUPL certainly makes an effort to localize the rules surrounding the freedoms of the use of original work, but we need to go further.

The use of open source software components is a simple idea. Software use is governed by just a few things:

• Use: personal, redistribution, modification and redistribution, and contribution to the core project.
• Requirements: maintenance of copyright notice, attribution, indemnification, license-free use of original and included third party work, and availability of source code (not always mandatory, depending on the license).
• Restrictions: regional, limitations of liability, legal jurisdiction, and time limits.

That’s it. While there are more clauses, and more complex ways to describe it, there are only so many ways that software can be used; the Apache license distinctly describes four, and the GPL v2 does not even reference personal use. It seems that software licensing needs to be simplified into a “representative language” that spans the globe, is legally enforceable, and is clear.

A big distinction here is that usually, when we talk about license proliferation, the discussion focuses on yet another derivation of US copyright law in the form of another license written and enforceable only in the US English language. Open source licensing needs to surpass the US English language barrier and address a global audience of users. Real freedom will happen when original works can be shared, with constraints and conditions, in a way that can be understood by users and enforced by courts in all parts of the world. For the global future of open source software, fewer licenses are better, but one license best.

The EUPL shows that by using compatible licenses, a simple message can be communicated, a broader scope of freedoms can be encouraged, and developers can be provided an “out”. It’s our guess that more OSI-approved licenses will eventually evolve to include a compatibility clause like that in the EUPL v1.1, which allows developers to take their code and get away from the current license if they’re unhappy with the way things are going. It remains to be seen if the FSF will embrace this degree of freedom in the future.

Is freedom just another word? No, freedom is choice. And while licensing choice is baked into the EUPL v1.1, it’s not currently afforded to developers modifying GPL v2 and GPL v3 licensed software.

References and Credits

Licenses

EUPL 1.1 — http://ec.europa.eu/idabc/eupl
GPL v3 — http://www.gnu.org/licenses/gpl-3.0.html

Software patents

http://gpl3.blogspot.com/2008/08/gpl-project-watch-list-for-week-of-0822.html

US Copyright

http://gpl3.blogspot.com/2008/06/gpl-project-watch-list-for-week-of-0613.html

Jacobsen: Copyright Case

http://gpl3.blogspot.com/2008/10/gpl-project-watch-list-for-week-of-1010.html
http://gpl3.blogspot.com/2008/01/gpl-project-watch-list-for-week-of-0125.html

The Research Group

The Research Group collects and manages data regarding software policy management, open source licenses, and global software vulnerability management issues. Data and references for this article were researched by Ernest Park and Antony Tran. The Research Group actively takes submissions regarding stories, FOSS issues, and project announcements, and we are grateful to the hundreds of core contributors who have devoted their time and resources at helping us provide up-to-date information. The Research Group has hosted over 80 interns in the last year from the leading schools in the United States. To submit stories and announcements, receive more information on products, or inquire about internships, please write to rdgroup@airius.com.

The three tables below compare the licenses on these general, and commonly considered, points, in increasing detail:

• Author
• Date published
• OSI Approved
• GPL Compatible
• Copyleft

For those of you new to licensing, some definitions:

GPL Compatible licenses allow the combination of the code covered by them with programs that use the GPL without conflict.  Some free/open source software licenses are not GPL-compatible which means they impose conditions not in keeping with the GPL.

Copyleft licenses – of which the GPL is the most commonly used – require any work originating in the licensed code to be made available under terms identical to that specified by the license that applies to the originating code.

Comparing Licenses One to Another

Here’s a pdf of the highest level comparison…

A little more detail…

And the most detail yet…

If you’d like, you can download the entire license matrix in either Microsoft Excel (XLS) or OpenDocument Spreadsheet (ODS) format.

OpenLogic’s researchers work diligently to confirm the accuracy of licenses for the open source projects included in the OpenLogic Certified Library. They follow a process carefully crafted from many years experience, refined and sauced liberally with intuition, creativity and not-a-little tenacious detective work. As they’d be the first to tell you, this work is not for weenies and is best left to the professionals. However, if you insist on trying your hand, there are a few tricks they’re willing to share.

Where to look

About half the time, getting an initial sense of the licensing of an open source project is as simple as navigating to the project’s home page, and taking a gander at the menu options scrolled variously down the left or across the top. Much of the time, if  ‘License’ is one of them, you can follow the link and, voila: license text.

Even this simplest case, though, is not always as simple as it seems. Our legal department issued the edict that ‘distribution is King’ which means that, regardless of what the Web site claims, the license found in the distribution is the license the project is released under. To be certain you’re using the correct license, you always want to locate and download the distribution to determine a match. Later in this article, we talk about typical filenames given to license files, and where in the distribution they’re most often found.

Projects that use a hosting site such as SourceForge will have a summary page that lists basic project information. This information typically includes the license. AcegiSecurity, for instance. Their Web site (www.acegisecurity.org) does not appear to include a link to the license information. But, notice in the upper right hand corner the link to Acegi on SourceForge:

A couple more clicks, and you’ve arrived at Acegi’s summary page which reports the license as Apache 2.0. In this case, this information is correct, however, sometimes the SourceForge information is out-of-date.  If the project you’re researching will be modified and included in work for sale, you should confirm the license by checking the distribution.

If none of these paths result in license information, check the project documentation for a FAQ, for instance, the Mozilla License FAQ. If there is one, it will often have an intuitively titled entry covering license terms. If there’s no FAQ, search for ‘license’ first on the home page, and then by using the site’s search function if there is one. If none of this turns up information, follow with a general Google search (project name + version + ‘license’)  and often the appropriate page on the project site will appear in the results.

Why you shouldn’t stop there

We mentioned quickly the possibility of downloading the distribution and confirming the licensing of a project by exploring it. You might think that, given all of this, downloading the distribution first would be the most reasonable approach. This is risky for a couple of reasons.  In many instances the Web site and the distribution will conflict for one reason or another. While legal says the ‘distro is king’, there are situations in which a conflict between the two licenses could cause problems. If, for example, the distribution contained a permissive license like Apache 2.0, but the Web site included text that indicated commercial use of their work required the Gnu Public License (GPL) and they hadn’t included a FLOSS Exception like MySQL.

Additionally, some enterprises restrict the download of distributions based on licenses like the Gnu Public License (GPL). As an engineer or manager researching the licensing issues around using a certain project, you’ve got a textbook chicken/egg situation: in order to be certain on the license, you need a peek at the distro, in order to get access to the distro, you need to know if the license is safe.

What you’ll find

If you’re a developer of more than a little experience, you won’t be surprised at the range of organizational strategies at work inside the distributions. The rest of us have experienced symptoms such as cold sweats and dizziness and, in one instance, actually fainting dead away when faced with Yet Another variation on the theme. You can pad the room and go on alone, or you can make use of some of these set ups our researchers have seen.

Sometimes you’ll find the license information at the top level and sometimes you’ll have to dig. Some of the locations we have found license files:

• Licenses directory
• Copying directory
• Legal directory
• Docs directory
• Lib directory
• Project-name directory
• License-name directory

Some of the file names that may contain license information:

• License.txt
• Copying.txt
• Legal.txt
• Readme.txt
• Copyright.txt
• Notices.txt
• Specific License Name.txt

What you should do with what you find & how

So, say the Web site and the distribution of the project you’re interested in using both claim that the project uses Apache Software License version 1.1? Now you’ll need to eyeball the text and make sure that, in fact, they are the same license. It is not uncommon for projects to modify standard licenses to include custom text. Here, again, the Web site version and the distro version might differ. More likely, though, the Web site and distro will match, but the license will deviate from the standard version of the license. For examples of the standards, see the Open Source Initiative site and the Free Software Foundation.

For short and relatively uncomplicated licenses such as BSD and MIT, an eyeballing to make sure that the licenses match the standard is probably good enough. But, for more complex licenses like the MPL, you’ll want to use a ‘diff tool’ like KDiff to compare the text a project uses against the standard.

Other tools OpenLogic researchers leverage include Fossology and OhCount.

Other tidbits

You’ll also want to make sure to read carefully any text on the license page of the project Web site that specifies the versions of the project to which a particular license or license version applies.

And, finally

OpenLogic researchers perform all of this analysis, and more, on every version of every project in the Certified Library. We’re happy to do the heavy lifting on research, but if you’ve got access to a legal team, you should run what we’ve found by them, too. We rely heavily on our legal team to interpret anything remotely questionable. Look for ‘Special Notes’ on any package that qualifies as such.

3GPP is a partnership of telecommunications-related organizations designed to create “evolved Third Generation and beyond Mobile System specifications”. So, in other words, it’s an effort to develop certain specifications relating to 3G mobile communications.  The 3GPP AMR Speech Codec Library is a suite of tests for verifying that an implementation complies with the relevant specification.

License Issue

3GPP AMR Speech Codec Library was requested by an OpenLogic customer. Specifications can be a challenge because often times a specification itself is not open source but a reference implementation is, or vice-versa. During the certification process, OpenLogic could find no open source license or statements as to whether the project was open source, though a statement was found indicating that the specification is free for commercial use. The information included on the project website around legal issues was confusing and of limited use. Additionally, an unusual proprietary license was included with the technical specification, but not with the source code.

This combination of circumstances made it difficult if not impossible to determine the actual licensing terms of the package. Our analysis determined that although it was free and the source was available, the licensing terms were not consistent with OpenLogic’s definition of open source software. Normally, the certification effort might end here, but since this package was specifically requested by a customer, we escalated the issue to our legal staff.

Resolution

The OpenLogic legal team returned the following assessment:

• Neither the codec nor the specification appear to be released under any sort of open source license (or anything resembling an open source license).  The terms under which they have been released are in question.
• The actual origin of the codec also appears to be in question.  While it may have come from the efforts of the 3GPP or one or more of its members, under what agreements(s) they were created and what rights have been granted by the authors is not clear.

Even after legal review, OpenLogic was still uncertain as to the origin, ownership and license terms of this project, though legal did confirm that it is not open source. We contacted the project community to request permission to distribute the specification in one customer’s private library on a case-by-case basis and permission was denied.  We informed the customer, which was able to update designs in order to avoid the use of this package.

Cobertura is a free Java tool that calculates the percentage of code accessed by tests. It is based on jcoverage. Some of its main features include:

• Executable from Ant or from the command line.
• Instruments byte code after compilation.
• Generates reports in both HTML and XML.
• Shows the percentage of lines and branches covered for each class, each package, and for the project.
• Shows the McCage cyclomatic code complexity for each class, the average code complexity for each packet, and the average cyclomatic code complexity for the project.
• Provides sorting of HTML results by class name, percentage of lines covered, and more.

Use Cobertura to identify which parts of a Java code base are lacking test coverage.

License Issue

This project is dual licensed under the Apache 1.1 and GPL V2 licenses.

The Ant tasks are licensed under the Apache 1.1 license. Because the Ant tasks are loaded directly into the runtime of Ant, and the GPL is incompatible with all versions of the Apache license, Ant tasks can’t be licensed under the GPL.

The rest of Cobertura is under the GPL because Cobertura is a fork of the GPL version of JCoverage. The terms of the GPL require that forks – or any other project based on a GPL licensed project – also use the GPL license.

Additionally, because use of Cobertura modifies JCoverage code, there are other license implications.

Resolution

We added a special note to the Cobertura package details page in OLEX explaining the situation and pointing users directly to all of the relevant information available on the community website.

gSOAP eases the development of SOAP and XML Web services in C and C++ by performing XML to C/C++ language binding. By providing a transparent SOAP API that leverages strong typing to map XML schemas to C/C++ definitions, it frees users from the burden of WSDL and SOAP details.

Use gSOAP to implement or interact with web services. It is portable across a variety of platforms, and provides compiler tools for a WSDL parser, and a SOAP stub and skeleton compiler. It follows the WS-I Basic Profile 1.0a compliance recommendations, and warns about potential interoperability issues before building a new web service application. This helps to keep users from having to go through another development cycle to make the service compliant. Its supported standards include:

• SOAP 1.2
• SOAP RPC encoding
• SOAP document/literal style
• XML-RPC
• UDDI v2 inquire and publish APIs
• SOAP attachments: MIME, DIME and MTOM
• WS-Addressing
• WS-Discovery
• WS-Security
• SSL/TLS encryption and certificate authentication

License Issue

gSOAP is distributed under several licenses:

• The GNU General Public License
• The gSOAP Public License 1.3, which is based on the Mozilla Public License 1.1
• The gSOAP Commercial License

The community made no clear statements regarding the choice to multi-license the project.  Further, the relationship between the licenses was unclear. Following the OpenLogic certification process, we were able to provide customers with the following guidelines:

• The software is offered under the GPL to enable it to be used with open source projects, and requires all software development to be open-sourced under the GPL or a GPL-compatible license.
• The gSOAP Public License allows commercial and non-commercial use of gSOAP without fees or royalties. It can have products built on top and distributed under any license, including proprietary, as long as a notice of copyright and disclaimer of warranty is in the product’s documentation.
• The gSOAP Commercial License is for use with the wsdl2h WSDL parser, UDDI code, and sample applications which are only licensed under the GPL or the gSOAP Commercial License. Any use of the listed tools or source code for proprietary product development requires the gSOAP Commercial License.

Resolution

Multi-licensed projects are a common source of confusion for users of open source software. In this instance, OpenLogic was able to clarify the intent and obligations of the three unique licensing options.  As a service to our customers and the community at-large, we’ve added an entry to the OLEX knowledge base which explains the licensing of gSOAP in detail.  Perhaps as a result of our input and inquiries, the project has also updated their Web site to explain the license situation more clearly.

The Jacl project provides a self-contained implementation of a Tcl (Tool Command Language) interpreter. It also facilitates communication between Java and Tcl interpreters.

Jacl can be used to add scripting functionality to an existing Java application, or to take advantage of Java methods from Tcl procedures. An alternative to Jacl is Tcl Blend, which provides similar functionality in a Tcl extension.

License Issue

During the certification process for Jacl 1.4.1 in May 2008, OpenLogic discovered that versions of Jacl previous to 1.4 were licensed under a proprietary copyright statement. This statement is included as a text file in the distribution as the “Jacl License”. The project website offered no additional information on the license. Examining the contents of additional distributions, OpenLogic found the copyright statement mentioned on the website and in the original distribution, and researchers also found a Sun license. The Sun license had no name or title, but launched immediately into terms and conditions.

Using text comparison tools, OpenLogic researchers determined this Sun license was not one previously encountered. A close read of the license text revealed the following potentially restrictive clause regarding development: “[use is] expressly subject to Sun’s continuing ownership of the Software”. According to OpenLogic’s definitions, a true open source license contains no restrictions, and thus an evaluation of a license that results in ‘potentially restrictive’ text is reason enough for a project to fail OpenLogic’s certification process. But there were two additional red flags:

1. There are only two OSI-approved Sun open source licenses, and this license was not similar to either.
2. Sun is a commercial entity.

The OpenLogic certification team searched Google with chunks of the license text looking for a match and scoured Sun’s pages, but had no luck turning up the exact license text in any other location. An ordinary project would have failed certification at this point, but OpenLogic determined to take the research a bit further because Jacl 1.4.1 was a specific customer request.

Returning to the distribution, OpenLogic’s researchers scoured the directories for additional clues and found a file that included the following text: “Jacl 1.0 was released by the now defunct SunScript group at Sun Labs. Newer versions of Jacl have been developed by…” and following this text was a list of the project developers. This answered some of the questions about the genesis of the license, and Sun’s history with the project and researchers contacted the project developers.

Discussion with the developers clarified a number of points regarding the relationship between the licenses and, most importantly, OpenLogic was assured that lawyers from Sun, AMD and IBM — all with an interest in the project at various junctures via staff involvement — had reviewed the licensing and found it adequate.

Resolution

Satisfied that the project was indeed open source, OpenLogic kept the copyright notice and added the Sun license under the name Sun Microsystems Laboratories License. This combination was called the Jacl Software License. A note on the Jacl knowledgebase entry within OLEX explains the situation as follows:

“Originally developed by Sun Microsystems in conjunction with developers affiliated with the University of California, Berkeley, Jacl uses both the Sun Microsystems Laboratories license, and a copyright, permission statement and warranty disclaimer added by the University. OpenLogic refers to this combination as the ‘Jacl Software License’.”