Wolfgang Denk wrote: > Dear Richard, > > In message <e1mhhue-00046l...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
