Sven Neumann wrote the list about a potential legal problem with the XCF (Gimp's Native File Format) loader in Imlib2:
yesterday night on #gimp someone pointed out that an XCF loader appeared in the Imlib2 CVS tree. I was curious, checked out the source and had a closer look.
There are two files, namely loader_xcf.c and loader_xcf_pixelfuncs.c, and as expected they contain code from the gimp tree, more exactly, from app/xcf.c and app/paint_funcs.c. The copyright header is however missing from both files and only loader_xcf_pixelfuncs.c has a small hint somewhere at the top that code was taken from the gimp source.
Imlib2 seems to be distributed under the X11 license. Since it is quite short, I have attached the text of the file COPYING as found in the Imlib2 source tree so you can have a closer look yourself.
It's definitely not our intention to make life too hard for someone who wants to hack an XCF loader. This has been clearly stated lately when the gdk-pixbuf people asked us to allow to include the relevant code under the LGPL license.
Simply using the code, removing the copyright notices and putting it under a non-compatible license is however too much if you ask me and we shouldn't let Carsten get away with this.
I'm not too deep into licenses and I hate to deal with legal questions. Could someone please step forward and take care of asking Carsten to change the files and take legal actions if it becomes necessary ?!
Several people wanted immediate action, but Tino Schwarze wanted to take
a more friendly approach of sending an e-mail and asking it to be removed.
Sven liked this idea, and Daniel Egger send an e-mail off to the person
who checked in the code. A few days later Daniel replied that he talked to Christian Kreibich, the author of the codemixture
and he told me that it was a mistake to publish the code in this form and
that he'll undo that step. He and Raster are going to meet next week and
then they'll think about possible solutions for this conflict.
Marc Lehmann wasn't so sure about this. He replied,
Don't they think this is demanding some _action_ (like reverting that
patch)? "meet next week" and "possible solutions" sounds, well, not very
serious.
The patch IS already reverted. About 5 minutes after my mail...
Marco Lamberto annouced that he has released a new version of gDynText, and it could be found at http://download.sourceforge.net/gdyntext/gdyntext-1.5.0.tgz
Sven Neumann asked if he should update the
version in gimp CVS or is this code considered to be unstable compared to
the version we ship with gimp now ? There are a few bugs regarding the
GDynText plug-in listed at the gimp bugtracker. Does this version fix those
problems?
Marco replied that 1.5.0 is just as stable as the previous version, and several bugs were fixed as well.
Frazer Williams is wanting to write a plug-in, but he needs a way to pass the co-ordinates to the plug-in. He explained what he wanted to do:
I'm trying to write an "unplot" plugin.
The idea is to load a graph image into the gimp (probably using a scanner),
and then, using the mouse to click on points on the graph, write the x and
y values of mouse-selected points to a file. Thus, if I had a graph of,
say, voltage vs. current, I could digitize it manually using the plug-in,
obtaining a file with voltages and currents.
Somebody replied that it would be a GTK-related solution. Several other
people suggested alternatives to manual mouseclicks, such as unqiue colors
that can be found in the image. Kevin Cozens suggested that Fraser looks
into the code for the ImageMap plugin. Thinking
about what it how it works from the users point of view I suspect it has to
have a way of getting the mouse coordinates.
There were no more messages in this thread, so hopefully Fraser had some success with his plug-in.