From: Robert Millan <rmh@aybabtu.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Roadmap for LUA support in GRUB
Date: Thu, 12 Nov 2009 11:38:56 +0100 [thread overview]
Message-ID: <20091112103856.GA27359@thorin> (raw)
In-Reply-To: <e763acc10911101938h131a1a0p7e4a9714e6d8d511@mail.gmail.com>
On Tue, Nov 10, 2009 at 07:38:01PM -0800, Roman Shaposhnik wrote:
> Hi!
>
> I was very excited to see Ubuntu 9.10 being one of the first distributions to
> officially switch to GRUB v2, but there was one fly in that ointment
> of happiness -- the lack of Lua scripting :-(
>
> Browsing the archives of grub-devel reveals that Lua support was moved to
> grub-extras which makes me ask these two questions:
> 1. Was the decision to move Lua based exclusively on the licensing concerns?
Hi,
Felix and Vladimir addressed some of the questions (size concerns, and the
risk to lose focus on our native scripting engine). There are some things
I should clarify though:
First of all, there's no license problem. We usually write our own code, but
when we have specific reasons to import it from another project, any license
that is compatible with GPL (v3 and later) would be considered suitable.
However, we only import code from external projects when there's an important
reason to do so. For example, we imported LZMA code because we needed the
best compression around, and we didn't want to reinvent the wheel. In the
specific case of LUA, this compromise didn't make sense to us since we already
had a scripting engine.
When we import external code, we don't ask that project to sign any paperwork
The GNU project considers it unpolite to make such requests to people who
didn't submit code to us in first place (this is documented in GCS).
The usual contributory agreement covers copyright assignment (so that FSF can
ensure code will always stay free), but MORE IMPORTANT than that is legal
assertion that the code you're submitting is your own. The reason we do this
is so that we can assure users and distributors that GRUB is a legally safe
codebase, and that they won't be affected by claims of copyright infringement
if they implement it.
--
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-11-12 10:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-11 3:38 Roadmap for LUA support in GRUB Roman Shaposhnik
2009-11-11 10:41 ` Felix Zielcke
2009-11-11 18:13 ` Roman Shaposhnik
2009-11-11 18:53 ` Vladimir 'phcoder' Serbinenko
2009-11-12 2:46 ` Roman Shaposhnik
2009-11-11 19:01 ` Felix Zielcke
2009-11-12 10:38 ` Robert Millan [this message]
2009-11-13 8:08 ` Roman Shaposhnik
2009-11-13 9:46 ` Felix Zielcke
2009-11-13 11:54 ` Vladimir 'phcoder' Serbinenko
2009-11-13 15:34 ` Roman Shaposhnik
2009-11-13 18:12 ` Bean
2009-11-13 18:29 ` Roman Shaposhnik
2009-11-13 19:06 ` Robert Millan
2009-11-13 19:34 ` Bean
2009-11-13 20:22 ` Vladimir 'phcoder' Serbinenko
2009-11-14 8:11 ` Bean
2009-11-14 12:29 ` Vladimir 'phcoder' Serbinenko
2009-11-13 20:54 ` Robert Millan
2009-12-29 4:24 ` Bruce O. Benson
[not found] ` <20100101114244.GE3692@thorin>
2010-01-02 7:35 ` Bruce O. Benson
2009-11-13 11:56 ` Robert Millan
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=20091112103856.GA27359@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.