3

I'm trying to figure out if I can distribute the Faenza icons, which are GPL licensed, with some MIT-licensed software I'm working on. What does the GPL license really mean when applied to a non-software medium, like an icon set, that is primarily used in software applications?

  • If I load the icons dynamically from external files instead of compiling them into an executable, would this violate the GPL license?

  • If not, would it make a difference if the icons were compiled in?

  • If I can compile them into a program, does the license just mean I can't compile the SVG "source code" of the icons into a program?

  • If I can't compile the SVG source into a non-GPL program, can I load it dynamically?

  • Even if I'm technically allowed to package the icons with my software under some of the above conditions, would I be violating the spirit of the license?

Relevant: Does distributing non-GPLd assets with a GPL application violate the license?

  • Consider also asking the authors of Faenza – Basile Starynkevitch Sep 6 '14 at 19:17
  • This is part of the reason why we have Creative Commons, not that it helps your current situation. I never understood licensing non-code resources under a license that is designed for code, even if it is not restricted to code. – user22815 Sep 6 '14 at 19:27
  • @Snowman CC licenses are popular enough on deviantART, so I assume the Faenza author is aware of them, and felt like the GPL was a better fit for some reason. Maybe it would be best to ask the author about his intent in this situation, but I'm still curious about the general case... what does the GPL mean when applied to non-software (or, at least, what are some good interpretations of what it might mean)? – Hey Sep 6 '14 at 19:31
  • 3
    It's not really clear how it works with assets, as even the FSF acknowledges the GPL is often inappropriate for things besides code: gnu.org/licenses/gpl-faq.html#WhyNotGPLForManuals – whatsisname Sep 6 '14 at 19:45
3

Standard disclaimer: I am not a lawyer. You should get one, if you are concerned about possible legal issues.

Certainly, you can distribute the GPL-licensed Faenza icons with some MIT-licensed code, since both of MIT licenses (yes, there are at least two of them) are GPL-compatible. The same way as you can mix MIT and GPL code in one project, you can mix MIT code with GPL assets, while you are releasing the entire software product under GPL. It should not entail any practical problems, since it does not imply re-licensing of code to GNU GPL, it still remains under terms of permissive MIT license, only code + icons as a whole would be GPL-licensed.

I did not say, that there are no other ways (most probably, you are right about “package, but do not embed”), but I wanted to point out that there is a way, one can be absolutely sure about.

  • That's an interesting take on it. Certainly using MIT-licensed code in a GPL-licensed project wouldn't change the license of the code. So I could MIT license all of the code, but GPL license the actual package containing the code and the icons. But I'd really like to stick with a liberal license for the entire package, so I'm not sure if this is a good solution for me. I don't want there to be any question about what people can do with the package, I want them to do whatever they want with it as long as it doesn't violate the licensing of any of the components. – Hey Sep 7 '14 at 18:51
  • @Hey Hmm... I am curious, what actually possible use cases of package could be, which are limited under GNU GPL more than under MIT licenses. Modifying binary (or non-source in any way) code and distributing the outcome? – Dmitry Alexandrov Sep 8 '14 at 11:32
  • I don't think the GPL would actually limit a package much, but what I'm worried about is confusing potential users/contributors. Say for example I want to list the software in some online directory, and in order to do that I need to select a license from a list. Since the package is GPL, I'd need to select that. That's going to keep some people away, even if I try to describe it as being "mostly MIT licensed" at the same time. – Hey Sep 8 '14 at 12:32
  • @DmitryAlexandrov: A possibility that exists under MIT, but not under GPL, is to modify the package and distribute only a binary version of the modified package. – Bart van Ingen Schenau Sep 8 '14 at 13:34
  • 3
    I think you misunderstand "GPL-compatible", a license is GPL compatible if it can be combined with GPL code and the aggregate distributed under the GPL. You may not combine GPL code code with a compatible license and distribute the combination under the non-GPL license. See: gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean – Craig Sep 8 '14 at 19:27
0

Here's my interpretation of it.

Definitions

The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

Seems like the only reasonable interpretation is that source code refers to the SVG source and object code refers to the PNGs generated from it.

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

Under this definition, I would be conveying the the icons by packaging them with other software.

Distribution

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License...

This means I can package the PNG icons with my project, as long as I also make the SVG source available. If I'm not modifying that source, I can make it available simply by providing a link to a third-party host, If I'm reading section 6 right.

The viral part

This is the part I was worried about:

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

...

c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

...

Looks bad so far, right? But:

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

As far as I can tell, this clause lets me off the hook with respect to the viral copyleft thing. My software project is a separate and independent work from the icon set project. This means the GPL license does not apply to my software, as long as the projects are not combined. I take this to mean that loading the icons dynamically is fine, but embedding them is not.

Summary

I'm allowed to package the GPL'd icons with my MIT-licensed software, but not embed them. If I change the SVG sources, I need to make those sources available, otherwise I need to include a link to the original sources. The GPL license from the icon project will not extend to my software project, as the distribution is an aggregate rather than an extension of the icon project.


Dual licensing

Another option, as I see it, is to dual-license my software under both the MIT and GPL licenses. Providing it under a GPL license should satisfy the requirement for any works based on a GPL'd work to also be GPL'd (considering a program to be a derivative work of an icon set seems like an extreme stretch, but apparently some people would be willing to classify it as such). As far as I can tell, while there is a requirement to release derivative works of GPL'd works under the GPL, there is no requirement stating that such works may not also be released under other licenses.

  • 1
    I don't think that program + icons falls under an aggregate. One of the characteristics of an aggregate is that if you separate the program from the icons and re-distribute only the program, then you don't lose any functionality. – Bart van Ingen Schenau Sep 7 '14 at 16:18
  • @BartvanIngenSchenau you wouldn't lose any functionality, though. You'd just have no icons, unless you replaced them with other icons. When you talk about characteristics of an aggregate, are you talking about a general definition or the definition given in the GPL? I didn't notice any language like that in there. – Hey Sep 7 '14 at 18:54
  • 1
    The functionality you lose is, for example, the effective use of buttons that are only labelled with an icon or the look and feel of the program. When talking about the characteristics of an aggregate, that is based upon my understanding of the GPL license and how the FSF is likely to interpret it (based on the intent of the GPL licenses). – Bart van Ingen Schenau Sep 8 '14 at 4:31
  • @BartvanIngenSchenau to my understanding it is either an aggregate or a derivative work. What I want to do seems much closer to the definition of "aggregate" given in the GPL than the definition of "derivative work" given in, say, USCO's circular 14 (I don't believe the GPL has the authority to redefine legal concepts like "derivative work"). – Hey Sep 8 '14 at 12:22
  • 1
    Now we are getting into legal interpretations that only a court of law can resolve. – Bart van Ingen Schenau Sep 8 '14 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.