Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] Compatibility with GPL and issues with availability of source

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: Francesco Poli <invernomuto AT paranoici.org>
  • To: cc-licenses AT lists.ibiblio.org
  • Subject: Re: [cc-licenses] Compatibility with GPL and issues with availability of source
  • Date: Mon, 1 Apr 2013 17:54:07 +0200

On Wed, 20 Feb 2013 11:50:28 -0600 Carlos SolĂ­s wrote:

>
> One of the topics commented for the discussion of the CC 4.0 licenses is
> the option to give a one-way compatibility between the CC-By-SA and the
> GPL. At a first glance, it looks like a great idea,

I am still convinced that it is a great idea...

> which would allow more
> intercompatibility between free licenses, but there is an issue with the
> GPL's requirement to provide complete corresponding source code.

I believe this is an issue with the way a number of CC-licensed works
are released, independently of the presence or absence of a
conversion-to-GPL clause.
In other words, I think that releasing a work without making its source
(that is to say, the preferred form for making modifications to it)
available does not really grant all the important freedoms to the
recipient, no matter what license is chosen.

>
> First of all, there's no consensus on what can be taken as the source code
> of every license-able work.

I think that the definition found in the GPL is flexible enough to be
applied to practically any (digital) work.

> For written works, it would be the editable
> file (in Word format, for example).

The point is not whether the form is "editable".
A binary executable file is an editable form of a program (you can edit
it, for instance with a hexadecimal editor!), but, in most cases, is
not source.

The point is whether the form is the preferred one for making
modifications to the work.
Hence, in your example, the .doc file may be the source form, as long as
the author prefers it in order to modify the work.
But, if the author modifies some other form (for instance, an .odt
file) and automatically generates the .doc file from that other form
(for instance, by using LibreOffice to perform the conversion), then
the other form is the actual source (and not the .doc file).

> But what about audiovisual works?
> Usually those are composed by several raw files (variously named "stems",
> "assets", "resources", and so on). Except for photographs (where there is
> only one raw file, unedited except for the color balance), most other
> works of this kind are composed themselves by several files, and the set
> of commands that are used to combine them (the project file for audio and
> video, the image editor's full file for images).

Just like when a program or library is built from several source files
(with or without some written rules for a build system, such as a
Makefile for make, or input files for the GNU autotools, or for cmake,
and so forth), I would say that the source consists of the various
files needed to build the final ready-to-use form of the audiovisual
work (possibly along with the written rules, if present).

> And then there's the
> question of how much must be an individual asset edited, in order to
> require the release of both the original file and the commands to edit it.

Just like with programs, I think that the written rules are required
whenever the author prefers using them.

>
> Secondly, as it should be well-known, most works under CC licenses
> (especially audiovisual works) don't release the source code,

As I said above, I think this is an issue that should be cured
independently from any license-conversion mechanism.

> either
> because of the size of the files, or because those files weren't preserved
> at all.

If the files were discarded, they are not the preferred form for making
modifications to the work. Some other form was apparently chosen as
preferred: that other form is the actual source.

> Also, the GPL requires that the assets and project files are "in a
> format that is publicly documented (and with an implementation available
> to the public in source code form), and must require no special password
> or key for unpacking, reading or copying". This outlaws releasing the
> project if it was made with non-free software (like Photoshop, Word, Sony
> Vegas and many more).

Please note that this additional requirement is present in the GNU GPL
v3, but not in the GNU GPL v2...

>
> That leaves two options for relicensing: allowing it only if those works
> already comply with releasing full corresponding source, or else
> retroactively forcing authors to comply with the new license terms.

I don't think the license can force the copyright holder to do anything.
Whoever holds the copyright is not subject to the license at all...

Moreover, I think that a re-licensing to GPL would be automatically
ineffective, whenever the source is not available: nobody (except for
the copyright holder) could re-distribute the work under the terms of
the GPL, if those terms cannot be complied with (because no source was
made available to the potential re-distributor).

[...]
>
> This doesn't mean that there shouldn't be any compatibility with the GPL,
> but it must be limited to works that already comply with the GPL's
> requirement for source code (here meaning full assets, full instructions
> for editing the assets in their final form, and all files under a free
> format).

As I said above, it may be worth noting it explicitly, but I think that
the conversion to GPL would automatically be ineffective without
source.

Bye and thanks for contributing to the discussion.


--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

Attachment: pgpIwwe3kxCa8.pgp
Description: PGP signature



  • Re: [cc-licenses] Compatibility with GPL and issues with availability of source, Francesco Poli, 04/01/2013

Archive powered by MHonArc 2.6.24.

Top of Page