Re: location of UnicodeData.txt

[Jim Penny <jpenny@universal-fasteners.com>]

On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote:
> On Sat, Nov 30, 2002 at 12:35:25PM -0500, Jim Penny wrote:
> 
> > > I think you are missing the points here.
> > > 
> > > First of all, DFSG applied to the standard does not want to change the standard, 
> > > but wants all to be able to change the text of the standard.
> > 
> > Huh?  If I change the text of the standard, I have changed the standard!
> 
> No you haven't, only the standards body in question can do that.

The above is in the context of people wanting to be able to change 
the unicode.txt file(s).  This file cannot be changed without producing
something that differs from the standard.  "Correcting" it produces an
artifact that is distinct from the standard.  Is that unclear?

> There are all sorts of reasons why you might wish to create derivative
> works based on the standard -- a new standard for a different purpose, for
> example. 

Derivative works are covered by copyright.  Period.  I would advise that
you not base a defense of infringment of copyright on the fact that you
have only used it to create a derivative work.

> Or helpful documentation of the standard for people who are
> intimidated by the 'dry' nature of the original...

This, on the other hand, would probably be regarded as "fair use",
especially as you would need only illustrative snippets to create such
documentation.  In normal circumstances, embedding the entire table 
in your documentation would likely not be regarded as fair use, but 
that is a fact based pattern that would have to be decided on a case 
by case basis.  In this case, it is arguable that the Unicode
Consortium's license specifically permits inclusion of the entire table,
as it does permit unlimited "extraction".

> 
> > On the other hand,  if you wish to create a competitor to the unicode 
> > standard, say the debicode standard, I see no moral right that you have 
> > to incorporate, without permission, the unicode standard.  You should 
> > expect to start from scratch!
> 
> Engage brain. Do you think that if I want to create a competitor to, say,
> GNU Emacs, that I should expect to have to start from scratch? Or fetchmail?
> Or any one of the thousands of DFSG-free packages that are in main?
> 

Brain engaged.  OK, according to you, anyone can make a competitor to
GNU Emacs and may use the GNU emacs code.  Great.  So, now consider
microsoft visual gnu emacs, which is released under the MS-EULA.  
If that seems to fail to capture your meaning, then well, suppose 
I think that the GPL sucks, and that BSD is the one true license.  
Can I the create FreeOpenBSDGNU emacs with a BSD license (as a
derivative work)?

What's that?  Oh, you mean that anyone may produce a derivative work
that is licensed in a manner compatible with the original work's license,
provided the original license specifically grants that right?  Oh.  Yes, 
I agree with that.  Stated in those terms, it is not much of a surprise.

Now, where in the Unicode license does it give you permission to create
derivative works?  The license does say "Information can be extracted
from these files...".  Oh, and you have to provide "an accompanying notice 
indicating the source".

The license does not say that any of the information in files provided
by the Unicode Consortium can be modified (except by "extraction").
This makes it fail DSFG guideline 3.

> 
> 
> Cheers,
> 
> 
> Nick
> -- 
> Nick Phillips -- nwp@lemon-computing.com
> Tomorrow will be cancelled due to lack of interest.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>