[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CC's responses to v3draft comments



On Sep 27, 2006, at 18:14, MJ Ray wrote:

Henri Sivonen <hsivonen@iki.fi> wrote:
But is it good for Free Software to be ported to platforms that have
been designed to deprive both developers and end users of freedom?

Yes, as long as a mutable copy is available to developers and end
users, because it widens the audience who will see free software
and may become interested in its development and advancement.

The mutable copy doesn't help much if the platform is designed to refuse to run modified versions.

I think saying no would be arguing against porting free software
to Microsoft Windows, which is a platform designed to deprive both
developers and end users of freedom when it increases revenue for
Microsoft - see the current moves that lock out third-party
security software, for example, or the DRM features, or product
activation keys.  However, free software on Microsoft Windows is
many (most?) users' introduction to free software.

If you get the source of e.g. Firefox or Gimp and modify the source and recompile for Windows, Windows will still run your own versions without you having to ask Microsoft to sign your binaries.

TPM-bans are a sort of digital Iron Curtain - these platforms may
have this free software; those ones may not.  It's tactically
stupid too - the population on "our" side of the Iron Curtain is
not yet sufficiently compelling to deter more neutral platforms from
joining the other side.

Are you sure? The existing collection of free software is already so valuable that companies choose to build products on it complying with the licensing terms.

Also, what good it is to have population on "our" side if they aren't de facto able to exercise freedom because the platform owner refuses to bless their modification?

If a gaming platform requires FooBigCo to sign software before it
runs, exercising freedom as in Free Software on that platform is de
facto prevented on a desert island.

Depends if the FooBigCo platform is the only platform on the island,
but discussing desert islands too much usually brings a d'Itri-flame.

If I want to fix a small thing, I should have the freedom to install and run my replacement version on the *same* platform as the original. I shouldn't have to acquire a substitute platform and port to it to exercise my supposed freedom.

However, if an iSuck player only
played TPM files but anyone could convert non-TPM files to TPM files
privately, requiring distribution to happen in a non-TPM format and
requiring iSuck owners to apply TPM themselves wouldn't be any more
onerous than the GPL allowing certain action only in private.

Indeed.  Sadly, CC's anti-TPM language may(*) prohibit iSuck owners
applying TPM themselves, as the copy would violate the licence and the
anti-TPM measure is not limited to distribution. (* - it's not entirely
clear to me, due to the recent comments and refusal to explain.)

I am in no way advocating any language that would prohibit the application of TPM in private. I think recipients of copies of works should be allowed mash the works any way they wish in private.

I find it strange that Debian is so vigorously defending this fringe
use case.

Why?  Many debian developers want to copy all sorts of things to all
sorts of media in all sorts of ways.

Because I thought Debian developers were more of a GPL crowd interested in protecting downstream freedom than a BSD crowd interested in their own freedom to do whatever.

The anti-TPM language is designed to limit the freedom of a
middle man so that the middle-man isn't allowed to limit downstream
freedom.  GPL is precedent that it can be free in the DFSG sense to
limit the freedom of middle-men so that they aren't allowed to limit
downstream freedom.

One could only appeal to the GPL precedent if the anti-TPM language
allowed parallel distribution, else it is also limiting the freedom of the end user to get the TPM-encoding service from a middle-man if they choose. It is obviously possible to let users get TPM-encoding from a middle-man
without letting them give up their freedom, just as you can get GPL'd
binaries from someone else.

Does the GPL allow you to buy GNU readline integration service for e.g. AFPL Ghostscript from a middle-man? I don't think so. Still, you can do the work in private.

Since the CC licenses don't require distribution of the preferred
form for making modification aka. source code, it is essential that
downstream recipient can extract works for modification and
redistribution without violating any law that protects TPM. I think
that it makes sense for CC licenses to have anti-TPM language and I
don't think that anti-TPM language should make a license non-free.

Should we accept as free software a program under a licence which does
not allow licensees to distribute compiled files?

No, but disassembly and decompilation is even specifically allowed by law in some cases. And when the law doesn't specifically allow it if the license allows it, a prosecutor won't come after you.

The correct way to fix this is for CC to require source code, not
prohibit compiled code.

That is currently impractical with music and movies.

(More on this: http://hsivonen.iki.fi/free-anti-drm/ )

I feel that essay contains lies such as "The entire purpose of DRM
[...] is to incarcerate a work and to deprive the recipient of the work
of the freedom to do things with the work without contrived technical
barriers"

So what is the purpose of DRM if not to create contrived technical barriers that limit the freedom of whoever receives a copy of a work?

and "entangling a work in DRM puts the recipient at the risk
of criminal prosecution if he exercises his freedoms otherwise granted by
the license".

How is that a lie? Where I live, in some cases, circumventing TPM is a crime prosecutable by a general prosecutor, distributing tools for circumventing TPM is a crime and organized discussion about circumvention may be illegal, too. The first case is being considered by a prosecutor--no court precedent, yet.

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/




Reply to: