Non-commercial licenses

A concept in competition with the idea of copyleft is the “non-commercial” license, which attempts to restrict the use of a work for “commercial” purposes. This is a somewhat compelling argument for aesthetic works, since for aesthetic works it is much harder to develop the kind of “service and support” models that have worked so well for free software.

Many people (wrongly) think of free software products as being “non-commercial” because you can’t (or can’t profitably) sell individual copies of the software. However, there are many other ways of using software “commercially” (such as providing support for it, using it as a promotional, delivering advertising with it, and so on). A “non-commercial” clause forbids them all.

Ironically, the only really rational use for a “non-commercial” license is when you want to operate commercially. If you are in the business of selling your work for commercial use, you can partially protect your monopoly, while still taking advantage of the fluid distribution and marketing provided by free internet file-sharing. However, the work never really enters the “commons” of free-licensed work unless you re-release it under a “free” license later (or until the copyright runs out, which takes practically forever under today’s copyright laws).

So, while they may have other uses, for commons-based projects, “non-commercial” licenses are a dead end.

Copyleft conflicts

It is extremely difficult to write a license which insists only that the intent of the licensing on derivatives is the same. It’s much simpler and much more enforceable to require derivatives to be under the same license terms.

Even if you could interpret the copyleft as requiring only the same basic conditions, this will still invariably create obstacles. For example, the GPL insists that no “legal venue” be specified, but some free licenses, like the original Python license insisted (as do many proprietary licenses) that court cases be held in a particular jurisdiction. As a result, the Python license was “GPL incompatible”, even though it was otherwise “free”, according to the Free Software Definition.

Because copyleft licenses can conflict with each other, it’s not good to have a lot of them. Over two-thirds of the projects on Sourceforge are simply licensed under the one “best practice” free software license: the GNU General Public License. Over 92% are “GPL compatible”, meaning that derivatives based on them may be released under the GPL

As a result, copyleft licenses are subject to incompatibilities which can make it impossible to publish a fusion between two packages with different free/copyleft licenses. Since this is obviously undesirable, there is a strong pressure in the community to stick with a very few copyleft licenses—the main one for software being the GPL—thus avoiding problems with “license proliferation” as it is called.

Note however, that proliferation is a much bigger problem for copyleft licenses than it is for non-copyleft licenses. This is why there is relatively little concern over the large number of non-copyleft licenses (such as the BSD, MIT, and Apache licenses). These licenses can be combined into derivatives, and will even allow conversion to GPL, so they do not really interfere with user freedoms in the software. They still make the licensing more complex to read and understand, which is why (even for non-copyleft licensing) there are recommendations not to use so-called “vanity” licenses when one of the standard licenses will do.

Upgrade and compatibility clauses

One way to reduce problems with “license proliferation” is to provide a more flexible “upgrade” or “compatibility” clause. For example, some licenses simply have a clause explicitly allowing them to be converted to GPL licensing (overriding any otherwise conflicting terms). The Creative Commons started introducing a mechanism for forming cross-licensing agreements with its version 3.0 licenses. Upgrade clauses provide a mechanism for migrating from older versions of licenses to newer ones, so that old licensing problems can be fixed by new licenses (the GPL does this through a suggested voluntary statement in the license grant, while the Creative Commons license provide such a clause in the body of the license itself).

Critics argue that such agreements would gradually erode the copyleft, leaving the works effectively little better off than if they were released under a non-copyleft license. However, if you’re going to use another license, it’s a very good idea to assure compatibility with the GPL (for software) or the Creative Commons By-SA license (for aesthetic works).

The problem with hardware

Hardware licensing presents another special problem, since hardware manufacturing processes are generally not subject to copyright or copyright-like protection (with a few exceptions). This means that hardware designs are in the position that software source code would be if there were no copyright protection for executable binaries (the linked article explores this analogy). Thus, it’s apparent that an open hardware copyleft will probably require stronger rules in order to be effective.

Some hardware projects today use the GPL or BSD licenses, but it is likely that a strong copyleft license for hardware will emerge as an evolution of specific licenses like the

When not to use a copyleft

There are obviously some negative effects to using a copyleft. Despite “Freedom Zero”, there are a number of permitted limits to uses of copylefted software, and occasionally they get in the way. If you are interested in supporting commercial proprietary software development, or simply don’t want the hassle of license compatibility issues, then a non-copyleft license may be more desirable.

Freedom, copyleft, and the commons

With proprietary projects, what matters is who owns an intellectual work. This is because such projects operate on a permissions basis, and so what you have to know is who to ask for permission. The overhead of managing this “permissions culture” is enormous. Our society, indeed, is practically being crushed by its costs. The most visible costs (such as lawsuits) are bad enough, but the worst damage happens when people simply give up and assume they can’t get permission. It is this “chilling effect” that is most damaging to innovation in society, and the removal of that burden is the source of the success of the commons-based production movement.

With commons-based production, then, what matters is not who owns the work, but what freedoms you already have in the work. Thus, the nature of the public license granted in the work is of paramount importance. So, don’t pick a bad one and don’t write your own! At least not until you have reviewed all of the existing popular free software, free content, and open hardware licenses, and still can’t find one that works.

The best and simplest choice is to simply use the GNU General Public License. It is quite versatile, and will work for many kinds of utilitarian works such as software or logic designs. You’re in good company if you do this, as this is what about four out of five software developers will do.

If the work is not software, you may be looking at a more complicated choice. A good bet here is to stick with the Creative Commons Attribution or Creative Commons Attribution-ShareAlike license, unless there is a clear and unambiguous definition of “source code” for the work you want to copyleft.

About four times out of five, though, free software programmers pick a copyleft license. And given the success of free software, that is probably the best recommendation for commons-based production.

PREVIOUS

Source: http://www.freesoftwaremagazine.com/books/mihrfc/rule_1_hold_on_loosely