Development of Creative Commons licenses

[Arne Babenhauserheide <arne_bab AT web.de>]

Hi Gisle,

Sorry for answering late. Time has been pretty tight up to a week ago
(and will now likely be tight again, but I wanted to answer you before that).

Am Sonntag, 18. Mai 2014, 08:52:36 schrieb Gisle Hannemyr:
> > How will these problems be solved by someone who wants to incorporate
> > CC-BY-SA graphical art in a GPL work?
> 
> I've no idea, I've never wanted to use GPL for stuff that are not
> conventional computer programs written in a high-level conventional
> programming language.

I know 4 main ways:

1. The Wesnoth Way
   “The Source is what we have”

The project just asks artists for full resolution PNG image files
(without all the layering information) - and only uses these to
develop the art. This was spearheaded by the GPL-licensed strategy
game Battle for Wesnoth¹.
¹: http://wesnoth.org

This is a viable strategy and also allows developing art, though a bit
less convenient than with the layered sources. For example the
illustrator who created many of the images in the RPG I work on used
our PNG instead of her photoshop file to extract a die¹ from the cover
she created for us². She took the chance to also touch up the colors a
bit - she had learned some new tricks to improve her paintings.
¹: http://1w6.org/releases/wuerfel.png
²: http://1w6.org/deutsch/anhang/artwork/cover

This clearly complies with the GPL, because the GPL just requires
providing the file used for editing published file. If the released
file is what you actually use to change published files, then the
published file *is* the source.

2. The External Storage
   “Use the FTP, Luke”

Here, files which are too big to be versioned effectively or which
most people don’t need when working with the project get
version-numbers and are put into an external storage - like an FTP
server.

I do that for gimp-files: I put these into our public release-listing¹
via FTP. For example I used that for a multi-layer cover² which
gets baked into our PDF.

¹: http://1w6.org/releases/
²: http://1w6.org/releases/cover-tim-2.6.0.xcf

3. The elegant way
   “Make it so!”

Here huge files are simply versioned alongside other files and the
versions to be used are created directly from the multi-layered
files. The usual way to do that is a Makefile in which scripts
explicitly define how the derived file can be extracted.

This is most elegant, because it has no duplication of information,
the source is always trivial to find, it’s always clear that the
derived file really originated from the source and it is easy to avoid
quality loss or even reduce it later.

The disadvantage is that it can be very cumbersome to force new
developers to get all huge files and then create them before being
able to really start developing.

The common way to do this is a Makefile - for example the one I use
for building my PhD thesis¹.
¹: http://draketo.de/light/english/free-software/makefile-to-autotools#sec-2

4. Pragmatic elegance
   “Hybrids win”

All the ways above can be combined: Huge files are put in version
control, but the derived files are included, too, to make it easier
for new people to get in. Maybe the huge files are only included on
request - for example they could be stubs with which the version
control system can retrieve the full files when the user wants
them. This can partially be done with the largefiles extension¹ in
Mercurial by just not getting the large files.
¹: http://mercurial.selenic.com/wiki/LargefilesExtension

Also you can just keep separate raw files and derived files. This is
also used in Battle for Wesnoth¹: Optimized files
of the right size for the game are stored in one folder while the
bigger full resolution files are stored separately.
¹: http://wesnoth.org

I hope this helps to provide some inspiration for people who want to
use free art in GPL projects.

Best wishes,
Arne

PS: I now also published this text on my personal website¹.
 ¹: http://draketo.de/english/huge-datafiles-free-culture

Attachment: signature.asc
Description: This is a digitally signed message part.