Subject: Re: GPLv3 draft
From: Seth Johnson <seth.johnson@RealMeasures.dyndns.org>
Date: Tue, 04 Apr 2006 06:46:14 -0400


Isn't it true that you can have complete access to and ability to
modify a set of code, but if that code calls a operation from a
hardware module that employs a key to decrypt a data file, then
the DRM system would be quite effective?

I lose track of whose "private" key is where and for what kind of
operation, but regardless, what about a hardware operation like
that?


Seth


Norbert Bollow wrote:
> 
> Bernard Lang <Bernard.Lang@inria.fr> wrote:
> 
> >   If GPL v3 forbids DRM
> 
> GPLv3 does not forbid DRM any more than GPLv2 does.  The spirit
> of DRM has always been incompatible with the spirit of the GPL,
> and the text of the GPL has always been pretty good in expressing
> that spirit.
> 
> How effective would any DRM system be at restricting your
> ability to view, copy or redistribute a data file in any way
> you please if you have the source code to the DRM system and
> the right to modify it?  In order to be effective, DRM systems
> can't be free software, and the GPL has been designed to be
> incompatible with anything that isn't Free Software.  The
> GPLv3 draft is similar to the GPLv2 in this regard.
> 
> The only differences in how GPLv2 and the GPLv3 draft relate to
> the issue of DRM are:
> 
> 1) The GPLv3 draft mentions the issue of "Digital Restriction
>    Management" explicitly.  In the GPLv2 it's implicit.
> 
> 2) If someone uses GPL'd code in violation of the license in
>    some (non-free) DRM system, the GPLv3 draft allows for a
>    cleaner way to resolve the issue that what exists with
>    GPLv2 in jurisdiction where the DMCA or similar legislation
>    is in force.
> 
> If someone creates a proprietary program using a significant
> amount of the GNU project's GPLv2-licensed code (significant
> enough that the resulting program is a derivative work of the
> GNU project code), and the FSF finds out about this, the FSF
> will generally negotiate with the transgressor, using the
> "we can get a court of law to order you to stop using our
> code" threat.  The goal and typical result of this strategy
> is that the transgressor starts complying with the terms of
> the GPL.
> 
> Before the DMCA came into force, it was possible to imagine
> that this scenario could be applied to a DRM program.  If I
> had used some GPLv2-licened code to implement a DRM program,
> the FSF would have contacted me, threatening a lawsuit if I
> don't fix my transgression, and I could have fixed it in a
> way that would be acceptable to the FSF by releasing my DRM
> program, with full source code, to all of its users, under
> GPLv2.
> 
> Now that the DMCA is in force, doing this would however not
> be an acceptable solution, because in any jurisdiction
> where the DMCA is in force, the statement "I distribute
> this DRM program under the terms of the GPLv2" is a
> contradiction in itself which does not give the recipients
> any right to redistribute.
> 
> The GPLv3 solves this problem by explicitly removing any
> program that is distributed under its terms from any
> "protection" that the DMCA would otherwise provide to any
> DRM-like features that the program might have.
> 
> I have no doubt that if the FSF failed to take action now
> with this GPL revision, over time a significant number of
> cases would arise where someone violates GPL copyleft in
> some way that is mixed up with DRM stuff.  The DMCA would
> prevent the FSF from resolving some of these issues in a
> satisfactory manner, and the result would be a significant
> legal weakening of GPL copyleft in the long run.
> 
> I draw the conclusion that the FSF's GPL revision work
> doesn't create any new problems realted to DRM, while it
> solves an existing problem related to GPL enforcement and
> DRM.
> 
> > many people, for a variety of reasons, will stick to
> > GPL v2,
> 
> This is not a problem.  If someone uses GPLv2 code in a
> proprietary software project with DRM features, and
> afterwards (possibly after a lawsuit threat from the
> copyright holder of the GPL'd code) everyone wants to
> work together to make a GPL-compatible release of the
> program and thereby get the problem out of the way, the
> solution is easy:  The GPLv2 part stays GPLv2.  The part
> which has DRM-like features in released under GPLv3.
> The rest can be under either GPLv2 or GPLv3, that doesn't
> matter.
> 
> Of course, after being released in GPL'd Free Software,
> the DRM features aren't effective DRM anymore, but at
> least the data can still be accessed, and any useful
> features that the program may have besides accessing the
> data also remain available.
> 
> > which will of course be incompatible.  Nice fork,
> > thanks.
> 
> GPLv2 and the GPLv3 draft are not incompatible.
> 
> GPLv2 is the more restrictive license.
> 
> > And, wherever DRMs are compulsory, GPL code will be excluded
> > ... thus weakening free software.
> 
> Even if I created an entire GPLv3-licensed operating system,
> with libraries and everything being under pure GPLv3 without
> LGPL or linking exceptions, people would still be free to run
> DRM programs for that OS.  They'd just have to be careful that
> their DRM program isn't a derivative work of my GPL'd code. If
> they write these programs using standard techniques for writing
> portable code, there will be no problem.
> 
> It's the same as with GPLv2, really.
> 
> Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
> 
> > the current "you sign away all patent rights for claims necessary to
> > execute the software or even mentioned in a comment"[1] anti-patent
> > clause of the draft GPLv3, into a widely-used copyleft license ...
> 
> Actually the GPLv3 draft is much better in this regard than the
> GPLv2.
> 
> Under the GPLv2 you grant an implicit patent license whenever
> you distribute the code.  This implicit patent license is
> unfortunately incompatible with many of the teeth that one would
> want to put into the terms and conditions under which defensive
> patents are licensed.
> 
> The GPLv3 draft not only makes this explicit, but it also weakens
> the GPL copyleft just enough to make it compatible with reasonably
> nasty patent retaliation threats.
> 
> In a different message, he had written:
> 
> > >>>>> "Norbert" == Norbert Bollow <nb@bollow.ch> writes:
> >
> >     Norbert> I think that there's nothing wrong with implementing
> >     Norbert> "advisory DRM"
> >
> > I think we should avoid use of such terms.  DRM is a term denoting a
> > *legal* mechanism for enforcement of restrictions.  If you don't
> > believe that restrictions on distribution should be enforced, then
> > it's best to use an alternative name for what you think is reasonable.
> 
> What I meant is a mechanism that would _advise_ me about legal
> restrictions, without trying to make it impossible for me to do
> what I shouldn't.
> 
> You're right, in order to avoid needless confusion, such a thing
> probably shouldn't be called anything that includes the letters
> "DRM".  My remarks were in the context of a discussion with Taran
> who obviously wasn't using the term "DRM" is a broader sense than
> how it's usually employed, and I was trying to come to an
> understanding with him about what he means.
> 
> Greetings,
> Norbert.

-- 

RIAA is the RISK!  Our NET is P2P!
http://www.nyfairuse.org/action/ftc

DRM is Theft!  We are the Stakeholders!

New Yorkers for Fair Use
http://www.nyfairuse.org

[CC] Counter-copyright: http://realmeasures.dyndns.org/cc

I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.