Hi Scott,
On Tue, Jun 23, 2009 at 06:33:53PM +0200, Detlev Zundel wrote:
Also this is one of the objections worded on the mailing list, namely that such a cooperation will be impossible in the future if U-Boot moves to GPLv3.
As a base for reasonable discussion, I think we need to evaluate those claims and back them up by actual figures. Only then the real effort needed to move and the potential loss of "code immigration" can be estimated.
The NAND subsystem is from Linux and is GPL v2 only, as is the u-boot-specific NAND code in drivers/mtd/nand.
Ok, thanks for that info. Subtracting the drivers this is ~5k LOC, right?
nand_ecc.c is an exception, which not only has the "or later" language but also has an exception that makes it non-viral.
Why do you refer to one of the most important aspects of the effectiveness of the GPL as being viral? GPLd software neither attacks nor infects software so the wording is actively misleading.
env_nand.c is v2-or-later. cmd_nand.c has no explicit license.
In summary: If you switch to v3, you lose much of NAND. Unless RMS volunteers to rewrite it. :-)
Is there any chance of convincing those authors to change that?
Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be "a neccessary precondition to only accept blessed firmware upgrades" (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades.
Regardless of what motivates it, people who sell hardware to such customers (and who also contribute to u-boot) may not want to risk losing that business by pushing GPLv3 on them.
Actually I want to understand why people fear to "loose business" with GPLv3. What is the exact scenario that is so threatening? Unless this is understood, it is hard to argue in any way.
Cheers Detlev