This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Feature: Legal

The trouble with artwork and free software licenses

By Nathan Willis on September 26, 2007 (9:00:00 PM)

Share    Print    Comments   

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 24 = 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:

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,, and DeviantArt, and digital repositories as varied as, 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."'s Icon 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 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 specs. Then end users get the best deal of all -- great-looking artwork running hand in hand with excellent free software.

Share    Print    Comments   


on The trouble with artwork and free software licenses

Note: Comments are owned by the poster. We are not responsible for their content.

The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on September 26, 2007 10:04 PM
"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."

This is just plain wrong. Several non-copyleft licenses are GPL-compatible, at least according to the Free Software Foundation [1]. If the Creative Commons licenses are incompatible with the GPL, that's purely due to other reasons.



Re: The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on September 27, 2007 01:51 PM
I stopped reading right there. Did the author of this article even bother to read the licences,
before deciding to go around giving legal advice?


Re: The trouble with artwork and free software licenses

Posted by: Nathan Willis on September 27, 2007 05:00 PM
There are some non-copyleft licenses that are compatible with GPL because they allow for relicensing of the original work under different terms (i.e., under GPL) -- either explicitly or by virtue of their simple requirements. CC-BY does not allow for relicensing, as it explicitly states in clause 4(a).


Re(1): The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on September 27, 2007 11:07 PM
Wow. No. Only the original copyright holder of a work can relicense a work. You are thinking of distribution, "New BSD" licensed code can be distributed in a larger GPLed project because it imposes no restrictions above what the GPL imposes. It is still BSD licensed, not GPLed.


The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on September 26, 2007 10:26 PM
Yet another misinformed article. The packaging of artwork alongside code counts as "mere aggregation" under the GPL, and does not lead to license incompatiability. Hard-coding a filename in your software, but allowing the file referenced by that name to change, does not create a single work. Only including the binary code of the image within your software would lead to this situation.


Re: The trouble with artwork and free software licenses

Posted by: Nathan Willis on September 27, 2007 05:17 PM
Since you do not explicitly outline the scenario that you are addressing, allow me lay out the specifics. GPL-licensed code X and CC-BY-SA icon Y are combined into a package Z, with references to Y hard-coded.

You assert that the inclusion of Y does not make Z a derivative work according to GPL, since you could remove Y and replace it with something else (say, W). That by itself is not true, since the removal of Y altogether would cause functional breakage of Z. If it were true, then you could make a Linux kernel with a non-free binary blob driver on the grounds that because you could pull the driver out and replace it with another that used the same interface, its inclusion in the kernel does not create a single work. That is untrue, and more importantly, the Fd.o icon theme spec does not work by harcoding file names of icons.

However, even if your original assertion (that Z is not a combined work under GPL) was true, the conclusion would still be wrong, because Z is also subject to the terms of CC-BY-SA, and the combined work is also definitely a combined work under CC-BY-SA.

Granted that there is no one, bright line agreed upon by everyone as to what methods of referencing an icon constitutes creation of a derived work, but hardcoding is definitely at the extreme end of the spectrum and thus the least safe. Still, the example also illustrates the other problem: that when combining works of two different licenses, both must be satisfied, and even when things are clear under the terms and definitions of one, they may not be under the terms and definitions of the other. Thanks for providing the example.
[Modified by: Nathan Willis on September 27, 2007 11:24 AM]


The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on September 26, 2007 10:57 PM
"CC-BY makes no such requirement, thus it is not copyleft and is incompatible with the GPL." - That sentence is wrong. CC-BY is compatible with GPL, it just has one requirement less, so it is even more free than GPL, but not so well protected against apropriation.


Re: The trouble with artwork and free software licenses

Posted by: Nathan Willis on September 27, 2007 04:57 PM
The article is correct, your assertion is wrong. Quoting directly from
Creative Commons Attribution 2.0 license (a.k.a. CC-BY) This is a non-copyleft free license that is good for art and entertainment works, and educational works. Please don't use it for software or documentation, since it is incompatible with the GNU GPL and with the GNU FDL.


Re(1): The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on October 01, 2007 09:37 PM
Nathan, why on Earth are we discussing 2.0 when 3.0 is already out?



The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on September 27, 2007 12:45 PM
This is an area which needs desperate attention, as what is software wthout clarity and freedom regarding the works it is used to create?


CC licenses and the GPL

Posted by: Anonymous [ip:] on September 28, 2007 12:12 AM
"But to be GPL-compatible, a license must also be a copyleft license"
That is absolutely not true. MIT license is not copyleft and it is GPL compatible while CDDL is a copyleft license and is not compatible with GPL.
GPL compatible license must allow mixing code/work with GPL licensed code/creations.


Attribution (CC-BY) is GPL compatible (if you could ignore moral rights)

Posted by: Anonymous [ip:] on September 28, 2007 01:22 AM
Nathan says: "But to be GPL-compatible, a license must also be a copyleft license".
It's non sense since BSD, Apache, LGPL, W3C are all non copyleft licenses. If your license permits GPL clauses so your license is GPL compatible.
Please, read further


GPL icons

Posted by: Anonymous [ip:] on September 28, 2007 03:42 AM
Very interesting read. I have put a lot of thought into this recently, in creating, and GPL-licensing an icon set for FileZilla3. ( awkwardly in this context, GPL licensed through CC, at bottom of page.) //

It's a loaded one, but my biggest question is why can't I say also at the bottom, "Toolbar icons also wholly and separately licensed CC-BY"? The article seems to say I need to duplicate all my icons somewhere else, and differently license them there. (Would love for there to be a forum someplace where this could be discussed. Maybe here is the place.) //

Also, if it matters, I consider the "source code" of an image to be the format in which a new designer would likely want to make modifications. In my case, probably the "original" svg files.


Data licenses in games

Posted by: Anonymous [ip:] on September 29, 2007 02:05 AM
The whole licensing-mess is especially problematic for the free games movement (links: ) Someone who has a clear head ( and is a bit better informed than the author of this article ;) ) should thing about the licensing crap and make a definite statement, so a discussion may finally begin.


Re: Data licenses in games

Posted by: Anonymous [ip:] on September 30, 2007 09:51 PM
What's problematic about it? There is nothing illegal about using CC content in a game engine that is released under the GPL, the only problem comes in the freeness of the license. CC are still considered non-free licenses by most distributions that care about software freedom and as such those distributions can't (or won't) distribute said games. Which leaves the makers of the "free" games with the decision: do they choose the philosophically free route or the popular non-free route that gives them fewer GNU/Linux distro's able or willing to distribute said games.


good article

Posted by: Anonymous [ip:] on September 30, 2007 02:52 PM
you did a very good research for this article IMHO.
There seems to be many misunderstandings on what licence needs to be used for a specific project.


The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on October 01, 2007 07:32 AM
I had read the license page on fsf site only a few days ago and this articles expands on to that.

Which is the best license for the weblogs, I mean least restrictive? I was thinking GNU FDL and CC-BY=NC.


The trouble with artwork and free software licenses

Posted by: Anonymous [ip:] on October 01, 2007 08:06 PM
I personally feel that the important issue is not whether or not the game art is free or not, and that the game source code being free is far more important. Sometimes this what is compatible with what stuff is just silliness. When games start borrowing art from each other, we wind up with a bunch of mediocre games that all look alike.


Art Libre copyleft license

Posted by: Anonymous [ip:] on February 16, 2008 01:15 PM
You forgot to mention

Here is it's description:
With this Free Art License, you are authorised to copy, distribute and freely transform the work of art while respecting the rights of the originator.

Far from ignoring the author's rights, this license recognises them and protects them. It reformulates their principle while making it possible for the public to make creative use of the works of art. Whereas current literary and artistic property rights result in restriction of the public's access to works of art, the goal of the Free Art License is to encourage such access.

The intention is to make work accessible and to authorise the use of its resources by the greatest number of people: to use it in order to increase its use, to create new conditions for creation in order to multiply the possibilities of creation, while respecting the originators in according them recognition and defending their moral rights.

In fact, with the arrival of the digital age, the invention of the Internet and free software, a new approach to creation and production has made its appearance. It also encourages a continuation of the process of experimentation undertaken by many contemporary artists.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya