Hydra project

There are three primary drivers for asking for CLA's:

1. it helps protect the project (and all its users) against copyright infringement lawsuits; with a CLA on file, we will be in a better position to defend against any claims that the Hydra code in question wasn't intended to be distributed as OSS. This is the primary reason that Apache and others require CLAs of contributors.

2. it helps protect contributors, by ensuring an explicit understanding of the nature of and intent of any contributions to the project. If a contributor (or his/her employer) hadn't fully considered the rights and implications of including their software in the project, the CLA makes the license as clear as possible.

3. it enables the project to relicense the software at future points; if/when Apache 3.0 were to emerge as a license, e.g., the project could reissue the entire codebase under the new license without having to contact each individual copyright holder and ask for permission (an untenable position for a code base as diverse and widespread as Hydra's). This is actually somewhat common, and something that many long-lived and successful projects have had to face in the changing legal environment.

It's important to note that it's possible to sign a CLA and be a code contributor without becoming an official Hydra Partner. So yes, while it will definitely add some overhead, we feel like it's an important step in laying a solid foundation for defensible and long-term use of a cohesively-licensed code base.

Google

one of the reasons that Google chooses the Apache License (2.0) as the default for the software it open-sources. It is permissive like BSD, but (unlike BSD) actually happens to mention the rights under copyright law and gives you a license under those rights. In other words, it actually knows what it is doing unlike some of the other permissive licenses.

Licensing of Contributions

Any third-party libraries (e.g. JARs / Maven Dependencies) required to compile or run DSpace must be included. The license of any required jar/dependency MUST be compatible with BSD. It must not prevent any commercial use of DSpace, nor have any impact on the rest of the code by its inclusion. It is not acceptable to require additional downloads of JARs/dependencies to make DSpace compile or function.

Non-Java third-party web frameworks or tools (e.g. XSLT, CSS, Images) should follow these same licensing guidelines.

Examples of acceptable licenses:

  Apache License 2.0
  BSD
  Common Development and Distribution License (CDDL)
  Common Public License (CPL)
  GNU Library or "Lesser" General Public License (LGPL)
  MIT / X11 License
  Mozilla Public License
  Additional examples may be found in our LICENSES_THIRD_PARTY file in the source code. This file lists the licenses of all third-party libraries used by DSpace.

Examples of unacceptable licenses:

  GNU General Public License (GPL)
  GNU Affero General Public License (AGPL)
  European Union Public Licence (EUPL)
      Similar to GPL, this license is "share alike" / "strong copyleft" and may require usage of the same license for redistribution or derivatives. For more information, see the EUPL FAQ (specifically the questions "What about compatibility issues?" and "Are there limitations to the use of the software?")
  Any license which strictly forbids "sublicensing" as detailed at http://choosealicense.com/licenses/
  Any license which limits commercial use/redistribution of binary code

Why is GPL (and similar) unacceptable? Icon

DuraSpace feels it is important for commercial entities and service providers to be able to customize the entire codebase and redistribute/repackage/sell it in a binary form. GPL licenses prevent this, as noted in the following FAQ questions:

  Can I release a modified version of a GPL-covered program in binary form only?
  If I distribute GPL'd software for a fee, am I required to also make it available to the public without a charge?

In addition, the Apache Software Foundation has a good explanation of why they are also forced to avoid GPL-based (copyleft) licenses because of its one-way compatibility with Apache License 2.0:

“This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3.

We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3.”

While DSpace is released under BSD licensing, the same issues exist between BSD licenses and GPL-based licenses.

JDBC drivers for databases are an exception since:

  They must correspond to the database version and not the DSpace version.
  They are not required for DSpace to compile and run; a variety of databases, including open source databases, may be used.