Free Software: What About Images?
Posted 18 Apr 2001 at 21:33 UTC by BenFrantzDale
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
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
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
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
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
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 »
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.
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 »
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.
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
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
like Raphael said, it might be a simple problem of size. Furthermore, even if the image generation is scripted (personnally I consider
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
"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
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.
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
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.
I got this email several days ago from Bowie Poag, the Propaganda
author. (Quoted with permission.)
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
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