[U-Boot-Users] [PATCH] add 'license' command to u-boot commandline

[Harald Welte]

Hi Wolfgang!

On Sun, Jul 06, 2008 at 12:11:05PM +0200, Wolfgang Denk wrote:

> in message <20080706075219.GC4167 at prithivi.gnumonks.org> you wrote:
> > 
> > [PATCH] add 'license' command to u-boot command line
> > 
> > The 'license' command includes the u-boot license (GPLv2) into the actual
> > bootloader binary.  The license text can be shown interactively at the u-boot
> > commandline.
> 
> When we started working on this boot loader (by then still under  the
> name  8xxrom  or  maybe already PPCBoot, I don't remember exactly any
> more) we decided not to implement such a feature because  of  (flash)
> memory footprint reasons.

Well, the same argument holds true for many other of u-boot's features.
However, they still get implemented, and the compilation/inclusion in
the (flash) image therefore is optional.  Users who don't want it, get
zero additional benefit.

> I still feel this is pretty heavy in terms of memory footprint versus
> benefit ratio.

that is probably from your point of view.

While I was working for OpenMoko, from a vendor perspective of a company
that wants to make 100% sure that the GPL is always followed, this kind
of feature makes a lot of sense.  Even if you just put a u-boot binary
on some ftp server (without the GPL text next to it) you still don't
risk any GPL infringement.

> > For products where the commandline can actually be accessed by the end user,
> > this helps to prevent inadvertent GPL violations, since the GPLv2 license text
> > can no longer be 'forgotten' to be included into the product.
> > 
> > The 'license' command can be enabled by CONFIG_CMD_LICENSE.
> 
> Well, I bet 9:1 that some vendors (and I guess you and me know a  few
> of   them   pretty   well)   may   simply   "forget"  to  enable  the
> CONFIG_CMD_LICENSE option, or they ship  U-Boot  in  a  configuration
> where access to an interactive console interface is difficult or even
> impossible (completely unintentionally, of course).

this is perfectly true.  I'm not saying that this patch is a
fire-and-forget solution for all device manufacturers.  I'm simply
saying that this solved a practical problem for OpenMoko.  It's a
straight-forward patch that doesn't impact any existing code or files,
and it comes at zero footprint impact if you don't want it.

> So the benefit in such cases is really small,  especially  since  the
> License  text  cannot  be  found  easily in the binary image (as it's
> compressed).

well, it's supposed to offer the license text at the command line, not
in the memory image..

> So I have to admit that I'm realy biased here. Let's see what other's
> say.

Ok.  I'm also waiting for the feedback of others.  Please keep in mind
tha this is a zero-maintenance patch that doesn't affect any existing
code.  So even while you might think the feature is esoteric, it is a
very painless feature to add.

> But I definitely object against such a binary, i. e. unreadable copy
> of some license which nobody can check, and which quickly gets out of
> sync with the COPYING file included with the source code.
> 
> If we add such a command, I insist  that  the  included  (compressed)
> licenzse  text  must  be  generated on the fly from the COPYING file,
> i. e. I will reject all attempts that cause two (probably  different)
> copies of the license text included with U-Boot.

Ok, I agree.  Let's wait for the further comments on the list.  If I
have the feeling that such a feature would be accepted, I'll re-work the
patch to include a script and makefile hooks to generate the header file
with the compressed license text on-the-fly while compiling u-boot.

Regards,
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080706/e4c09efd/attachment.pgp