Re: location of UnicodeData.txt
On Thu, Dec 12, 2002 at 01:05:07PM -0600, Steve Langasek wrote:
> On Thu, Dec 12, 2002 at 11:38:25AM -0500, Jim Penny wrote:
>
> > A) Upstream produces some set of tables that it claims are compatible
> > with unicodeData.txt, but not derived from them.
>
> > B) Upstream has a tool that mechanically takes unicodeData.txt,
> > extracts, and reformats data for use in its program. This tool is run
> > by upstream, and is not rerun at build time.
>
> > C) Upstream has a tool that mechanically takes unicodeData.txt,
> > extracts, and reformats data for use in its program. This tool is run
> > as a part of every build.
>
> > I think that if the question was ever brought up before a court of law,
> > B and C would be held to be equivalent; that is, that if under the DSFG
> > "contract", C places a package in contrib; then B also would. This is
> > NOT a question of copyright law, but only of the DSFG "contract".
>
> Careful; the Social Contract (and the DFSG it references) is not a
> legally-binding contract, it is a set of guidelines.
Notice the nicety of words here. The Contract is not a contract.
(I agree, BTW, there is no consideration.) But why did we have to use
legal language to express an non-legal idea?
> Moreover, the DFSG has *never* concerned itself with the tools used by
> authors in the creation of their free software; if B) above is a non-free
> dependency, then so is BitKeeper, so the Linux kernel has to go to
> contrib; so is the POSIX spec, so any code written that references that
> spec has to go to contrib.
Ah, but this is different. If bitkeeper went away, could the kernel be
maintained and compiled? If the posix standards were not available
on-line, could those programs be created and compiled? Clearly, yes,
both have occured in the past.
If Unicodedata.txt were no longer available, _could_ a unicode
compatible application be built? If you must have a file on hand
to begin the compilation process, then it seems that rather different
analysis applies.
Now, Debian can argue, that hey, upstream purified that for us. Had we
done it, it would have clearly thrown the work into contrib. But, hey,
we can wash our hands and say that the fact that they used this file as
a part of bootstrapping the build makes us clean. Seems a bit
hypocritical, though.
>
> > Programs using strategy A are probably DSFG free, assuming that there is
> > no evidence of fraud. But, given the complexity and magnitude of the
> > unicode standard, and that the totality of facts embodied in
> > unicodeData.txt is not available in the rest of the unicode standard:
> > if an interested party ever brought this before a judge then
> > copyright infringement would be proved.
>
> Proving that A) is a copyright infringement would require showing both
> that these tables are a derived work, and that the derivation is not
> permitted by the license on unicodeData.txt. I don't see how you would
> successfully argue that in court; permission to "extract data from the
> file" would include extracting *all* of the data from the file, AFAICT.
Agreed.
> Once extracted, you can do anything you want with that data, including
> assembling it into a new table, because copyright only covers
> the *expression*, not the data itself.
I think that the case law regarding derivative works is considerably
more flexible than this.
> --
> Steve Langasek
> postmodern programmer
Reply to: