Bug#431794: whichwayisup: CC-v3.0 licenses do not meet the DFSG

Sun Jul 8 10:47:39 UTC 2007

On Fri, 6 Jul 2007 00:34:37 +0200 Moritz Muehlenhoff wrote:

> Francesco Poli wrote:
> > The debian/copyright file[1] of this package states, in part:
> > 
> > | All game content, sounds and graphics are licensed
> > | under Creative Commons 3.0 Attribution license
> > | ( http://creativecommons.org/licenses/by/3.0/ )
> > 
> > As I replied[2] to you on debian-legal and debian-devel, I don't
> > think that CC-v3.0 licenses meet the DFSG.
> > In that message I referred you to some past threads, among which
> > you can find a detailed analysis[3] of CC-by-sa-v3.0: most of the
> > issues found in CC-by-sa-v3.0 also apply to CC-by-v3.0.
> 
> Just because you feel it's non-free, doesn't make it non-free. I don't
> see anything in the license rendering it non-free. More important, the
> authorative body for DFSG-compliance are the FTP masters, who decided
> that CC-cy-sa v3 is DFSG-compliant, so I'm closing this bug.

[For those that are out of context, see bug #431794]

I would *love* to be persuaded that there are no problems with
CC-by-v3.0 and CC-by-sa-v3.0, but I haven't yet seen any convincing
rebuttal of my detailed analysis of CC-v3.0 licenses.

May I have an explanation from FTP masters as to *why* they think
CC-by-v3.0 is ok for main, please?

The issues that I see in CC-by-v3.0 are the following ones.
Disclaimers: IANAL, TINLA, IANADD, TINASOTODP.

| Creative Commons Legal Code
| 
| Attribution 3.0 Unported

This is the unported version of CC-by v3.0 license.

[...]
|  e. For the avoidance of doubt:
| 
|      i. Non-waivable Compulsory License Schemes. In those
|         jurisdictions in which the right to collect royalties through
|         any statutory or compulsory licensing scheme cannot be
|         waived, the Licensor reserves the exclusive right to collect
|         such royalties for any exercise by You of the rights granted
|         under this License;

This is worrying, IMHO.
DFSG#1 states, in part: "The license may not require a royalty or other
fee".
Hence I would say that a license where the Licensor reserves the
exclusive right to collect royalties does *not* meet DFSG#1.
On the other hand, in a jurisdiction in which royalty collection rights
cannot be waived, this issue seems to be *unavoidable*...  How can that
be worked around?  Is this clause a legal no-op?  But is this a freeness
issue anyway?  How do we deal with jurisdictions where granting some of
the permissions required by the DFSG is *impossible*?

[...]
|     When You Distribute or Publicly Perform the Work, You
|     may not impose any effective technological measures on the Work
|     that restrict the ability of a recipient of the Work from You to
|     exercise the rights granted to that recipient under the terms of
|     the License.

This is the infamous anti-DRM (or anti-TPM, if you prefer) clause,
probably the most controversial part of CC-v3.0 licenses.  It has been
discussed to death on both debian-legal and cc-licenses.

The big question is: does the clause allow a licensee to distribute a
DRM-encumbered form of the work, as long as he/she also make a clean
(unencumbered) form available in parallel?
If this parallel distribution scenario is indeed allowed, then I've seen
no one objecting to the freeness of the anti-DRM clause: everyone says
that the clause meets the DFSG.
If instead the clause forbids parallel distribution, many people
(including me) think it fails to meet the DFSG.

OK, "which is the answer to the big question, then?", you might wonder.
Granted, the clause does not *explicitly* allow parallel distribution:
the Debian Creative Commons Workgroup has been pushing for such an
explicit permission in the anti-DRM clause, but the additional provision
was rejected by Creative Commons[4].  Nonetheless, some people have
hypothesized that the anti-DRM clause, as it stands, can be interpreted
as *implicitly* allowing parallel distribution.  This is indeed the big
question mentioned above.

So, once again, which is the answer?
We do *not* know, unfortunately.
Even official Creative Commons representatives refused to disclose the
intended meaning of this clause[5].
It seems that we have to wait for a court case where someone tries to
punish parallel distribution of CC-licensed works, to see some light
shed on this issue...   :-((

[4] see http://lists.debian.org/debian-legal/2006/08/msg00051.html (and
the thread that followed) for further details
[5] see http://lists.debian.org/debian-legal/2006/09/msg00155.html and,
more recently,
http://lists.debian.org/debian-legal/2007/03/msg00041.html

[...]
|     If You create a Collection, upon notice
|     from any Licensor You must, to the extent practicable, remove
|     from the Collection any credit as required by Section 4(b), as
|     requested. If You create an Adaptation, upon notice from any
|     Licensor You must, to the extent practicable, remove from the
|     Adaptation any credit as required by Section 4(b), as requested.

I'm not convinced that this clause meets the DFSG.
See my previous comments[6] if you need to read a more detailed
analysis.

[6]
http://lists.ibiblio.org/pipermail/cc-licenses/2006-November/004472.html

In summary, I don't think that a license can (allow a licensor to)
forbid an accurate credit and meet the DFSG at the same time.
I think that stating "This Adaptation is based on the Work _foo_ by
James O. Hacker" is an accurate credit, as long as it's true.
Allowing James O. Hacker to force me to purge such a credit seems to
significantly restrict my ability of modifying the work (see DFSG#3).
Why?  Because it forbids me to state a true fact in a modified version
of the work, namely that the modified version is based on the original
work by the original author.

Many licenses require that *accurate* credits be kept.  This seems to be
fine and acceptable (that is to say it's DFSG-free).  On the other hand,
if a license required *inaccurate* credit, I think it would be
considered non-free.  If this is the case, how can forbidding *accurate*
credit be considered acceptable?

Please note that I'm *not* advocating misattribution: stating the true
origin of a work (and explicitly clarifying that the original author
wrote the original work, while someone else based the adaptation on it)
is *not* misattribution.

Moreover, I'm *not* advocating the permission to hurt the reputation of
the original author: I believe that no reputation is being hurt, as long
as it's clear that the original author just created the original work,
and that the modified version was created by someone else by modifying
the original work.  

If "a credit for all contributing authors [...] appears", credit for the
licensor must be "at least as prominent as the credits for the other
contributing authors".  Even if the licensor's contribution is not
comparable to others.
I still think that this restriction is excessive and fails to meet the
DFSG.

See my previous comments[7] if you need to read a more detailed
analysis.

[7]
http://lists.ibiblio.org/pipermail/cc-licenses/2006-November/004472.html

In summary, suppose a novel is written by three co-authors who
respectively write, say, 21 chapters, 25 chapters, and N chapters, where
N is enough to grant the third co-author the author status, but still
non-negligibly smaller than 21 (maybe N is 1, or 2, or something like
that...).  In this scenario, if a credit for all contributing authors
appears, the third co-author must be credited as prominently as the
other two, which does not seem to be reasonable.

If the clause said "at least as prominent as the credits for the authors
of other comparable contributions", it would be OK, but the actual
clause doesn't say so, unfortunately.

I think that requiring excessive credit is a non-free restriction and
that crediting in proportion to the contribution (rather than
necessarily in a manner equal to every other credit) should be possible.

[...]
|  c. Except as otherwise agreed in writing by the Licensor or as may
|     be otherwise permitted by applicable law, if You Reproduce,
|     Distribute or Publicly Perform the Work either by itself or as
|     part of any Adaptations or Collections, You must not distort,
|     mutilate, modify or take other derogatory action in relation to
|     the Work which would be prejudicial to the Original Author's
|     honor or reputation. Licensor agrees that in those jurisdictions
|     (e.g. Japan), in which any exercise of the right granted in
|     Section 3(b) of this License (the right to make Adaptations)
|     would be deemed to be a distortion, mutilation, modification or
|     other derogatory action prejudicial to the Original Author's
|     honor and reputation, the Licensor will waive or not assert, as
|     appropriate, this Section, to the fullest extent permitted by the
|     applicable national law, to enable You to reasonably exercise
|     Your right under Section 3(b) of this License (right to make
|     Adaptations) but not otherwise.

I cannot understand the effect of this section: it seems to enforce
moral rights through economic rights (because it restates moral rights
in a copyright license), which sounds awkward anyway.  But it seems to
carefully avoid extending or strengthening moral rights in jurisdictions
where they are weak or almost absent, since it says "Except [...] as may
be otherwise permitted by applicable law [...] You must not distort
[...]".

Consequently: if it's a no-op, why has it been included in the license? 
If it has some effect, I cannot see which (apart from a chilling effect
on people willing to create adaptations in order to criticize the
original work or author, which is not good at all...).
Why did Creative Commons open this can of worms?

-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
..................................................... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20070708/6042fe4c/attachment-0001.pgp 