Re: location of UnicodeData.txt
On Mon, Dec 02, 2002 at 07:30:57PM +0200, Richard Braakman wrote:
> On Mon, Dec 02, 2002 at 11:16:07AM -0500, Jim Penny wrote:
> > On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote:
> > > 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.
>
> Umm, yes. That's exactly why the text of a standard should be free.
> You seem to be confusing the "should be" and "is" discussions.
>
> > > > 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.
>
> You seem to have hit the wrong button when you tried to engage your brain.
> Why would "create a competitor" have to mean "create a competitor under
> a conflicting license"? The GNU Emacs license allows you to create a
> competitor without starting from scratch. That is what makes it free!
The question above did not specify that the competitor was to be GPL
licensed. In the universe of GPL licensed programs, you are indeed free
to create a competitor using code incorported from GNU emacs; in fact,
the universe of DFSG licenses was specified. In the universe of DFSG
licensed programs, you are not free to create a competitor
using incorporated code, in particular, you cannot create a BSD licensed
version of GNU emacs using derived code.
(And if BSD licenses were allowed, then so would the MS-EULA license,
by "washing" the GPL through the BSD license.)
>
> > 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.
>
> I don't think he meant that at all. You're confusing "may" with "should
> expect to be able to". The whole "provided..." clause misses the point.
> Laws do not define morality.
This is straying terribly far from field, but are you saying that it is
morally correct that the debian project modify standards without
permission of the standards body? Or that it is morally correct to
incorporate (portions of) other programs in your work unconditiontally
and without permission of the original creators? Are you saying that if
the FSF brings a suit alleging GPL violation, that this suit is immoral?
If your answer to any of these is yes, then your morality is very
different from mine.
>
> Now, why do you think that it would not be a good thing for the text of
> the text of the Unicode license to be free? Your only answer so far
> seems to be "because it currently isn't".
1) that is a good enough answer to make a determination on whether it is
part of non-free, contrib, or main.
2) It is an embodiment of years of work by many people who did not
agree that it should be free (in DSFG terms).
3) I can think of no value in a standard that is DFSG free. The
purpose of a standard is to ensure interoperability. If there first has
to be a discovery phase to determine how my "standard" deviates from
your "standard", interoperability is reduced if not destroyed.
This is not to say that standards should not permit extension. Most do.
However, even this has been controversial in the past (Microsoft
Kereboros, for example).
Jim Penny
>
> Richard Braakman
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: