In the proprietary production world, what matters about a copyright is who owns it. In the free production world, however, who owns a copyright is relatively unimportant. What matters is what license it is offered under. There is a very simple rule of thumb about the best license to use: use a "free, copyleft license". Such licenses provide the ideal balance of freedom versus limitations, and projects that use them are overwhelmingly more successful than ones that don't.
RULE #1: Hold On Loosely
Use a free, non-copyleft license
A free license provides everyone working on the project parity: they have an equal stake in the project's success, reap equal value from it, and do not feel they are losing the value of what they contribute to it to anyone else.
A copyleft license prevents any single entity from stealing value from the public by taking the project private (including the work of other participants).
The most popular license for software is unquestionably the Gnu General Public License (GPL). However, that license is clearly written with computer programs in mind, so it is not really appropriate for all forms of information (this point is somewhat controversial, but there is no question that the GPL uses program-specific language in its text which may be ambiguous when applied to other works). Therefore, there are a number of other licenses, including the Creative Commons Attribution-ShareAlike (CC-By-SA) license , which is optimized for creative content. No single license has emerged as appropriate for licensing open hardware, although the GPL is often used.
The Culture of Innovation
The heritage of open source development stems largely from academia, where intellectual freedom is as fundamental an ideal as "democracy" or "freedom" is to most people throughout the industrialized West. It is this view of the concept which leads to the ideologically-based "Free Software Movement" and its preference for emphasizing user freedoms over developer process.
While this approach is probably not so good as a method of persuasion, since it relies on cultural norms that do not apply broadly across all human societies or even across professions, it has a special importance to commons-based production: it is a core belief of the people who do the most work.
Whether you share this belief system or not, you cross it at your peril. Many people regard these ideas as moral imperatives and one of the first rules of the freedom game is learning not to offend the very people who are likely to be your most important asset in success. You cannot play the game halfheartedly, hoping to create a business advantage through appropriating publicly-created work, while holding back your own.
Intellectual Freedom is a fundamental principle that underlies many of the beliefs shared by knowledge workers, particularly in academia, but also in a much broader area of complex engineering and scientific disciplines. Although it is often couched in ideological terms, the real point is that secrets are wasteful. Scientists learn from very early in their training the faults of suppressing information, perhaps most iconically in the person of Galileo Galilei, who published evidence supporting the Copernican theory that the planets orbited the Sun (primarily his observations of Jupiter's satellites), and was proscribed and forced to recant his beliefs by the Catholic Church.
Scientists learn from very early in their training the faults of suppressing information
Scientists view Galileo in heroic terms, and the Church's resistance to the Copernican theory was ultimately futile. Without the Copernican theory, we'd have never made it to the Moon. So it is fitting that Galileo's famous hammer and feather experiment was actually demonstrated by Cmdr. Dave Scott at the Apollo 15 landing site on the Moon (figure 8.1).
When scientists are free to share information and regard it as a duty, they fuel the process of science, which needs to check and recheck assumptions to reach an ever more accurate understanding of the world. Engineers and inventors also share information, so as to attain ever more refined improvements to the inventions that they develop. Software developers use this freedom to find bugs and refine their software as well as to improve upon what has been written before. All of them are using it to avoid wasting time re-inventing what has gone before.
The utilitarian argument for intellectual property is fairly simple: producing information costs time and effort of those who do the work, just as much as any other kind of production. Yet, unlike other forms of production, information can be freely copied, so, in a completely free market, the monetary value per copy of an information product tends to be very nearly zero.
Intellectual property systems make it easier to recoup the development costs of information products via artificially inflating the cost of sales to cover the initial investment. This mimics the natural behavior material products, where barriers to entry such as manufacturing tooling costs give the first entry into the market a chance to recoup its development costs so as to make a profit.
Intellectual property systems make it easier to recoup the development costs of information products via artificially inflating the cost of sales to cover the initial investment
Of course, there are problems with the Intellectual Property idea. Perhaps the most obvious is that, in the limit, it's the just like the medieval guild system that locked Europe into a dark age for nearly a thousand years!
Suppressing the flow of information damns us to repeat the same mistakes over and over again, retarding technological progress and resulting in massive wastes of human capital. Only when inventors, authors, engineers, and scientists are able to build upon each others' works can civilization reap the renaissance rewards of a booming technological and intellectually creative society. Thus, even if and when intellectual property law is needed, it must always exist in tension against the long range benefits of preserving intellectual freedom.
An Unnecessary Evil?
Most serious creators of intellectual works in the United States know about the limited constitutional basis for Intellectual Property, but they still view it as a "necessary evil": a fictive arrangement we have to adopt in order to create intellectual works within our capitalist society. The free market, they argue, demands that we respect Intellectual Property as a tradable good, so that we can profit by producing intellectual works.
At the very least, we know that a free market society can produce intellectual works without the need to resort to the restrictiveness of conventional intellectual property
The experiences of free software and free culture, however, have empirically disproved this idea. At the very least, we know that a free market society can produce intellectual works without the need to resort to the restrictiveness of conventional intellectual property. Free-licensing, which intentionally releases such works from these confines, produces more value from the free exchange of information than it loses to lost licensing sales and free rider problems.
In his essays, "The Cathedral and the Bazaar", "Homesteading the Noosphere", and "The Magic Cauldron", Eric S. Raymond illustrates the strategies that commercial entities and amateur developers have employed to defeat the conventional wisdom that locked-down "IP" is essential to business success . I highly recommend reading these essays yourself.
Why Use a Copyleft?
There is one serious problem with all this freedom. If everyone is free to do what they want with the work, then one thing they can do with it in a society which has strong intellectual property laws is to claim it for themselves, appropriating all of the effort that has gone into the project.
There is some evidence that copyleft is not so influential on users who make small contributions to projects (in that non-copyleft projects are generally as active as comparable copyleft ones , see figure 8.2). Indeed, the overall license choice has only a small effect on the activity rates for Sourceforge-hosted projects.
Based on this alone, the use of a copyleft might not seem very important, and indeed if you have compelling reasons not to, the chances are that you will find enough like-minded contributors so that it doesn't really matter.
However, one thing that is clear is that founders, people who start new projects, overwhelmingly prefer the use of a copyleft license. This is illustrated by the overwhelming majority (80%) by which free-licensed project founders choose copyleft licenses (figure 8.3). These numbers include (indeed they are dominated by) small projects which rely on copyleft-licensed platforms, so "founder" also includes "contributions" of new separate projects relying on existing ones.
Why is this?
One need look no further than Apple Computer to see the answer. Apple's "OS X" operating system, which is used commercially on modern Apple Macintosh computers, is built on top of "Darwin" a particular distribution of BSD Unix. OS X contains many, many improvements on Unix, and tools to make it easier to use. But of course, OS X is proprietary. As a result, the growth of the free project, OpenDarwin, was somewhat depressed, resulting in its eventual closure.
People start free projects under the promise that they will stay free. Copyleft offers that promise
This can happen because Darwin has no copyleft.
On the other hand, GNU/Linux, which is mostly licensed under the GNU GPL or LGPL licenses, and therefore protected by copyleft limitations from this kind of hijacking of community effort, continues to boom in popularity.
In other words, people start free projects under the promise that they will stay free. Copyleft offers that promise.
"Copying" and "Use"
The term "use", when applied to intellectual works, can be treacherously ambiguous. After all, "copying" a work, "distributing" it, or "deriving" from it, are clearly ways of "using" the work in the English vernacular. Yet theorists talking about copyright or software freedom generally do not consider these uses to be included in the word "use".
The term "use", when applied to intellectual works, can be treacherously ambiguous
Three of the four major definitions of software freedom that exist in the community include the requirement that a work must be "free to use for any purpose", and yet they also allow copyleft requirements to ensure that a work remains free by placing terms on "copying" and "distributing" it. These definitions include the Debian Free Software Guidelines from the Debian Project, the Open Source Definition from the Open Source Initiative, and the Definition of Free Cultural Works from the Freedom Defined wiki project).
The Free Software Definition from the Free Software Foundation and its GNU Project, is less demanding: it says only that you must have the freedom only to "run the program for any purpose". That's less vague, but of course, it also only makes sense for an executable program, which is why the other definitions opted for a broader expression.
This has always been contradictory if "copying", "distribution", and "derivation" are to be regarded as "use". The true ambiguities of this definition, however, only came to light with the introduction of "digital rights management" (DRM) and "technological protection measures" (TPM). These are both euphemistic names for encryption technologies designed to interfere with users' ability to copy and decode digital intellectual works.
Some licenses do not permit encrypted distribution whenever it would interfere with users' legal rights under the license
It was argued by some that the right to distribute a work in such an encrypted file format, even when no key is made available to allow users to unlock the work, was a valid "use" (i.e. not an act of "copying" or "distribution", which might be subject to copyleft restrictions). Some licenses, particularly those from the Creative Commons organization, do not permit encrypted distribution whenever it would interfere with users' legal rights under the license. A strong lobby was formed to try to convert Creative Commons' language over to an alternate form of protection against DRM-laden files, which relied on a requirement to provide a non-encrypted distribution of any file which was distributed in DRM format (an idea which seems logical based on the success of the GPL's requirement of a "source code" distribution along with any binary distribution).
However, some observers, notably Greg London, noticed an exploit which showed how this form of "protection" could fail to protect users' freedom to use and/or derive from encrypted works in a useful way. As a result, the Creative Commons licenses retain the anti-DRM language, although the issue remains somewhat controversial.
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.
Corollary to Rule #1
Do not use a 'non-commercial' or any other 'restricted-use' license on a commons-based project!
Such licenses reserve commercial use to the original author, and therefore thwart the parity principle that links free licenses to commons-based production. As such, so-called "non-commercial" licenses are destructive to commons-based activities. So, even if the work is likely to be focused on "non-commercial" activities, it is a very bad idea to formally limit such uses through the licensing.
In practice, a copyleft will put a strong practical limit on the sorts of "exploitation" that most authors are trying to protect themselves from with a "non-commercial" license clause.
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.
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.
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[17-19]). 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. 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 TAPR Open Hardware License, which attempt to extend copyleft provisions to the physical products manufactured from the design.
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.
#Oops, Wrong License...
It's pretty much a no-brainer to use a free license for a free culture project, but there are a lot of situations in which you might find it difficult. For example, you may have created a software package you are willing to release under a free license, but made extensive use of non-free libraries. What then?
Occasionally, this can even happen with "free" licenses, when two incompatible copyleft licenses have been used.
Essentially, you have two choices:
####Option #1: Re-licensing
Sometimes, the package you've relied on is under some sort of "semi-free" license (i.e. it's not a normal proprietary license, but it isn't a true free-license either. Or else, it might be under a free license, but one which isn't compatible with widely-used licenses like the GPL). In situations like this, it's probably a good idea to track down the copyright holder (usually, though not always, the author). Often, the use of this sort of license is a good sign that the author would be open to re-licensing the work if you ask nicely (or possibly, offer to pay for the change).
Occasionally, you'll find yourself having to sell them on the idea. Consider not only opening up about why you've decided to free your own code, and consider also engaging the user community to help you make the case for freeing the license.
####Option #2: Re-writing
Free software now being fairly mature, there is a free software library to do just about anything you can find a proprietary library to do. Switching over will require some re-writing on your project, but maybe not as much as you would think. Often you can write a compatibility layer or simply modify the calls in your existing code, and free yourself of the burden of code that isn't compliant with your licensing goals.
If you get really stuck trying to convert your code, remember you can ask for help: freeing your code is a benefit to the whole community, so it may well be that you can find people who are interested enough to help make it happen.
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.
 Eric Raymond; The Cathedral and the Bazaar, Homesteading the Noosphere, and The Magic Cauldron; 1997-2000. Also available in print as The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary from O'Reilly books.
5(http://www.freesoftwaremagazine.com/columns/copyleft_has_no_impact_project_activity). Statistics on project activity index were derived using features of the Trove search engine on Sourceforge for projects based on results from particular groups of licenses classified as "copyleft", "non-copyleft", "proprietary/other", and "public domain").
 An exploit, suggested by Greg London, shows how an unscrupulous party could use DRM to maintain a "platform monopoly" on rights which are granted by the license of a free-licensed work, even with a so-called "parallel distribution" requirement.
copyleft: A "copyleft" is a licensing provision which exists to ensure that the original license terms are applied to derivatives of the work.
Debian Free Software Guidelines/DFSG: A set of guidelines established by the Debian Project for determining whether the license of any given piece of software is "free enough" to be included in the Debian GNU/Linux distribution.
Debian Project: The Debian Project is a volunteer organization which packages and maintains the world's largest distribution of GNU/Linux. It is also a parent distribution for many more specialized GNU/Linux distributions.
Definition of Free Cultural Works: A standard for free-licensed works of an aesthetic or creative nature, meant to include and extend the standards established for free software, prepared as the principle raison d'etre of the Freedom Defined project.
distribution: A collection of software or other data, such as an operating system that is released as one packaged entity. Usually, there is an implication that the included packages have been tested for consistent interaction and quality.
Freedom Defined: The Freedom Defined wiki was created as a community response to the perceived lack of leadership by the Creative Commons in creating normative standards for freedom of cultural, creative, and aesthetic works. Its principle function is to maintain a definition of what "freedom" should mean in reference to cultural works, and to list licenses which are believed to satisfy that standard. It is roughly analogous to the Open Source Initiative for software.
Free Software Definition: The original standard for the meaning of free software, in terms of licensing requirements, provided by the Free Software Foundation
Free Software Foundation: The formal organization created by Richard Stallman to support the GNU Project and promote free software in general.
GNU Project: A project to create a complete Unix-like operating system from scratch, using all free software. The project was somewhat co-opted when Linux was developed by Linus Torvalds, well before the project's own Unix kernel could be created. The resulting operating system is popularly called "Linux", but purists (including Stallman) prefer to call it GNU/Linux to reflect this joint heritage.
license proliferation: In the commons environment, too many licenses can be a serious problem, as conflicts may arise, particularly with copyleft clauses. This is less of a problem with proprietary licenses, because it is always assumed that you will have to contact the licensor in order to use the work. For free licensed works, however, such problems negate the advantage of the free license.
Open Source Definition: A definition of software licenses which are worthy of the label "Open Source" according to the Open Source Initiative.
Open Source Initiative: An organization, started by Bruce Perens and Eric Raymond, to promote free software to businesses in a less "confrontational" way than had been pursued by the Free Software Foundation.