Re: GNU FDL 1.2 draft comment summary posted, and RFD
On Thu, Jun 13, 2002 at 09:28:09PM -0500, Branden Robinson wrote:
> If the consumer can apply a transformation to what he recives that
> perfectly restores the original, I don't see a problem.
>
> I'm not crazy about permitting degradation of quality or fidelity. That
> like saying it's okay for Hollywood to restrict our Fair Use access to
> DVDs because they also make a VHS release.
>
> And in my opinion, no, that's not okay.
I was thinking more along the lines of using prettier fonts, or "better"
lossy audio encoding schemes - e.g. should a distributor be allowed to
distribute MP3s encoded with Fraunhofer's latest best encoder if that is
not Freely available, when the user is free to use oggenc to produce a
functionally equivalent version?
Analog in code terms is "should the distributor be allowed to distribute
a binary built with Visual Studio or the proprietary Sun cc if that produces
better (faster, smaller) code, so long as it will work when built with gcc?
> > A point to bear in mind: do we want to allow the final work to be distributed
> > in a format for which there exists no free method of reproduction from the
> > provided source? e.g. MP3 as opposed to Ogg, if Fraunhofer/Thomson have
> > their way?
>
> The author is allowed to distribute in whatever format he prefers. Only
> licensees are bound by the DFCL.
Yes, so should a distributor be allowed to distribute the work in a really
handy format in which the work would not otherwise be distributed, given
that there is no Free way to create that format (say the author distributes
docbook source and pdf "binary" - should a distributor be allowed to
produce a version which is encoded using a non-free system for use on a
particular type of PDA/ebook reader/whatever, when that is the only way
to make it available for that type of device)?
> Ironically, some authors might distribute works licensed under the DFCL
> but using a lossy or proprietary format *because* that form is a pain
> the ass to modify. However, when this happens you know who to complain
> to: the author.
You mean because you're still likely to pay them to get a prettier, more
convenient form of it? That's fine - the author's choice.
> > Or more importantly, some future format which may be *the* way to
> > distribute, which is only produced by some ubiquitous new device...
> > well, like laser printers in the days before there were any free
> > fonts.
>
> The DFCL cannot impose any restrictions on the format the author uses.
> The author has monopoly power over his own work, and it is unlikely that
> any restrictions the DFCL attempted to impose on him would be upheld in
> court (who would have a cause of action to sue him?).
Again, I'm not really thinking of the original author, but later contributors
or distributors.
> The DFCL, like all copylefts, applies to those who distribute the work.
> Getting the work from a distributor has to be like getting from the
> author, as far as ease of modification goes. The *distributor*, who is
> himself a licensee, is not granted permission to obfuscate the data for
> people downstream from him in the distribution channel.
And here, I'm not talking about making it difficult to modify source, just
impossible to recreate the exact final form using Free systems.
> > I don't think I'd mind my work being put onto a DVD using CSS,
>
> And you're free to negotiate a license with a DVD producer to put your
> work on DVD using CSS and/or region coding, but it's not my intent to
> permit the producer to have that freedom with your work under the DFCL.
>
> > so long as the source provided allowed it to be put onto a "DVD" in
> > some other (Free) way.
>
> You can produce perfectly legal (both from a legislative standpoint, and
> from a technology/protocol standpoint) DVDs that are neither
> CSS-encrypted nor region-coded.
Exactly. That's why I wouldn't mind "binaries" of my movie being distributed
using DVD/CSS, so long as the source was available to enable users to
produce their own non-CSS versions. This would mean that the only way
they could gain by distributing with CSS would be if they could get better
reproduction or faster frame rates or whatever by doing it that way.
Hmmm...
> > The "no relationship" is an interesting idea.
> Hmm. What if the "no relationship" clause only applied to people doing
> distribution for monetary gain? Remember, this is an exception under
> which you *are* allowed to distribute with "obfuscation" in the stream
> (e.g., breaking the copyleft) due to circumstances beyond your control.
> You are not restricted from distributing WITHOUT obfuscation under any
> circumstances, so there isn't a DFSG 6 problem here as I understand it.
Hang on; one or other of us is getting confused between "source" and
"binary" (anyone got a better term for this in document context?) forms.
You aren't allowed to obfuscate the *source* at all. How you go about
producing the final "binary" is at issue, isn't it? So if the distributed
final form *is* the preferred form for making modifications... hmmm...
You may need to restrict later contributors from changing the source
format to one which can only be used to produce "final" output using
non-Free processes.
I'm not sure that creating a protected e-book from a docbook original
(or using non-free fonts) is necessarily Bad, but processing the docbook
into a format which is only readable by a proprietary product, and then
editing and using that to produce final output probably is - at that point
the "preferred source" format has changed, and can no longer be used by
the recipient of the final product to reproduce *anything at all*. But
then you might need to do that in order to typeset a book, for example.
I'm leaning toward "if the source you receive can be processed by a
Free system to create a final published work, then you may not change
the source format into one which cannot be so processed".
Of course, you still need to define a "Free" system. Which is Hard.
Cheers,
Nick
--
Nick Phillips -- nwp@lemon-computing.com
Try to relax and enjoy the crisis.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: