Licensing and FOSS Guidelines

From EGEE-see WIki

Jump to: navigation, search

Contents

About Free and Open Source Software

Those interested in wider social aspects of open source and licensing issues may wish to read two great essays:

For the readers interested in economical aspects of the issue, the impact analysis of FLOSS in Europe is available here.

FOSS Licenses

The most frequently used software licenses, ordered by growing restrictiveness (i.e. growing enforcing of open source), are:

  • BSD (several versions) - users can do whatever they want, but if redistributing source or binary, they must retain the copyright notice. Also endorsing or promotion of derived products usually requires prior written permission
  • Apache Public License 2.0 - also BSD-style but often used
  • GNU LGPL - use of the product as a library allowed for non-GPL applications, but changes must remain LGPL
  • GNU GPL - requires even usages and changes to use GPL

A brief comparison of GPL, LGPL an BSD is here.

There is also a more comprehensive List of OSI (Open Source Initiative) approved licenses].

While applying of GNU licenses for your own software and using of components with GNU licenses are discussed in the next two sections, some common aspects of these topics are detailed in A Practical Guide to GPL Compliance.

Applying FOSS Licenses on Your Software

GNU LGPL v2.1 and v3 are basically the same, except that v2.1 is self-contained, while v3 is a written as a simple extension of GPL with LGPL-specific relaxations. And v3 allow for using of Apache 2.0 components explained. It is also said that v3 "has the advantage of being clearer in different aspects and offering better patent protection".

The choice between GNU GPL and LGPL should be made according to anticipated needs/limitations of your users and your FLOSS agenda - LGPL is more permissive, thus allowing non-LGPL usage of libraries (only requiring preserving LGPL access to the used library), while GPL promotes open source by requiring your users to use GPL in their works as well. There were also some dilemmas regarding LGPL and Java, but they seem to be clarified (http://www.gnu.org/licenses/lgpl-java.html). Anyway, use older versions of GPL and LGPL only if required by used components, but then please explicitly allow users to choose "any (or explicitly named) later version" of the (L)GPL to facilitate compatibility in combining components.

The application of GNU licenses is described in the link below, but make sure not to miss already mentioned Practical Guide to GPL Compliance

You can also provide your software with several licenses. You can choose dual-licensing, i.e. offer users of your software a choice among several mutually exclusive licenses (usually GPL and proprietary):

Here are some recommendations based on the above details:

  1. Find candidate licenses compatible with licenses of the components that you are using.
  2. If you want do combine software with some other development of yours that already has some FLOSS license, use the same license for both products.
  3. If you still have several choices at this point, if you strongly want to promote (read enforce) open source, use GPL v3. Have in mind that this is a bold political statement that may affect applicability of your software. Otherwise opt for more permissive LGPL v3 or even fully permissive Apache 2.0 or some BSD variant.
    1. Using (L)GPL can limit code reusability in commercial environment. Many users would rather use a library with permissive Apache license in their commercial software than one with LGPL, which is "weak copyleft" that is requiring commercial programs to allow reverse engineering in order to debug modifications of LGPL-ed libraries. BSD and Apache are apparently more permissive to end-users.
    2. On the other hand, using (L)GPL gives better control over modifications and prevents competition with "closed" proprietary modified version of your own software. The benefits of (L)GPL for developers are described here.

Combining Other Products with Your Software

Please note that the license of your software must be compatible with licenses of all components used in your software. Please check this first while when choosing your license. Discussion on compatibility of licenses of used products is available at:

These compatibility relationships are not symmetrical - for example, Apache 2.0 licensed components can be used in GPL v3 and LGPL v3 licensed products, but not with ones that use GPL v2, while Apache 2.0 licensed products cannot use (L)GPL components.

Note that, although you are allowed to use a library with LGPL in your commercial software, you must do it in a LGPL compatible way, which also includes allowing a new version of the library to be linked with your software and permitting "reverse engineering for debugging such modifications" to the library, which should not be contradicted in the EULA.

This link can help in deciding what is a single program, linking or aggregation of separate programs, at least from GNU standpoint. Based on this, the operating system, system libraries (which are differently defined for GPL v2 and v3), non-linked databases, or services should not be treated as components of your software.

FOSSology software is Free and Open Source Software representing a system for analysis of FOSS licenses in the source of software projects and meta data extraction from documents and media files

Special MySQL Considerations

MySQL software is a well-know case of software with a dual-license. The basic orientation is provided here:

  1. If you want to use MySQL as a commercial distributor (OEM, ISV or VAR) use a commercial license, you must purchase a commercial license.
  2. Otherwise, you can use MySQL Community Edition and Community Server under GNU GPL v2.0. Your software must be compatible with this license, and you may, but do not have to, distribute MySQL with your software.
  3. If your software is FOSS (GPL v2.0 or license listed here, including BSD and LGPL, you can distribute MySQL drivers, namely Community Edition or Community Server Client Libraries, but not MySQL database.

Although the use of a database can be treated as aggregate use, your application is effectively bound to MySQL by usage of MySQL Client Libraries (MySQL Drivers", "MySQL Connectors", including i Java, .NET, ODBC, PHP i C++ connectors and drivers) and related licensing requirements (commercial, GPL v2, or those of MySQL FLOSS exception.

The usage of MySQL drivers through mediation of an application server also seems to be treated as linking and not as aggregation, even if effectively performed the means of XML configuration, annotations (or methods like lookup, Java reflection, or inheritance). These limitations cannot be averted by independent distribution of MySQL database under GPL, usage of MySQL Enterprise drivers, or by silent letting of end-user to install the MySQL database and drivers.

The usage of MySQL Enterprise drivers imposes other set of rules.

Personal tools