Understanding "License Must Not Be Specific to a Product" OSS Guidelines

Question

The copy reads:

The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

When I read this it makes me think that a developer cannot release the same code under two different licenses, for example, have the code in GPL while also releasing a "commercial version" under a commercial license.

I have googled this and saw that it's fine to do. But even after reading the annotated version of the points (which was unhelpful for this point) I don't quite get it.

Here's a piece of software which has both an AGPL license and commercial license: https://www.plupload.com/license/oem

Answer 1

When I read this it makes me think that a developer cannot release the same code under two different licenses, for example, have the code in GPL while also releasing a "commercial version" under a commercial license.

The problem is that you are reading the Open Source Definition as constraining the behavior of developers. It does not. Rather, it constrains the behavior of licenses.

This term requires that open source licenses permit users to modify the packaging of any software distributed under those licenses. For example, if you distribute GPL'd code inside a self-extracting installer (for Windows), an end user can redistribute just the source code, or a self-contained binary (with source) that doesn't need installation. The GPL permits this, which is a requirement of the Open Source Definition.

No part of the OSD restricts your decision to offer multiple licenses, nor does it have anything to do with commercial licenses. Commercial licenses (generally speaking) are not open source, so they never claimed to comply with the OSD in the first place.

Answer 2

This guideline is aimed at things like bloatware installers. Suppose I make two open-source products, xginx and Flapache. Flapache has really taken off and is an industry-standard tool, but xginx is languishing in the backwaters of the unknown. In an effort to promote it, I might start bundling it with Flapache - if you use my installer to install Flapache, it'll install xginx too.

What this guideline says I can't do is to say "You can only have Flapache under the AGPL if you also install xginx". In other words, I can't make the Flapache license conditional on you also installing another product at the same time - a "software distribution", as the guideline says. I can promote xginx and encourage you to install it and even install it without asking (though the latter will certainly annoy people), but I can't condition the Flapache license on xginx's presence.

Answer 3

It seems you are asking about item 8 in the Open Source Definition: “License Must Not Be Specific to a Product”. There are a number of reasons why an open source license should not be product-specific (or perhaps even technology-specific).

Consider what happens if a license is specific to a product. Here is an example based on the ISC license:

Permission to use, copy, modify and/or distribute FooSoft v1.2 for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

Difficult questions:

• If I modify FooSoft v1.2, is the resulting software still covered by the license? Can I distribute my not-FooSoft version? The license as written only allows me to distribute FooSoft v1.2.

• In particular, am I free to remove parts of FooSoft v1.2 that I do not want? Or is FooSoft an all-or-nothing bundle?

• Can I take parts of the FooSoft v1.2 code and include it into a completely different software? For example, I might want to reuse FooSoft's implementation of a file format or a protocol. But the license as written only allows me to distribute FooSoft, not necessarily a part of FooSoft, and definitively not MyCompetingSoftware v3.4.

So when a license is product-specific, this could be used to deny other people the possibility to distribute their modifications, in particular the possibility of forking the project. In such a license, the original copyright holder retains total control. That is not in the spirit of open source.

• This would also clash with OSD 9, that the license must allow derived works to be distributed under the same license.
• In cases where a copyright holder wants to protect the integrity of their software, OSD 4 may apply. E.g. the license could disallow direct modifications but may require modifications to be distributed as patches that are applied at build time, or may require the name or version number to be changed upon modification.

Truly open source licenses provide a license for the software, not for a branded product. When we are talking about the software, we can consider each part of the creative work independently.

A license that applies OSD-4 style requirements is the Artistic License. It makes a distinction between the Standard Version of the software as made available by the original author, and modified versions. One way to publish a non-standard version is to distribute it under a different name so that it does not impede use of the Standard Version on the same system. However, the Artistic License is a bit unusual and is widely avoided outside of the Perl ecosystem – the FSF even considers the original Artistic License to be so vague that it is non-free. Instead, open source projects wanting to protect their brand would simply apply for trademark protection of their name, for example consider Mozilla's enforcement of the Firefox trademark.