Development of Creative Commons licenses

[Terry Hancock <hancock AT anansispaceworks.com>]

rob AT robmyers.org wrote:
>  Quoting Terry Hancock <hancock AT anansispaceworks.com>:
> > I think the fact that GPLv3 would be as prohibitive as the proposed
> > CC-By-SA-3 language is interesting, and pretty important from
> > Debian's PoV.
>
>  I do not beliebve that this is the case. GPL-3 allows you to use or
>  write DRM. You just cannot prevent people removing it or creating
>  replacements.

You're repeating the same mistake as before. Whether you can
implement DRM under a GPL license is not the relevant point
here.

The question is whether a *GPLv3'd work* may be DRM'd.

The definition of "Corresponding Source" insists on the availability
of any keys necessary to make a binary built from the source compile
and run on the platform.  This includes whatever key or software is
needed to put a DRM wrapper on the file, if the platform is DRM-ONLY.

Due to the DMCA considerations mentioned up-thread, this information
is (well, "may be", but "is" for the same worst case "DRM Dave"
scenario that we've been discussing) illegal to distribute.

Hence GPLv3 prohibits distribution of the DRM'd version for the DRM-ONLY
platform.

But, this is precisely the same limitation that is being objected to for the
CC-By-SA-3.

So, if you released a song under the GPLv3, instead of CC-By-SA-3, you
still can't port it to a DRM-only platform.  The reason is that you cannot
provide "Corresponding Source" for it, which would be the non-DRM
song, plus the DRM key so that it can be DRM'd for the platform.  The
GPL says that if you can't distribute the source, you can't distribute
the binary.

The explanation is a little different, but the result is the same: both
GPLv3 and CC-By-SA-3 would block the kind of distribution Debian
is asking for (at least in Greg London's example case).

>  One solution for CC and Debian, based on the Scottish license
>  language that MJ Ray has mentioned, would be for CC to allow only
>  ineffective DRM to be applied. This would be DRM where blanket
>  permission to circumvent has been given *by the DRM vendor*, as is
>  included in the GPL-3.

But I think Greg has a point: anyone who's going to provide that could
more easily just let non-DRM'd media play on the platform, leaving no
reason to allow DRM at all.

>  If they still find the second draft incompatible with the DFSG they
>  are confusing "use" with "distribution" in the same way that the
>  Linux Kernel Hackers are.

That's a strong assertion (that the Linux Kernel Hackers are indeed
misunderstanding). I'm not sure Eben Moglen understands the full
impact of the new wording in the GPLv3. It's too new.

For example, he recently posted a blog claiming that certified systems
using GPLv3 could be burned to ROM instead of using Flash memory
with a hardware key. But this is a pretty fine point that is not at all
obvious from the actual language in the license. It's pretty clear to me
that providing the source to the code in ROM will not meet the
requirements of the definition of "Corresponding Source".  The FSF's
claim not to be interested in enforcing that reminds me all too much
of their claim not to be interested in enforcing copyleft against
dynamically-linked libraries and the issue of copyleft for interpreter
code and libraries.  They changed their tune once it became obvious
that they had something to gain by it. Likewise, we may expect ROM
based systems to be attacked by future enforcers of the GPLv3,
despite the present claims to the contrary.  It's the license that matters
in the end, not the blogs and commentaries.

For that matter, it's pretty clear that the FSF doesn't agree internally
about the definitions of "use" and "distribution", in the particular
kind of way that is important here. The voting machine example brings
this up. However you feel about the policies that the GPLv3 would
enforce (maybe they are wiser), the fact that the license is dictating
business models (by determining who must own and operate voting
machines, versus who might use them on contract, or provide software
as a contractual service on existing machines, etc...) is a really bad
sign.

We already have enough problems trying to fit the GPLv2 into viable
business models. Now the GPLv3 is going to trash some of those few
remaining options.  The kernel hackers have legitimate concerns. The
damage to the use cases in question may or may not be worth the
risks associated with DRM-schemes like Tivo's, but to say the kernel
hackers don't understand the license is basically a myth -- they know
exactly what the distinction between "use" and "distribution" is.

Of course, to make life harder, the GPLv3 doesn't use the term
"distribution" any more -- it invents new terms "propagate" and
"convey", IIRC.

The GPLv3 is a big, complicated can of worms about to be opened,
and to dismiss so casually the legitimate concerns of people who
have a high stake in the use of the GPL license and 15 years of
experience with the older version, is naive, IMHO.

> > Another interesting point is that people fighting the anti-DRM
> > clause (including specifically Linus Torvalds) in GPLv3 have said
> > that the GPL is the wrong place to fight DRM, preferring to apply
> > anti-DRM clauses to artistic works (as the CC licenses do), while
> > recently we've seen arguments here that the CC licenses for
> > artistic works are the wrong place (and presumeably that it's
> > better to do it in the licenses for the software?).
>
>  Do you have a source for Linus's comments? Possibly we should get
>  Linus on here?

<sigh>

I read some of Torvalds comments (on draft 2) on Groklaw. The same
sentiment has been expressed elsewhere. They feel that DRM might
be worth fighting, but not via the software license.  Elsewhere, Torvalds
was quoted as identifying the CC style ban on DRM'd content as a
better strategy.  That quote might be hard to find.

--
Terry Hancock (hancock AT AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com