Development of Creative Commons licenses

[drew Roberts <zotz AT 100jamz.com>]

On Saturday 30 September 2006 02:15 am, Terry Hancock wrote:
> 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.

So, I have not kept the fine details in my head lately but I will state it 
again another way to try and help clarify and wait for corrections.

The GPL-3 addresses DRM from two points.

1. GPL-3 code cannot be incorporated into a DRM system that is put forth by 
its maker as being "an effective TPM" as per the DMCA.

2. The GPL-3 also contains language that would prevent a TPM/DRM system 
containing (made from) no GPL-3 code whatsoever from being used to "protect" 
GPL-3 code unless keys were provided such that those getting the platofrm and 
code can mod the code and sign and run the modded code on the platform.

Is that about it for the intended effects and not the possible side effects?
>
> 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.

I am not so sure the kernel guys have such a high stake in the GPL3. Some 
seem 
to think that they can't put the kernel under the GPL3 even if they wanted 
to. At least without (major?) re-writes due to code contributed by people who 
will not go along or who can't be found, or who are dead...
>
> > > 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.

-- 
(da idea man)
http://www.ourmedia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedia.org/user/17145