Development of Creative Commons licenses

[Terry Hancock <hancock AT anansispaceworks.com>]

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