From: Andy Green <andy@warmcat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] GPL 2 "or later" concern
Date: Tue, 19 Sep 2006 11:46:08 +0100 [thread overview]
Message-ID: <450FCA70.3060809@warmcat.com> (raw)
In-Reply-To: <450FB804.7080601@cambridgebroadband.com>
Alex Zeffertt wrote:
> Andy Green wrote:
>>
>> Since all U-boot users who may use signatures to verify the provenance
>> of a package are in the same boat, I am wondering what the general
>> opinion about this situation is, and what the feeling would be about a
>> Linux kernel/busybox-style GPL V2-only license.
> I am curious as to what worries you about GPL v3.
>
> Is it that you wish to build a version of u-boot that will only load a
> kernel
> that has been signed with your private key?
>
> If so, then your customers will not be free to modify their kernel even
> though
> they may access its source.
>
> This seems to go against the spirit of the GPL. However, I can also see
> that
> for some products linux will only be used if it can be shown to be
> tamper proof.
Hi Alex -
My main concern is in fact updates, currently we package our updates,
including U-boot in RPMs and I intend to sign them, and check the
signature before allowing install. In this embedded device the user
does not have root access. We use RPM so we can completely and easily
fulfill the requirement for sources that match any binaries we ship by
capturing them into SRPMs.
It seems to me possible for a GPL 2 "or later" user to argue that he
should have the signing keys on the basis that he is choosing to
"modify" the code on the provisions of GPL 3, not GPL 2 and despite that
the distributor says he gave the sources on GPL 2 rules. (Last week on
another mailing list a guy was arguing that even GPL2-only code would
qualify for the same treatment, but I can't see how that can be).
Because the hardware is fixed, and the special nature of what U-boot
does, a workaround for me might be to never update U-boot, but obviously
that is less than fully desirable. That way we ship U-boot in the
flash, provide sources for it, but never distribute a signed update
avoiding the proposed potential problem.
I audited the sources for all the packages we will ship, and there is
only one other relatively small source file in net-tools that is GPL2
"or later", so I am considering making sure everything non-proprietary
we ship is GPL2-only or more liberal.
-Andy
next prev parent reply other threads:[~2006-09-19 10:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-18 18:05 [U-Boot-Users] GPL 2 "or later" concern Andy Green
2006-09-19 9:27 ` Alex Zeffertt
2006-09-19 10:46 ` Andy Green [this message]
2006-09-19 12:56 ` Alex Zeffertt
2006-09-19 19:17 ` Jerry Van Baren
2006-09-19 20:02 ` Andy Green
2006-09-19 21:11 ` Jerry Van Baren
2006-09-19 22:00 ` Andy Green
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=450FCA70.3060809@warmcat.com \
--to=andy@warmcat.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox