I have been a Debian user for several years now, an occasional free
software developer, and a user of the Creative Commons By-SA license, so
I have been following the effort to make the CCPL3.0 comply with the
Debian Free Software Guidelines with some interest. I used to post here
on debian-legal occasionally, and I've rejoined to discuss this issue.
I am not a lawyer. I apologize for the length of this post, but it is
summarizing the conclusions of quite a large discussion (which I
promised to the Debian folks who joined the conversation there that I
would provide here).
The case has been made that CCPL3.0 is DFSG-non-free because it does not
allow the distribution of content in TPM'd format[0]. I assert that not
only is this argument false, it is actually reversed: allowing TPM
distribution, even with parallel distribution of non-TPM versions of the
same content actually permits a violation of the DFSG, specifically item 3:
"""
*Derived Works*
The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software.
"""[1]
I interpret this to be an alternate wording of the same rule described
as "Freedom 1" of the Free Software Definition:
"""
The freedom to study how the program works, and adapt it to your needs
(freedom 1). Access to the source code is a precondition for this.
"""[2]
Debian's determination that parallel distribution of non-TPM files
alongside TPM files will solve this problem is based on the FALSE idea
that binary/source distribution is analogous to TPM/non-TPM distribution.
This analogy has been cited multiple times in the discussion on
debian-legal, but I am not able to find much serious analysis of this
assumption. It is a seductive idea, and I have to admit that I was sold
on it myself for quite some time.
However it misses the most critical point about TPM systems, which is
that they acquire their force not from "technology" (despite the name),
but from "law". It is not truly the fact that TPM is difficult to
reverse that is the problem, but rather that it is ILLEGAL to do so.
Moreover, it turns out that the most serious problem occurs not because
it is difficult/illegal to *remove* TPM, but because it is
difficult/illegal to *apply* TPM (counter-intuitive as that may seem).
A system which applies encryption, but is not enforced under law is NOT
a "TPM" in the legal sense of the word, and is therefore not "being used
to restrict" a work (legally).
For example, any "TPM" system licensed under the new GPLv3 (d2), will
not actually be a TPM in the legal sense, because the license expressly
declares that it is not. This *technically identical* software is
nevertheless *legally distinct*. We might call this a "Non Legal
Technological Protection Measure" or NL-TPM system.
For such an NL-TPM, Debian's parallel distribution idea *might* apply
(there is still a subtle problem, but it is much less severe), but this
is not what "TPM" is under law. TPM is something that has the force of
law backing it up. In the United States, this means that circumventing
the TPM is a violation of the DMCA. Other countries are adopting similar
rules, which is, of course, the basis for so much concern over TPM.
Another assumption that is typically made about binaries is that
creating them from source is a complex, error-prone process that
requires expert skill. This is what drives the practical necessity of
distributing binary versions of free software packages. TPM, however, is
always trivial to apply, provided the correct encryption keys are
available. It is only the secrecy of the keys and the laws protecting
their secrecy that interferes with the application of TPM to content.
Because of this, having to apply your own TPM is hardly a burden -- in
fact the process can be automated to the point where you would not even
realize that it is being done (e.g. it could be part of a download
client). Once again, the issue is *not* technical, but legal: you may be
required to agree to (non-free) terms to apply the TPM to content. This
effectively never happens with binaries: even if sources are designed to
be compiled with a proprietary compiler, it is always legal to write a
new compiler which does the same job. But with a "TPM compiler", that
compiler is illegal to write (it's a "TPM circumvention device").
Now, having hopefully dispelled the myth that binary/source is analogous
to TPM/non-TPM, I will relate the problem case (originally presented by
Greg London on the cc-licenses list [3], I'm just outlining it here):
1) Sam releases a work A under By-SA w/ parallel-distribution allowance.
2) Dave, owner of a TPM-only platform, wraps work A in his TPM wrapper
to create d[A].
3) Under "parallel distribution" rule, Dave can now sell d[A] through
his channel, so long as he also provides A.
4) Dave may choose to alter the work to create A', and wrap that to
create d[A'] which he may also sell (Dave has the right to modify and
distribute).
5) Bob downloads work d[A] and likes it. He decides that he wants to
create a modified version, A'' which he will (due to the platform's
TPM-only nature) need to wrap to create d[A''] so that he can play on
the platform Dave owns.
6) Bob can download the non-TPM work, A. He can modify it to create
A''. But he has no key to create d[A'']. Nor does anything we've done
require Dave to give him that key! Bob's freedom to modify and
distribute has been eliminated by Dave, in a clear breakage of copyleft.
So Dave has secured a platform monopoly on Alice's work. He is able to
charge for it under monopoly terms exactly as if he were the copyright
owner. He is not required to distribute the work in a form that allows
others to modify it and play it on his platform. He has managed to
effectively revoke the users' "freedom 1", making the work non-free.
Now, if you pay close attention, you can also see that this is basically
identical to the problem of "tivo-ization": we need a special key, which
has been withheld, in order to exercise our freedom to modify and
distribute. The GPLv3d2 attempts to rectify this problem by defining
that key as part of the "corresponding source" for the work.
This is equivalent to demanding that Dave release his encryption key (or
provide an alternate key) to be used to encode works to play on his
platform. But note that this is (from Dave's point of view) no more
difficult than making his platform run non-TPM'd works. In fact, one
way to implement that is to make a TPM-key-wrapper a part of his platform.
So, if Dave wanted to create a TPM-only platform in the first place,
he's not going to release the encryption key. Requiring him to do so is
no less onerous than just asking him to let non-TPM works play on his
platform.
Furthermore, if such a key is published, Bob may use the published key
to TPM his own private copy of A'', and so may all users who receive
A''. IOW, having the key allows the platform to be freed to allow
content to play on it, so it is not effectively TPM'd any more (or, in
fact the TPM is no longer a TPM once the key has been published). In
any case, it is no longer being used to restrict the content, so the
anti-TPM clause in CCPL3.0 no longer applies to it.
So, in my opinion, the GPLv3d2 "Corresponding Source Key" clause is
roughly equivalent (at least in effect) to the CCPL3.0 "anti-TPM"
clause, because it is a key necessary to view the content on the
platform. IOW, if you were to release the same content under the
GPLv3d2, the same results would happen: Dave would be barred from
publishing the work on his TPM-only platform, unless he pubishes the TPM
key (which then makes it no longer a TPM-only platform). Now, of
course, Debian hasn't approved GPLv3d2 either, but I think it's relevant
that the Free Software Foundation and the Creative Commons have both
come to the same terms on this issue: TPM used to make it impossible to
play a derivative work on a platform is a violation of users' freedom.
In any case, it's pretty clear to me that it would be inconsistent to
recognize GPLv3, but not CCPL3 on this point, since they are actually
effectively making the same requirement.
In my opinion, Debian has reasoned incorrectly about this issue, based
on a compelling, but false assumption that the 15+ years experience with
binary/source parallel distribution can be applied to TPM/non-TPM
parallel distribution. It was a nice thought that that should be so --
but it doesn't hold up to close scrutiny. There really is a difference,
and for free-licensed cultural content, the CCPL3.0's anti-TPM
distribution clause is the only practical solution.
On a related note, I should mention that CC has decided to clarify the
language to make it more obvious that it is only the *distribution* of
TPM'd files (not private copying) that is forbidden. There is a strong
feeling that fair use already permits this, and that the existing
wording already makes this true accross jurisdictions, but that it
should indeed be made more explicit (this is my understanding from Mia
Garlick's responses to the list commentary).
As a Debian user, I am furthermore concerned that continuing to push for
a TPM+parallel distribution clause will damage the freedom of the Debian
distribution and free software / free culture in general, because it
will encourage exactly the kind of exploitation that Dave exhibits in
the example above: it provides an incentive to exploit existing works
commercially while removing any incentive to create (and for many, even
the ability). It's a very wicked poison to the free/copyleft
development community, and all the more deadly for its relative
invisibility. Please don't let this happen over a such a basic
misunderstanding!
Anyway, that's my case both for accepting the CCPL3.0 w/o the parallel
distribution clause, and also for generally considering the parallel
distribution not to be required for "DFSG freedom". Thanks for reading.
Cheers,
Terry
[0] TPM="technological protection measures" it's synonymous with DRM in
a legal context (There was a bit of red-herring awhile back in which it
was suggested that "digital rights management" would refer to the
management of metadata about the rights on a file. In a sane world
perhaps, but this is not what it means in licenses)
[1] http://www.debian.org/social_contract
[2] http://www.gnu.org/philosophy/free-sw.html
[3]
http://lists.ibiblio.org/pipermail/cc-licenses/2006-September/004130.html
--
Terry Hancock ([EMAIL PROTECTED])
Anansi Spaceworks http://www.AnansiSpaceworks.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
