[MPlayer-dev-eng] GPLv3 draft

Rich Felker dalias at aerifal.cx
Thu Jan 19 21:41:10 CET 2006


On Thu, Jan 19, 2006 at 07:09:55PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Thu, Jan 19, 2006 at 11:54:54AM -0500, Rich Felker wrote:
> > On Thu, Jan 19, 2006 at 04:54:01PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > i hope its not to early to flame about gplv3 ...
> > > 
> > > the first issue is that its possible to add a requirement for
> > > "functioning facilities that allow users to obtain copies of the 
> > > program's Complete Corresponding Source Code"
> > > thats obviously not reasonable for any embeded device, simply putting
> > > a CD with the source in the box is the sane solution, requireing the
> > > device to output the source somehow (USB, serial, screen, ...) is silly
> > > 
> > > now just imagine someone forks mplayer and adds this requirement :)
> > 
> > Then the person who forks it is responsible for making this
> > functionality if they want to use such a requirement, and no one will
> > use their fork. I don't see how it matters. :)
> > 
> > While in some ways I don't like this section, it very likely will
> > become an issue in the future -- companies misappropriating free
> > software meant for network/thinclient use and making proprietary
> > derivatives, and claiming they don't have to release their enhanced
> > source because they're not "distributing" the program, just allowing
> > remote use of it.
> 
> yes, but why not say something like
> every user must be able to obtain the source under the same license for
> a reasonable fee
> 
> ahh 5 pages of legealese less :)

:)
I agree, the license should not talk about a mechanism for the program
to output its source or distribute its source, but rather requiring
anyone providing access to the software for use (not just for
distribution) to also provide access to the source. Perhaps there's a
complicated legalese reason why they chose the way they did though.

> > > "No covered work constitutes part of an effective technological protection
> > > measure"
> > > so basically free software may not use DRM laws for good purposes?
> > 
> > DRM laws cannot be used for a good purpose, at least not "good" in the
> > sense of free software. I'm sure plenty people with specific other
> > agendas could think of ways to warp the DRM laws to prevent their
> > software from being used for a particular purpose they disagree with
> > (e.g. database in an abortion clinic or something); however it was
> > established a long time ago that free software cannot restrict fields
> > of endeavor or else everyone would have their own incompatible
> > restrictions based on their own causes and prejudices and no one could
> > use any aggregate free software due to all the conflicts. :)
> 
> i was more thinking about using DRM laws to protect private/sensitive 
> information instead of programs ...
> yeah encrypt and use bugfree software ... if it where that easy, someone
> just needs a little camera behind you and you loose

IIRC there was another DRM-related section I forgot to mention. The
basic problem is that someone can use GPL code and release the source,
but sign the binary with a special key needed to make the program
actually run. This totally nullifies the freedom of the software since
the end user is effectively not free to modify it or use the modified
version (for some programs using the source on a different piece of
hardware might be all they care about but sometimes, especially when
DRM is involved, you actually care about modifying and replacing the
firmware so that you can overcome the DRM).

The new clauses in the GPL v3 make it clear that the encryption keys
used to sign the binary are part of the source code (the preferred
form for modification) and thus that they must be distributed as part
of the source if they're needed to use modified versions of the
program. IMO this also is just a clarification, since these keys have
always been essential to modification (and thus part of the "preferred
form").

Rich




More information about the MPlayer-dev-eng mailing list