The trouble with artwork and free software licenses

Are you a crafter of icons, sounds, backgrounds and splash screens, or even window manager themes? Selecting the right license for your artwork to coexist with free software is no trivial task. Creative Commons (CC) and Free Software Foundation (FSF) licenses each have their advantages, but they are mutually incompatible. The two groups are beginning to move toward simplifying the situation, but in the meantime there are several things you can do to make license compatibility easier.

The crux of the problem is that non-software artwork like the examples above occupies a strange niche inside free software applications and operating systems. They are not code, but they are tightly integrated into the system. Artists frequently create them as standalone works, but they are also — by necessity — bundled into software packages and distributions, many of which are under the FSF’s General Public License (GPL).

A Creative Commons taxonomy

CC has crafted a palette of licenses for non-software works that is naturally appealing to artists. Other artists use them, they are integrated into the tools of social networking sites like Flickr, and they explicitly accommodate the concerns of artists by using the appropriate terminology — “performance,” “reproduce,” and “adaptation,” for example.

CC currently defines six licenses. They share a set of common clauses, but differ from each other on the basis of the inclusion or exclusion of four specific elements: the Non-commercial element, the No Derivatives element, the Share Alike element, and the Attribution element.

Mathematicians will note that there are 2⁴ = 16 possible combinations of these elements, so clearly not all possibilities are addressed. All of the current licenses, for example, include the Attribution element, and there are no “Attribution No Derivatives Share Alike” nor “Attribution Non-commercial No Derivatives Share Alike” licenses, as the No Derivatives and Share Alike elements overlap in their requirements.

The six current licenses are:

• Attribution Non-commercial No Derivatives (CC-BY-NC-ND)
• Attribution Non-commercial Share Alike (CC-BY-NC-SA)
• Attribution Non-commercial (CC-BY-NC)
• Attribution No Derivatives (CC-BY-ND)
• Attribution Share Alike (CC-BY-SA)
• Attribution (CC-BY)

Complicating matters is the fact that the CC licenses are revised far more frequently than FSF licenses. Revision 2.0 introduced a clause stating that derivatives of CC-licensed works could be released under later versions of the original license. 2.5 made multiple changes to the attribution requirements. The current CC licenses, numbered 3.0, were released in Feburary 2007.

Further complicating matters, each revision of a CC license is available in different versions for different legal jurisdictions. The distinctions are not simply linguistic, but include real changes to the rights and responsibilities covered.

For example, the European jurisdiction CC licenses contain a “moral rights” clause. If the original author of a work feels that a derivative work harms his or her honor or reputation, the moral rights clause gives the original author the power to demand his or her attribution be removed from the derivative work, or to terminate the license. CC licenses in the United States and Canadian jurisdiction do not have such a clause.

CC licenses and the GPL

Luckily, when determining which CC licenses permit a work to be combined with GPL software, there are far fewer choices.

The Non-commercial and No Derivatives elements both conflict with the FSF’s free software definition, so no license that includes either of these is compatible with the GPL.

The Non-commercial element restricts the licensee’s right to use the licensed work in a commercial setting; this conflicts with the free software definition’s “freedom zero” — the freedom to run the program, for any purpose. The No Derivatives element restricts the licensee’s right to change the licensed work, which conflicts with both freedom one (the freedom to “adapt it to your needs”) and freedom three (the freedom to “improve the program and release your improvements to the public”).

The remaining licenses, CC-BY-SA and CC-BY, stick only to elements that satisfy the free software definition. But to be GPL-compatible, a license must also be a copyleft license — meaning the license ensures that once a work is made available to the public, it cannot be taken away again. CC-BY makes no such requirement, thus it is not copyleft and is incompatible with the GPL.

That leaves CC-BY-SA, which based on its nominal elements satisfies both the free software definition and the copyleft definition. And indeed, CC-BY-SA is a popular choice at icon and wallpaper sites like kde-look.org, gnome-look.org, and DeviantArt, and digital repositories as varied as themes.wordpress.net, the Internet Archive, and the Open Clip Art Library. But the FSF says that CC-BY-SA is incompatible with the GPL, too.

Why CC-BY-SA is not GPL-compatible

The statement on the FSF license page says only “please don’t use [CC-BY-SA] for software or documentation, since it is incompatible with the GNU GPL …” I contacted both CC and the FSF to ask about the specific incompatibilities.

FSF Licensing Compliance Engineer Brett Smith says that there are several problems that prevent users from combining CC-BY-SA and GPL components into a single work. “Perhaps the most straightforward one is that they’re both copyleft licenses: each license wants the entire work to be released under its own terms, so no matter what you do you can’t satisfy them both.”

CC Interim General Counsel Thinh Nguyen agrees, but points out the new “compatibility” clause that was added in version 3.0 of CC-BY-SA. Section 4(b)(iv) states that a licensee may distribute or publicly perform an adaptation of the licensed work under “a Creative Commons Compatible License.” The 3.0 licenses’ release announcement indicates that compatible licenses will be listed on the CC Web site, although none have yet been so certified.

Nguyen verifies that CC is interested in certifying licenses as Creative Commons Compatible, but could not provide details with respect to any particular licenses. Smith confirms that the two groups have discussed certifying the GNU Free Documentation License (FDL), but has heard no such discussion regarding the GPL.

In addition to the copyleft collision, Smith considers some of CC-BY-SA’s specifics to be in conflict with the GPL. “For instance, section 4(a) in CC-BY-SA 3.0 has provisions to allow the authors to demand that their attribution be removed when the work is adapted or included in a collection. The GPL has no such provision, so imposing this requirement on a GPLed work would violate section 10 [of the GPL] — it says in part, “You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.”

CC-BY-SA 3.0’s “moral rights” clause (in those jurisdictions where it is included) is also a further restriction contrary to GPL’s section 10. But Smith says it may not constitute a genuine problem, since it only exists in versions of the license where “moral rights” are established law. “Section 4(d) is meant to mirror a concept of ‘moral rights’ that exist in certain jurisdictions, including most in the EU. I’m not very familiar with the details, but the basic idea is that even if you have a license to use a work in certain ways, you may not use those rights in ways that would cause obvious harm to the author.

“This all relates to compatibility analysis because we’ve historically held that clauses that merely require what the law requires do not render a license GPL-incompatible. For example, a number of free software licenses have a clause that says something like, ‘This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor….’ (That particular example is from the Apache License 2.0.) Even though GPLv2 doesn’t contain a similar requirement, we never said that a license was GPL-incompatible merely because it had a term like this: even if the license didn’t say this, you still wouldn’t have permission to use the trademark, so it doesn’t actually put new legal burdens on the licensee. Section 4(d) of CC-BY-SA may act similarly; we would have to research it carefully.”

Applying the GPL to non-software works

If none of the CC licenses allow a work to be combined with GPLed software, one common alternative is to license the artwork itself under the GPL. The FSF suggests this possibility, but it also cautions that what constitutes the “source code” of the licensed work must be clear.

In contrast to the CC licenses, the GPL and Lesser General Public License (LGPL) use the language of software — “interface,” “propagate,” and “downstream.”

The distinction is not merely cosmetic; if you attach the GPL to a piece of music, the definitions, rights, and restrictions it specifies all require translations and interpretations — things on which reasonable people can easily disagree. Thus some uses of the music (e.g., re-recording it) are in a gray area. Is the arrangement of the piece considered part of the “source code” to the music as the GPL sees it, or only part of the “packaging”?

Smith acknowledges the that the difference in terminology can cause problems. “I’ll readily admit that there is a learning curve for artists who want to release their work under the GPL. However, I don’t think that means it’s a bad idea to recommend the GPL to them; if anything, I think it means the opposite. As more artists use the GPL and gain an understanding of how it affects their works, they’ll be able to share that knowledge with their friends and colleagues, making it easier for the next person to understand.”

Ultimately, licensing artwork under the GPL is only a safe choice if incorporation into free software is the only usage you wish to guarantee. Some creations (such as icons) are generally not used outside of software, but others (such as music or desktop background images) are.

Solution one: artists, publish with more than one license

The CC licenses are popular among artists for good reasons, and the FSF licenses are popular among software developers for equally good reasons. So for an artist who moves in the free software world, the only way to license creations so that they are both useful to other artists in a creative context, and available for use by free software developers, is to release them in a GPL-licensed and a CC-licensed form.

This does not mean releasing a package with both licenses attached. Attaching two conflicting licenses would be self-contradictory and of no practical use. Instead, you make two packages, one for each license.

Yes, that is technically two times as much work at the packaging stage, but it is two times practically zero. For large collections of artwork, the prevailing wisdom is that you can license the entire collection with a single file (named COPYING or README).

People who re-use some of the material in a derivative work or adaptation must keep track of copyright notices, but by making your artwork available under more than one license, you spare them the trouble of keeping track of multiple licenses within their projects.

CC is developing an interesting project named liblicense that simplifies tracking the licenses of particular files, even integrating a GUI license selector to make the process painless.

Solution two: coders, write software to avoid licensing pitfalls

Even though combining two works under incompatible licenses (such as CC-BY-SA and GPL) is not allowed, there are ways developers can code an application so that images and other data remain separate as far as copyright law is concerned.

Smith says, “There hasn’t been a lot of case law on this, and separate collections of images for developers to use are a relatively recent development, so best practices for the community haven’t fully evolved yet either. We’re still at a point where we feel it’s best to get all the details of a particular scenario and rule on that.”

On Unix-like operating systems, applications typically store resource data such as icons, sounds, and splash screens separately, somewhere within the /usr/share hierarchy. As a developer, you can code your app to access those resources in any number of ways.

Hard-coding the paths to your icons, Smith says, probably results in what copyright law could deem a single, combined work. In that case, Smith would advise ensuring that the icons had a GPL-compatible license.

But mechanisms do exist to make a clean separation between the code and the data. “Most graphical toolkits are written such that applications can request stock icons, such as the ‘zoom in’ icon, and the toolkit will load and display a particular image based on the user’s theme and other preferences.”

“This level of abstraction,” he says, “is enough that I haven’t met anybody who’s particularly concerned about compatibility between the icon at the bottom of the stack and the application at the top.”

Freedesktop.org’sIcon Naming Specification is the place to start. The spec defines a hierarchy of contexts and standard icon names. The Icon Theme Specification details how can look up installed icons, install its own icons, and what happens when an app requests an icon that doesn’t exist in the user’s current theme.

GTK+, Qt, and other modern toolkits have their own implementations of the icon theme spec API; developers should consult their documentation for the specifics, or seek help from the Freedesktop.org project.

Someday, certified compatibility between FSF software licenses like the GPL and CC content licenses may make the issue moot. But for right now, artists who want to make their work available to other artists and to free software developers must make sure they offer acceptable licenses to each group. And free software developers can make life easier by writing their code to take advantage of the Freedesktop.org specs. Then end users get the best deal of all — great-looking artwork running hand in hand with excellent free software.