From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Grub & accessibility
Date: Sat, 18 Jul 2009 22:03:25 +0200 [thread overview]
Message-ID: <20090718200325.GB14330@thorin> (raw)
In-Reply-To: <20090712105104.r3t0ipb5lw0g84o4-cebfxv@webmail.spamcop.net>
On Sun, Jul 12, 2009 at 10:51:04AM -0400, Pavel Roskin wrote:
> Quoting Samuel Thibault <samuel.thibault@ens-lyon.org>:
>
>> (sorry phcoder for the duplication)
>>
>> Robert Millan, le Fri 10 Jul 2009 19:22:48 +0200, a écrit :
>>> We've made some exceptions, but in general, we'd like to keep the GRUB
>>> codebase made entirely of FSF-copyrighted code, or at least code we
>>> have disclaimers for.
>>>
>>> OTOH, we don't want to discard valuable work that wasn't written
>>> specifically
>>> for GRUB. Perhaps Marco or Okuji will allow an exception for this case.
>>
>> The thing is that it would be sad to re-implement these drivers, as
>> getting hardware to make sure they work is hard.
>
> One of the main advantages of Free Software is that it allows code
> sharing. For a GNU project to reject accessibility code solely because
> it's copyrighted by others would be a very bad move from the PR
> perspective.
Hi,
We're not going to reject that code, or duplicate their work. I discussed
this with Marco two days ago. He approves of the grub-extras project, and
thinks we can make this the recommended approach for situations in which we
want to import code that wasn't written specifically for GRUB.
Had I known about his position, I'd have proposed that some things like LUA
be put there. Anyhow, I look forward to more stuff being added to it.
grub-extras is integrated with the Debian package, so additions there are
merged with it semi-automatically.
I won't allow, however, grub-extras to be used as an excuse to avoid
paperwork for code specifically written for GRUB. We've had some bad
experience with uncooperative developers who refused even signing a
disclaimer (which essentially said they wrote the code themselves without
infringing someone else's copyright).
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
next prev parent reply other threads:[~2009-07-18 20:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 13:50 Grub & accessibility Samuel Thibault
2009-07-10 17:22 ` Robert Millan
[not found] ` <20090710174321.GB5471@const.bordeaux.inria.fr>
2009-07-10 18:13 ` Samuel Thibault
2009-07-12 14:51 ` Pavel Roskin
2009-07-13 21:44 ` Vladimir 'phcoder' Serbinenko
2009-07-18 20:03 ` Robert Millan [this message]
2009-07-18 20:08 ` Samuel Thibault
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090718200325.GB14330@thorin \
--to=rmh@aybabtu.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.