Skip to Content.
Sympa Menu

cc-licenses - Re: [cc-licenses] Version 3.0 - Public Discussion

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: Terry Hancock <hancock AT anansispaceworks.com>
  • To: Discussion on the Creative Commons license drafts <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: [cc-licenses] Version 3.0 - Public Discussion
  • Date: Fri, 11 Aug 2006 19:04:32 -0500

Greg London wrote:
I don't have a problem with someone playing FLOSS music on DRM
hardware. I don't have a problem with someone running OpenOffice on
Microsoft Windows.

The point is not to prohibit the use because DRM is involved
somewhere. By itself, it doesn't make a difference to protecting the
project.

Where it makes a difference to protecting the project is whether or
not someone can take OpenOffice source code, FORK it, keep the source
code private, and DISTRIBUTE an EXECUTABLE that can only be run on
WINDOWS.

That is a hole in the armor that ShareAlike should protect against.

This would allow people to EFFECTIVELY make proprietary forks, even
though the EXECUTABLE is licensed the same, it is of NO USE to anyone
who doesn't have the source.

This set of requirements appears to me to imply the "parallel distribution"
requirement: i.e. you may distribute a DRM'd version of a work as long
as you offer the plain version through the same channels.

I don't know if it's worded right in any of the draft materials or the Debian
statement, but the obvious model is the GPL's binary/source distribution
requirements (which have been tested pretty well).

One could imagine someone taking a copyleft game and porting to run
on the PSP with hardware DRM, and making only the final executable
available in non-DRM channels, holding the source code private. Now,
that's not too big an issue until that same person starts modifying
the game, and still releasing only executables that run on
proprietary hardware. The source code is unavaible to the community
who created the original project. All they get is an executable.

Of course, this is somewhat moot. Why are they using a CC license for
software? Use the GPL instead, it's much more clear cut on this issue.

GPLv3's DRM language would certainly meet your requirements here.

Do you see the proprietary fork occurring in this scenario? I need a
yes/no answer to know we're on remotely the same channel here.

What happened is that the "open source" requirement was broken,
and that's a problem of great importance in free software licenses.

Clearly, any open source license will make this illegal.

Now, I know CC doesn't recommend using their licenses for software,
but I don't think it is too far fetched to consider that there are
media applications which have intermediate formats equivalent to an
executable. Any opaque format that makes it impossible to get back to
the original media. Or any format that only operates on certain DRM
hardware.

Okay, fair enough.

I still think the parallel distribution requirement does the trick -- at
least if it's worded right. Because basically, the behavior is the same
thing that the GPL requires for source distribution with binaries.

But I'm not saying you should be prohibited from taking yoru FLOSS
project and playing it on your iPod. I'm saying that you should be
prohibited from using the DRM and DMCA and similar restrictions
around your iPod as a way to create proprietary FORKS, derivatives of
the FLOSS content that the original FLOSS creators have no access to.

If this is true, then I don't think you can favor the current DRM wording,
because I believe it DOES have a problem with you playing your music
on a platform that requires DRM encoding of the data.

At some level, this is highly artificial, because what's the difference
between a compiled executable which is difficult to reverse engineer,
but "not a technological protection mechanism" and a DRM system
which is difficult to reverse and *is* a "technological protection
mechanism".

The difference is solely in the intent -- and the DMCA makes doing
exactly the same thing illegal if the author "intended" it to be so.

That's why the GPLv3 clause saying that the work does not constitute
a TPM makes sense: the difference between TPM and mere
compilation of a source to binary is all in the mind. There is no
widely applicable technical difference (there may be lots of practical
differences between the commonly used technologies, but the only
consistent difference is that one is difficult to reverse engineer as
a incidental fact of making it easier to run while the other is
difficult on purpose (and of course it's stickier than that, since lots
of companies have been using compilation as DRM for a long time --
else why do they all come on the Python mailing list asking for
ways to "obfuscate" their code?).

That's the basic promise of protection in Copyleft: No one can create
and distribute a derivative that is unaccessible to the rest of the
project.

Right, but that happens every time you distribute an executable
without the source. The GPL solves this not by banning the distribution
of executables, but by requiring the distribution of source.

The parallel distribution idea is the same idea applied to artistic
works, with DRM encryption replacing compilation.

And my question is simply this: Does the DRM clause provide the
protection promised or not?

That hinges on the wording. But I argue that it is possible in principle,
because the GPL has been doing it successfully for years.

You can play stuff on your DRM hardware, but you cannot be allowed to
use that DRM barrier as a way to circumvent the requirement that you
share your derivatives with the original project.

I for one agree that should be the goal.

Cheers,
Terry


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





Archive powered by MHonArc 2.6.24.

Top of Page