Wolfgang Denk wrote:
Dear Richard,
In message E1MHHUe-00046l-SR@fencepost.gnu.org you wrote:
Have you considered moving U-boot to "GPLv3-or-later"?
[snip]
So it seems we can set up something like a plan:
Short term goal:
Clean up the existing license conflicts in U-Boot. This is a task that is completely independent of the GPLv2 versus GPLv3 discussion - it must be done in any case.Medium term goal:
Analyze which parts of U-Boot are implemented by GPLv2-only code, and evaluate options to convert these into GPLv2+later.
From what I saw, most of the GPLv2-only code was from the linux drivers that we've adopted and adapted.
Observations: 1) U-Boot v2 is taking the approach of plug-in drivers to allow U-Boot to use the linux drivers directly.
2) While it is controversial, there is a long established precedent in the linux kernel that loadable modules with GPLv2-only incompatible licenses are acceptable.
3) U-Boot currently has an explicit license to run "stand alone applications" that have a GPL-incompatible license.
Questions: Would U-Boot be willing to have as much GPLv2++ (GPLv3) as possible, and supporting a run time plug-in system to accommodate GPLv2-only modules? If we accommodate GPLv2-only modules, will we allow proprietary modules? Depending on what we accept and how, proprietary modules may be allowed as a side effect of allowing GPLv2 modules - is that a problem?
Note that drivers are not the only potentially modular item - if we redid the command handler #defines and some glue code, I believe we could easily change the commands to being plug-in as well.
Richard, Wolfgang, U-Boot List, how do you view a "loadable module loophole" fitting in with GPLv3 (a) legally and (b) philosophically?
[snip]
Thanks a lot, Richard, for bringing up this topic.
Best regards,
Wolfgang Denk
Thanks, gvb