Free Software: What About Images?

Posted 18 Apr 2001 at 21:33 UTC by BenFrantzDale Share This

According to the GPL (section 3) ``The source code for a work means the preferred form of the work for making modifications to it.'' In the case of a C program, that is the .c file as opposed to a compiled binary. In the case of a Perl program, that is just the Perl source which essentially is the binary. However I have yet to see this question asked of images. I will argue that, contrary to current practice, (most) images released as GPL ``software'' should be included as .xcf (or whatever the appropriate format may be) and ``compiled'' along with the rest of the software.

According to the GPL (section 3) ``The source code for a work means the preferred form of the work for making modifications to it.'' In the case of a C program, that is the .c file as opposed to a compiled binary. In the case of a Perl program, that is just the Perl source which essentially is the binary. However I have yet to see this question asked of images. I will argue that, contrary to current practice, (most) images released as GPL ``software'' should be included as .xcf (or whatever the appropriate format may be) and ``compiled'' along with the rest of the software.

Over the past several years I have created a number of icons for the GNOME project and created many themes (including the infamous E-X and GTK-X themes). There are two major difficulties I have run into. The first is that, as a beginner, I had to figure out how the experts did it. I found one of Tigert's Tutorials which got me started. However I had to invent a lot of things from there, trying to imitate what others had done. The problem? I didn't have access to the multi-layer format of the icons I was copying, I only had the flat .png format. I didn't have the source code!

The second problem I've had is related. In working with other people's images (which is what a lot of icon and theme creation is about) I have many times been forced to completely re-draw an image to do something as simple as alter a drop shadow or remove an item. The reason, again, is that I have no access to the layers of the original. It's very easy to hide a shadow layer, but almost impossible to do a good job removing a shadow from an image while leaving anti-aliased edges intact. This problem is even worse when an image has been flattened onto a solid background. Then the alpha (transparency) channel of shadows and any anti-aliasing onto the background is lost completely. Even once I knew how to create, I needed the source to be able modify others' work.

Fortunately, this problem is potentially easy to solve. Using ImageMagick's ``convert'' program. With convert it is as easy as

convert -geometry 48x48 big_icon.xcf normal_icon.png
to create a normal sized icon from a .xcf file. On my PII 366, this opperation takes about 6 seconds on a 6 layer 192x192 source image. (This is the number of layers I used to create a simple icon.)

Icons are not the only type of image that is used in software. Original photographs are, by their very nature flat images in terms of layers. It would not make sense to expect a more source-like file than just a flat image file. However they are often stored as .jpg files which are lossey. It could be argued that, where possible, Free (as in speech) photographs should be available in as high a quality as possible. For me, my ``master'' images are usually high-quality .jpg files, but generally for distribution smaller, lossier files make more sense. It would make sense for people to demand access to the ``source'' of the highest quality version of an image.

The third type of image I would like to discuss is computer-created images such as desktop backgrounds. As an example, the (nolonger active) Propaganda project created tiling desktop backgrounds. Despite the GPL liscence on the images they were only released in .jpg format. I never was able to get .xcf files from the author, though I can't see how the images could have been made without layers. (I don't mean to cryticize Propaganda; it is an example of a widespread trend.)

I am very curious what the Advogato community has to say on this topic. I have yet to see it addressed. As someone for whom the bulk of my contribution to Free Software projects has been in the form of pixels, I hope this trend of only distributing what ammounts to ``compiled binaries'' can be reversed and that like code, images can be freed.

Differences, posted 19 Apr 2001 at 00:58 UTC by Uruk » (Apprentice)

I think you've hit upon the difference between programmers and end users.

The vast majority of people with regard to the propaganda tiles are just end users. They don't care how the image was made, they just use it. Layer information is worthless for them. On the other hand, for graphics designers, it's very valuable.

I've seen sites before that release shareware or freeware type software for windows, with no source code provided. It's not that the authors would object to making the source code available, it's just that they figure that pretty much 100% of their users are going to be end users who couldn't care less about the source code.

I think you're in the same boat with the image files. If you ask people for the layered images, I don't see any reason why they wouldn't give them to you, they probably just don't know that anybody cares enough about the images to want that stuff.

But keep in mind - the GPL doesn't say that you MUST distribute the source code to a work with the work itself. It says you must make it AVAILABLE. That's part of why you can ship binary only CDs, because it's understood that the source is available even if it doesn't come on the original CD.

So I'd say that there's no problem at all with these images from a GPL perspective. If you ask them for the layered images and they refuse, then you might have a case pending further discussion of whether the .xcf really constitutes the "source code" of the image (I can pretty much agree with you that it does). If they don't give you the xcf by default though, I don't think the GPL has anything to say about that.

Re: Differences, posted 19 Apr 2001 at 01:44 UTC by BenFrantzDale » (Journeyer)

The difference between programmers and end users is an important one. What I'm trying to encourage here, though, is for people to treat images more like code. I wouldn't expect to have xcf files in rpms, but I do think they should be available along with source code in a tarball, or at least available online. Currently one has to email the author to get an xcf file and while that may be consistent with the GPL legally, I would argue that it is not consistent philosophicly.

One other thing with regard to end users: it is much easier to alter graphics for the end user than it is to alter code. Were ``source'' images readily available, I could see more people becoming involved in Free Software projects which is an all around good thing.


Very good idea., posted 19 Apr 2001 at 02:24 UTC by carmstro » (Journeyer)

I think this is a very good idea that really needs to get advertised around to the community. I recommend sending some emails to some prominent people in the community. Maybe you could talk to RMS about getting a section in the GNU coding standards about it or putting it as an another example in the GPL, or talking to someone else who is widely heard in the community and getting them to spread the word.

Also, I think there is a compromise between the position of distributing the image source code IN the main program source package and not actively distributing it at all. Just create an extra package with all the image source files in it and distribute it along with your main tarballs.

Not always easy or practical..., posted 19 Apr 2001 at 03:17 UTC by Raphael » (Master)

I agree with the article and I wish that more GPL software would include the "source code" for the images that are used in the program. However, this is not always easy to do.

I see at least three problems: large images, non-scripted modifications, or non-free software used for the creation of the final image.

Large images: The original version of some images may be simply too large to be included in the software package. For example, a 256x256 image used as a background texture is generated from a 1024x1024 image with multiple layers. Even with gzip or bzip2 compression, the XCF file takes a couple of megabytes, compared to a few kilobytes for the final version (scaled down and flattened). Distributing the source of several textures would increase the size of the package by many MBs.

Non-scripted modifications: Some images are created by applying (by hand) several modifications to one or several source images. For example, the final image could be created by embossing the source image, painting something over it, then using IWarp or a similar plug-in to distort it. This steps could probably be scripted, but this would be too much effort for a one-time thing (besides, the artists are not always programmers and do not know anything about Script-Fu or Perl-Fu). What should be distributed in this case? The original images? The images plus a text description of what was done to generate the final version? Several copies of the image as it was during the creation process, so that other artists could guess what operation was performed at every step?

Non-free software: In some cases, the final image is generated by non-free software. Including the source will not be very useful for all other artists who do not have that software package. In the best case, these artists will simply ignore these useless files. In the worst case, they will have to obtain a copy of this non-free application. This may not be a big problem for "free beer, but not free speech" software such as POV-Ray (although I really hope to see a decent GPLed ray-tracer or scanline renderer one of these days) but this is annoying for Photoshop, 3DS or other commercial software.

That being said, in most cases it would be possible to include the XCF files (or other formats) that were used to create icons, textures and other images. I hope that more authors of GPL software will do that.

Re: Free Software: What About Images?, posted 19 Apr 2001 at 08:39 UTC by hadess » (Master)

like Raphael said, it might be a simple problem of size. Furthermore, even if the image generation is scripted (personnally I consider these images art, and wouldn't see how the little by-hand modifications could be scripted), it would require a tool like the GIMP to be running... For build machines without X running, you'd need a command-line version of the GIMP.

In any case the easiest way to get the "sources" of the images is to ask the original author that will, I'm sure, be happy to give you the hints you need. So far every well-known graphics artist that I asked for help gave me this help. The only exception being Andrew Lindesay a couple of years ago that feared that I'd rip his GNUStep icons...

Programmers and end users, posted 19 Apr 2001 at 09:31 UTC by dirtyrat » (Journeyer)

"The vast majority of people with regard to the propaganda tiles are just end users. They don't care how the image was made, they just use it. Layer information is worthless for them. On the other hand, for graphics designers, it's very valuable. "
May I paraphrase?
The vast majority of people with regard to the GIMP are just end users. They don't care how the package was made, they just use it. Source code is worthless for them. On the other hand, for hackers, it's very valuable.

Definitely a good idea, posted 19 Apr 2001 at 13:41 UTC by jmason » (Master)

I think including image source in free software should definitely be a requirement. Otherwise, if you drop a project and allow someone else to take it up, they'll have to rewrite the image from scratch, or reverse-engineer it. Why not save them the bother?

However I'm not convinced that you need to actually build the images from source during the build process -- this just adds a stumbling block for users trying to build your code.

Just include the source, and the built images -- and if someone needs it, the source is there.

GPL applicable to nonprograms?, posted 19 Apr 2001 at 14:38 UTC by kelly » (Master)

I have consistently held that the GPL has poor application to things which are not programs, and especially to documentation, manuals, configuration files, and, indeed, images. I would strongly urge persons writing open source software to consider using licenses other than the GPL for those portions of their project which are not code.

Another reason not to use GPL for images is that it contains nothing whatsoever with regard to trademark. Any image, and especially images which are iconic in nature, has at least the potential to be or become a trademark, and the GPL's failure to address this issue really sinks it as an appropriate image license in such situations.

Using the GPL to license images is akin to using a hammer to drive a screw. Yes, you can do it, but there are better ways to accomplish your goal.

Regardless, images do need better support., posted 19 Apr 2001 at 20:30 UTC by argent » (Master)

On the one hand, the GPL seems to be a rather crude tool for licensing images. On the other hand, for images that are an essential component of a program having access to data that can be used to generate new images consistent with the existing ones would often make a programmer's job a lot easier... even if the files are in a format that requires non-free tools to maintain.

I don't know the answer, but I think the question deserves attention... just because the GPL isn't the right tool that doesn't mean the right tool can't be developed.

Fwd: Propaganda and the GPL.., posted 24 Apr 2001 at 20:19 UTC by BenFrantzDale » (Journeyer)

I got this email several days ago from Bowie Poag, the Propaganda author. (Quoted with permission.)

Hi Ben,

A friend of mine directed me to your post over at Advogato..I thought i'd write you a reply.

The decision to GPL the content produced by Propaganda is one I generally look back on as a strategic mistake. The GPL is simply awful when it comes to covering things that arent explicitly sourcecode -- The further away from sourcecode you get, the more vaguely the terms and conditions of the GPL apply. It was hoped that eventually the GPL would be revised to incorporate these sorts of materials -- It never was. Looking back, it would have been a far better idea to license the images under Perl Artistic, and not the GPL. Regardless, hindsight is 20/20, so they are (and will remain) GPL, past, present and future.

The choice to release the images as JPEG-only was largely an arbitrary one. The process of creating the images does use layers rather extensively, and the order of those layers tends to get shifted around alot..Sometmes two or more layers are composited into a single layer, and that layer is moved, or discarded halfway through the process. Basically, it's sort of pointless to preserve the original image as a multilayer .xcf because what may end up in the end to be only a 2 or 3 layer image may have been created from 10 or 15 intermediary layers that simply got smooshed down during the creation process. Preserving the layers separately would only lend insight into rudimentary tricks and techniques, so, I felt it was unimportant to preserve everything that .xcf.

Beyond that, I have a slight interest in keeping some of my techniques closely guarded secrets. Part of the allure of it is the fact that people can't successfully back-engineer my work. :) I gave a live tutorial once, at a Linux users group meeting here in town. Sat down and whipped up a few on a big projection screen TV...The odd thing is, people seemed almost disappointed that the process was as simple as it was, but in awe of how insanely powerful a tool like Gimp is when in the right hands. It's largely the machine's work, not mine. Sure, I do some tricks by hand, but mainly what you're looking at when you see a Propaganda tile is pure math. All of it can be reduxed into a very simple recipe. Its not automated, and its not the same every time....but a cookie is a cookie, as they say.

The creation process isn't linear, anyway. Its not like I sit down and say "Ok, I want to make something that looks like crumpled sandpaper"... I generally have no idea what a particular image is going to look like in advance when I sit down and build it. You don't paint it, really -- You guide it, and introduce elements into it as you go, depending on what you think will look best in the end. I'd imagine that 90% of the time it takes to build a single tile is spent changing layer modes and tweaking hue/sat values, seeing what sort of results come to the surface. The ones that look good, I keep. The ones that dont are tossed out, and the process repeats, and the image is refined until a final product is derived. Finely sifted numbers.

Lastly, rumors of my project's death have been greatly exaggerated. The project is still active, and new sets of tiles are produced regularly. We've just fallen out of favor with the company that now seems to control everything news and content-wise when it comes to the Linux scene..Propaganda is currently housed safely away from VA Linux Systems at [], where it will remain accessable and free.

Yours in science,

Bowie J. Poag

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page