bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: filevercmp: worth pursuing formal copyright assignment ?


From: Bruno Haible
Subject: Re: filevercmp: worth pursuing formal copyright assignment ?
Date: Fri, 3 Oct 2008 02:04:36 +0200
User-agent: KMail/1.5.4

Hi Jim,

> You're the one who started this ;-) so I have to ask: Do you really
> think getting a formal assignment from anyone for such a small function
> (that's already been GPL'd for so long) is necessary?
>
> There is precedent with the *l.c math functions, which are copyright
> by Stephen L. Moshier and Sun Microsystems.

Oh, I wasn't aware of this precedent. It is an argument indeed.

Why am I picky about copyrights?

  - Because in the early Linux community, there was a hacker who wrote a
    shadow password library, gave it to the community, and when it was
    already in use and distributed, complained that he did not agree with
    the way it was used. H.J. had to take it out; it was quite of a mess.

  - Because the case that was so well covered by Groklaw showed us that
    even false accusations and lies can hurt us. I don't want to imagine
    a press article saying "the FSF misattributes to itself copyrights
    of code that Debian people wrote"; the effects of such a thing would
    be desastrous.

  - Because I'm a picky person, also :-)

Why am I trying to have a maximum of gnulib code covered by an FSF copyright?

  1) Because the GNU standards and RMS' policy says that essential / core
     GNU packages should be owned by the FSF. gnulib is distributing code
     into coreutils, tar, libintl, in the future maybe also GCC, etc.
     If gnulib was not 99% owned by the FSF, this would defeat RMS' policy.

  2) Because we often want to loosen the cooyright. For example, right now
     there is a request of putting the 'intprops' module under LGPLv2+. The
     author is unresponsive. If the copyright had stayed with the author,
     we would be stuck. If the copyright is with the FSF, we can ask RMS for
     the permission, and he likely will give us this permission within days.

> I'm happy to use Kamil's submission as-is, with a few small additions:
> listing provenance/spec paragraph, as Ian suggested, and previous
> authors/contributors.

I cannot object to it, given your argument about the mathl functions' code.
To be formally correct, though, please include
     Copyright (C) 1995 Ian Jackson <address@hidden>
     Copyright (C) 2001 Anthony Towns <address@hidden>
     Copyright (C) 2008 Free Software Foundation, Inc.

> Considering all the email on the subject, it might have been less effort
> overall to reimplement from scratch.

Yes, and it would have been more fun :-)

> I'd like to resolve this soon,
> because it's blocking a coreutils beta release: sort's new --version-sort
> option is affected and I want the first coreutils beta release with that
> addition to have the definitive underlying comparator.

Even if you cannot put a module into gnulib, you can put it into coreutils/gl/,
and use gnulib-tool's --local-dir option.

Karl Berry wrote:
>     think getting a formal assignment from anyone for such a small function
> 
> The function is just on the edge of being big enough to need papers if
> it were to be assigned.

it is also the core of the proposed module. I would not have been so picky
about code anyone can rewrite in a straightforward way in an hour.

> However, from what I understood, the original author works for Red Hat

Huh? Where was this said? The original author is Anthony Towns [1][2], in
July 2001. He worked for Debian for a long time. If you have records showing
that he was a RedHat employee at that time, then everything would be fine.

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2008-09/msg00434.html
[2] 
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=dba844bd36a18e6abb9e8fc6bb7eff5cb0de4347;hp=cb324560fd600a1a20cb7c930c025879c543e43a





reply via email to

[Prev in Thread] Current Thread [Next in Thread]