Re: [U-Boot] U-book and GPLv3?
Dear Richard,
In message E1MHHUe-00046l-SR@fencepost.gnu.org you wrote:
Have you considered moving U-boot to "GPLv3-or-later"?
I apologize for the late reply, but I have been on vacation and completely offline for more than two weeks. But as I saw you got well involved in the discussion on the U-Boot mailing list that resulted from my forwarding your question to the list, trying to get an understanding what the U-Boot community is thinking.
Now about your question: yes, I have considered moving U-boot to GPLv3. I have to admit that I don't understand all the consequences of GPLv3 yet; I am not a lawyer, and it took me long enough to get a somewhat thorough understanding of what GPLv2 means - the basic ideas, it's application in real live including it's interpretation by layers in different (US and German) legal systems, and some of it's deficiencies. It will take me some time to get equally familiar with GPLv3. Fact is, that I don't like the idea that somebody can take the code I've been developing as Free Software for the last 9 years and use it in a device in such a way that I cannot modify my own code any more even when the vendor strictly complies with the license (GPLv2). This fact alone is reason enough for me to strive for moving U-Boot to a license that prevents such usage models - i. e. going GPLv3.
But let's first have a little look at the discussion of this topic on the U-Boot mailing list - it must be one of the longest threads we ever had:
Discussion on U-Boot Mailing list from: Thu, 18 Jun 2009 16:51:28 CEST through: Sun, 5 Jul 2009 12:14:18 CEST = 17 days
References: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/61801 http://lists.denx.de/pipermail/u-boot/2009-June/054540.html
Total postings: (including initial posting): 143
Number of different posters (including initial posting): 21
Current number of subscribers: 1712
Posters, Number of Postings, Percentage, and Total: ------------------------------------------------------ Richard Stallman : 32 = 22.4% [ 22.4%] Detlev Zundel : 24 = 16.8% [ 39.2%] Mike Frysinger : 23 = 16.1% [ 55.2%] Robin Getz : 10 = 7.0% [ 62.2%] ksi@koi8.net : 7 = 4.9% [ 67.1%] Thomas Doerfler : 7 = 4.9% [ 72.0%] Scott Wood : 6 = 4.2% [ 76.2%] Jean-Christophe PLAGNIOL-VILLARD: 6 = 4.2% [ 80.4%] Jean-Christian de Rivaz : 6 = 4.2% [ 84.6%] Jon Smirl : 5 = 3.5% [ 88.1%] Jerry Van Baren : 5 = 3.5% [ 91.6%] Pink Boy : 2 = 1.4% [ 93.0%] Grant Likely : 2 = 1.4% [ 94.4%] Wolfgang Denk : 1 = 0.7% [ 95.1%] Matthew Lear : 1 = 0.7% [ 95.8%] Larry Johnson : 1 = 0.7% [ 96.5%] Graeme Russ : 1 = 0.7% [ 97.2%] Frank Svendsbøe : 1 = 0.7% [ 97.9%] Eric Nelson : 1 = 0.7% [ 98.6%] Chris Morgan : 1 = 0.7% [ 99.3%] Arno Fischer : 1 = 0.7% [100.0%]
More than 50% of all postings - 3 posters More than 60% of all postings - 4 posters More than 70% of all postings - 6 posters More than 80% of all postings - 8 posters More than 90% of all postings - 11 posters
Posters, Vote, Role (commits since 2006-01-01), Reasoning: [Total commits since 2006-01-01: 5845 by 314 Authors]
Richard Stallman : pro software freedom activist defend users' freedom Detlev Zundel : pro developer (38) defend users' freedom Mike Frysinger : con developer, custodian (311) Some customers don't want to let users run modified code. Robin Getz : con developer (1) Many organizations which require this, some from a legal standpoint, some from a certification standpoint ksi@koi8.net : con developer (5) sometimes regulations require secure boot Thomas Doerfler : no clear statement - con lurker, never showed up before (0) fears that GPLv3 would prevent use in "many possible applications" Scott Wood : no clear statement - con developer, custodian (48) fears that GPLv3 would result in a fork Jean-Christophe PLAGNIOL-VILLARD: con developer, custodian (320) "I've the same opinion as Linus Torvalds" Jean-Christian de Rivaz : no clear statement - pro lurker, never showed up before (0) some arguments pro GPLv3 Jon Smirl : no statement developer (5) fears the amount of effort needed to go GPLv3 Jerry Van Baren : no clear statement - pro developer (56) points out the current situation and the effort needed Pink Boy : pro mostly lurker, 15 postings before this thread (0) none of the people involved in product safety care about GPL Grant Likely : con developer (63) "Personally not interested. I don't want to license my code under GPLv3" Wolfgang Denk : pro (*) project maintainer (635) defend users' freedom Matthew Lear : no clear statement - con? developer? (0) fears that publication of security features might result in "a rather large security flaw" Larry Johnson : no statement developer (38) - Graeme Russ : no clear statement - con? developer (21) "there are cases where GPL3 went just a little too far" Frank Svendsbøe : pro developer (1) Keep fighting for freedom Eric Nelson : no statement developer? (0) - Chris Morgan : no statement developer? (0) - Arno Fischer : con developer? (0) just agrees with another con-posting, no own reasons
(*) I did not participate in this discussion yet - mostly because I was on vacation and strictly abstinent from any Internet access, but also because I wanted to get an uninfluenced picture of the situation.
So here goes my statement: if I own a device that is running any Free Software, and I decide I want to hack it, I want to able to do this. I accept all the arguments about safety and certifications and such, but in my opinion this has actually nothing to do with allowing me to change the code or not. If it's based on Free Software, that software must remain free. I don't want to see my own code, which I released under a Free Software license, being used in a device such that I cannot even fix my own bugs any more.
I am definitely _pro_ going for GPLv3. I am also realizing the efforts and the time this will take.
Observations: =============
1) If we take into consideration that you are not subscribed to the list, only 20 out of 1712 subscribers (less than 1.2%) bothered to comment at all.
2) Some of these 20 posters did not take a firm stand whether they are pro or con moving to GPLv3; an unweighted count gives 6 more or less clear votes pro GPLv3 versus 10 votes against such a move.
3) It seems reasonable to me to add some weight to these votes, taking into consideration how much the posters actually contributed to the U-Boot project.
Since Jan 01, 2006 we had a total of 5845 commits by 314 authors.
The "pro"-voters add up to a total of 730 commits (12.5%), while the "con"-voters have 769 commits (13.2%).
4) There is a repeating pattern in the arguments against GPLv3: some customers/vendors intentionally want to lock down their users, and moving U-Boot to GPLv3 might mean that we lose these customers. Various reasons are listed, but usually they boil down to legal requirements [which usually translates into guidelines issued by the business management], security and certification requirements. In all these cases, little or no seizable facts are provided.
Current Status: ===============
It is a known fact, that we have not always been careful enough to check licensing terms of all contributed code. In the result, the current U-Boot code base contains a number files with licenses that are incompatible with the GPLv2 (or later) which is the intended license for current U-Boot versions. This has been addressed with commit 78237df5, see "doc/feature-removal-schedule.txt":
---------------------------
What: GPL cleanup When: August 2009 Why: Over time, a couple of files have sneaked in into the U-Boot source code that are either missing a valid GPL license header or that carry a license that is incompatible with the GPL. Such files shall be removed from the U-Boot source tree. See http://www.denx.de/wiki/pub/U-Boot/TaskGplCleanup/u-boot-1.1.2-files for an old and probably incomplete list of such files.
Who: Wolfgang Denk wd@denx.de and board maintainers
---------------------------
Checking the code base using the Open Source License Checker V.3 (see http://forge.ow2.org/projects/oslcv3/) gives this result:
-> java -jar oslc.jar -x /home/wd/git/u-boot/master/.git -s /home/wd/git/u-boot/master
Source files: 4117 License files: 1 All files: 6178 Distinct licenses: 11 Conflicts (ref): 435 Conflicts (global): 34
License Count Incompatible with all_rights_reserved-f 285 apache-1.1 apache-2.0-s gpl-2.0-l gpl-2.0-only-s gpl-2.0-s lgpl-2.1-s mpl-1.1-s nokos-1.0a-s apache-1.1 163 all_rights_reserved-f gpl-2.0-l gpl-2.0-only-s gpl-2.0-s lgpl-2.1-s mpl-1.0-s mpl-1.1-s nokos-1.0a-s apache-2.0-s 1 all_rights_reserved-f gpl-2.0-l gpl-2.0-only-s gpl-2.0-s lgpl-2.1-s mpl-1.0-s mpl-1.1-s nokos-1.0a-s bsd 170 gpl-2.0-l 1 all_rights_reserved-f apache-1.1 apache-2.0-s mpl-1.0-s mpl-1.1-s nokos-1.0a-s gpl-2.0-only-s 196 all_rights_reserved-f apache-1.1 apache-2.0-s mpl-1.0-s mpl-1.1-s nokos-1.0a-s gpl-2.0-s 3007 all_rights_reserved-f apache-1.1 apache-2.0-s mpl-1.0-s mpl-1.1-s nokos-1.0a-s lgpl-2.1-s 16 all_rights_reserved-f apache-1.1 apache-2.0-s mpl-1.0-s mpl-1.1-s nokos-1.0a-s mpl-1.0-s 2 apache-1.1 apache-2.0-s gpl-2.0-l gpl-2.0-only-s gpl-2.0-s lgpl-2.1-s mpl-1.1-s 5 all_rights_reserved-f apache-1.1 apache-2.0-s gpl-2.0-l gpl-2.0-only-s gpl-2.0-s lgpl-2.1-s nokos-1.0a-s 5 all_rights_reserved-f apache-1.1 apache-2.0-s gpl-2.0-l gpl-2.0-only-s gpl-2.0-s lgpl-2.1-s ->
We have a lot of files with licenses which conflict with GPLv2 (and later); if the OSLC results are correct, there are 461 such files (7.5% of all files) - these must be cleaned up in any case.
Compared to that, the 196 "GPLv2 only" files (3.2% of all files) seem to be an easier task, but this may be a delusion - most of the con- flicting files above are strictly board-specific code, and the worst thing that can happen is that we just remove these files (if the respective board maintainers cannot or do not want to provide fixes), which would result in a number of boards breaking, without any signi- ficant impact on the majority of the supported boards. The "GPLv2 only" files are mostly global code that is related to important features of U-Boot, so just dropping these is not an attractive solution. On the other hand, it should not be that hard to analyze which features are affected, and eventually isolate these. Then we might evaluate what we'd lose when going GPLv3 anyway.
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.
Long term goal:
Move U-Boot to GPLv3.
All in all I must say that the whole discussion reminds me pretty much to the situation back 10 years ago when I started trying to use GNU/Linux for embedded systems. By then, it usually took long discussions and lots of convincing both on engineering and especially on management levels to get a Linux based solution accepted for a real-life industrial project. The arguments then were pretty much the same we hear today: systems would be less secure when everybody can read the code, intellectual property would get lost to competitors, it would be impossible to get the required certifications, and so on and on.
And what happened? Today we see GNU/Linux systems everywhere, inclu- ding safety-critical applications that require certifications, and including communication devices (like mobile phones) that need to pass approval procedures, homologation testing etc.
I am convinced that time will work for GPLv3 acceptance.
Thanks a lot, Richard, for bringing up this topic.
Best regards,
Wolfgang Denk
On Mon, Jul 6, 2009 at 6:55 AM, Wolfgang Denkwd@denx.de wrote:
Dear Richard,
In message E1MHHUe-00046l-SR@fencepost.gnu.org you wrote:
Have you considered moving U-boot to "GPLv3-or-later"?
If u-boot goes GPLv3 it will simply cause the people that need secure boot to switch boot loaders. That will result in a loss of u-boot developers. It is also a lot of pointless administrative work changing licenses and rewriting code. Even worse, you'll could cause a u-boot fork at the point of the license change since the code in front of the change will still be licensed GPLv2 and it can't be retracted.
Why do you want to take on a bunch of pointless administrative work that is going to result in losing developers? That time could be spent productively writing code.
Dear Jon,
In message 9e4733910907060541i6d59561asaa406522ae6558a2@mail.gmail.com you wrote:
If u-boot goes GPLv3 it will simply cause the people that need secure boot to switch boot loaders. That will result in a loss of u-boot developers. It is also a lot of pointless administrative work changing licenses and rewriting code. Even worse, you'll could cause a u-boot fork at the point of the license change since the code in front of the change will still be licensed GPLv2 and it can't be retracted.
There is of course a certain probability that U-Boot might fork. That's OK - it's Free Software, and it's a community project.
And I don't share your pessimistic point of view. I've been through the same thing before when it came to using GNU/Linux in embedded systems ten years ago. Now look where we are today...
And I don't expect that we will have a GPLV3 release of U-Boot in the next few days or weeks :-) This is a process...
Why do you want to take on a bunch of pointless administrative work that is going to result in losing developers? That time could be spent productively writing code.
I already explained this in my posting. No need to repeat it.
Best regards,
Wolfgang Denk
On Mon, 6 Jul 2009, Jon Smirl wrote:
On Mon, Jul 6, 2009 at 6:55 AM, Wolfgang Denkwd@denx.de wrote:
Dear Richard,
In message E1MHHUe-00046l-SR@fencepost.gnu.org you wrote:
Have you considered moving U-boot to "GPLv3-or-later"?
If u-boot goes GPLv3 it will simply cause the people that need secure boot to switch boot loaders. That will result in a loss of u-boot developers. It is also a lot of pointless administrative work changing licenses and rewriting code. Even worse, you'll could cause a u-boot fork at the point of the license change since the code in front of the change will still be licensed GPLv2 and it can't be retracted.
Why do you want to take on a bunch of pointless administrative work that is going to result in losing developers? That time could be spent productively writing code.
I totally agree with all the above. And if this happened I will be among those who move to the new forked code.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
In my experience, people who want a more permissive license typically claim that their participation is absolutely necessary, and doing without it would be a disaster. It tends to be somewhat of an exaggeration.
On Tue, Jul 07, 2009 at 06:05:35AM -0400, Richard Stallman wrote:
In my experience, people who want a more permissive license typically claim that their participation is absolutely necessary, and doing without it would be a disaster. It tends to be somewhat of an exaggeration.
Talk about exaggerations...
I didn't see anyone say that the "no gpl3" crowd was "absolutely necessary" or that there "would be a disaster" -- just that it's something to factor in when considering whether the project would be better off switching.
And it's not as if the anti-permissive crowd ever makes potentially exaggerated claims about what participation would be lost with a BSD-style license (both corporate contributions that would stay private, and individual contributions from GPL fans that would fork (or not be done in the first place) to prevent the former)...
-Scott
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
Dear Jerry Van Baren,
In message 4A521BD5.8080806@ge.com you wrote:
- U-Boot currently has an explicit license to run "stand alone
applications" that have a GPL-incompatible license.
Thanks for mentioning this. But this is explicitly restricted to "stand alone applications", with a pretty tightly limited set of functions exported to such code. It is not intended to be extended into something like loadable modules that can access much more of U-Boot's internal code.
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?
This would quickly render the whole effort of going to GPLv3 useless, as vendors would put all the "interesting" stuff into such GPLv2-only modules, and the result would be the same as with an all-GPLv2 system. Thus the answer can only be: if we go for GPLv3, then we have to do it right, which forbids such an exception.
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?
We don't intend to support proprietary modules - the existing exception for "stand alone applications" already allows to run priprietary code if somebody really feels he must do that, but then they please also take the burdon of developing _all_ their code themself. I don't intend to give them all of the existing U-Boot code for free to be used in their proprietary modules - that would be stupid. We could use a BSD license then as well. This maight be interesting to some, but it is definitely not acceptable to me.
Richard, Wolfgang, U-Boot List, how do you view a "loadable module loophole" fitting in with GPLv3 (a) legally and (b) philosophically?
I think there would be no big problems to set this up legally (just give an experienced laywer enough $$$), but it does not fit in philo- sophically - and not only not with GPLv3, but already now.
Best regards,
Wolfgang Denk
Hello Wolfgang,
2009/7/6 Wolfgang Denk wd@denx.de:
Dear Jerry Van Baren,
- U-Boot currently has an explicit license to run "stand alone
applications" that have a GPL-incompatible license.
Thanks for mentioning this. But this is explicitly restricted to "stand alone applications", with a pretty tightly limited set of functions exported to such code. It is not intended to be extended into something like loadable modules that can access much more of U-Boot's internal code.
AFAIK this limitation of extension is not stated anywhere in the documentation that is delivered with U-boot. (If I am wrong, please point me to the location where this is stated)
So, I guess every user of U-boot is allowed to extend that interface to even the complete symbol map of U-boot, without doing anything in conflict with the license. You can now say it is not intended, but it is not restricted.
Kind Regards,
Remy
Dear Remy,
In message 3efb10970907071216h57288a2an91701c1c851dea9e@mail.gmail.com you wrote:
Thanks for mentioning this. But this is explicitly restricted to "stand alone applications", with a pretty tightly limited set of functions exported to such code. It is not intended to be extended into something like loadable modules that can access much more of U-Boot's internal code.
AFAIK this limitation of extension is not stated anywhere in the documentation that is delivered with U-boot. (If I am wrong, please point me to the location where this is stated)
True.
So, I guess every user of U-boot is allowed to extend that interface to even the complete symbol map of U-boot, without doing anything in conflict with the license. You can now say it is not intended, but it is not restricted.
Right. But try it - banging your head against the nearest wall might be a pastime with more opportunities for reward.
And don't expect that such an "extension" had any chance for going into the mainline code.
Best regards,
Wolfgang Denk
Richard, Wolfgang, U-Boot List, how do you view a "loadable module loophole" fitting in with GPLv3 (a) legally and (b) philosophically?
Legally, the copyright holders of U-boot can give permission for linking with drivers under other licenses. The developers of Linux have in effect done this informally. It would be better to state this in an explicit exception. The exception can be broad or narrow. The set of activities permitted can be whatever you choose. It can apply to drivers loaded dynamically, or drivers linked statically, or both. It can specify particular kinds of code, such as "drivers" or "drivers taken from Linux as found on kernel.org", or whatever. It can permit one other license, such as GPLv2, or a range of other licenses.
To use GPLv2-covered drivers in this way would require a second exception -- on the drivers, to permit combining them with code under GPLv3. Perhaps the driver developers would agree to such an exception, or agree to license the drivers under GPLv2|GPLv3, or under LGPLv2.1. Either one would do the job.
Ethically, to permit non-free drivers would be a big step backward, since this would effectively make U-boot no longer free as used in practice. Allowing non-free drivers in Linux has caused a lasting weakness in our community, as it fails to pressure the manufacturers to permit free drivers.
To permit GPLv2-only drivers does not raise an ethical issue, since they are free. It only raises the legal issue which can be resolved as described above.
On Mon 6 Jul 2009 06:55, Wolfgang Denk pondered:
I am definitely _pro_ going for GPLv3. I am also realizing the efforts and the time this will take.
I'm also glad that you acknowledge that you will loose developers, and users...
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.Long term goal:
Move U-Boot to GPLv3.
And -- since some of us will require to fork at this time (it is not a threat, it is not "I don't like GPLv3", it is just me trying to plainly state the facts) - can we _plan_ for this, as part of the Long term goal?
Where someone else takes over the code base - pre switching to GPLv3 (or pre-dropping features when switching to GPLv2+later).
That way - contributors who still wish to place their contributions under a GPLv2 license, can do so? Contributors who wish to provide features under GPLv3 only can do so as well...
Hello Wolfgang,
2009/7/6 Wolfgang Denk wd@denx.de:
- If we take into consideration that you are not subscribed to the
list, only 20 out of 1712 subscribers (less than 1.2%) bothered to comment at all.
FWIW, I did not comment on this so far, because from what I felt what I had to say was already said. This might be true for others as well.
- Some of these 20 posters did not take a firm stand whether they
are pro or con moving to GPLv3; an unweighted count gives 6 more or less clear votes pro GPLv3 versus 10 votes against such a move.
- It seems reasonable to me to add some weight to these votes,
taking into consideration how much the posters actually contributed to the U-Boot project.
As far as I understand it, a move to gpl3 will need the approval of _all_ copyright holders to make such a switch. (not all names are listed in the headers) While U-boot contains a lot of imported code from other projects (like Linux and others) it will need the approval from the original authors of that code (not in the first place the person who integrated that code in U-boot). This sounds like an impossible task to me. Alternative is to remove all gpl2-only derived code. Only by looking at the USB code it appears to me, it will be needed to remove the entire USB stack (which has a very close resemblance with old Linux USB code), or rewrite it from scratch. Similar things will probably be true for other code as well.
This move to gpl3 will throw up a huge barrier for importing future Linux code in U-boot, because Linux is still gpl2-only, and as such Linux code can no longer be used in U-boot...
So, the goal is to prevent misuse by some hardware vendors of U-boot code. To accomplish this a huge barrier will be thrown up for all developers what eventually will slow down future developments, and that again will increase the chance that forks will arise... (And I believe there is at least 1 fork already...)
I might be missing something huge here, but It seems to me gpl3 is the wrong hammer to reach the goal. (So, if you like clear pro/con, count me in the clear 'con' group)
Kind Regards,
Remy
Dear Remy Bohmer,
In message 3efb10970907071307u662f7d87g5a4a0c0b0740b973@mail.gmail.com you wrote:
As far as I understand it, a move to gpl3 will need the approval of _all_ copyright holders to make such a switch. (not all names are listed in the headers)
Only for files where such a switch is not trivial by exercising the "version 2 (or any later version)" clause. And this is just 184 files so far (3.x % of all files).
This move to gpl3 will throw up a huge barrier for importing future Linux code in U-boot, because Linux is still gpl2-only, and as such Linux code can no longer be used in U-boot...
Without actually trying it out nobody can say how big such a barrier actually might be...
Best regards,
Wolfgang Denk
On Jul 6, 2009, at 5:55 AM, Wolfgang Denk wrote:
Medium term goal:
Analyze which parts of U-Boot are implemented by GPLv2-only code, and evaluate options to convert these into GPLv2+later.Long term goal:
Move U-Boot to GPLv3.
Its not clear if you've decided that u-boot will move to GPLv3 or not. If you haven't how will that decision be made? Will we vote as a community with some bias given to how much one has contributed? Will you just decide?
I ask because its my understanding from internal Freescale discussions (from the PPC group) that its Freescale's preference to stick with GPLv2. What Freescale will decide to do if the decision is to move to GPLv3 is not clear at this point.
- k
On Thursday 09 July 2009 12:10:48 Kumar Gala wrote:
I ask because its my understanding from internal Freescale discussions (from the PPC group) that its Freescale's preference to stick with GPLv2. What Freescale will decide to do if the decision is to move to GPLv3 is not clear at this point.
Freescale isnt alone here, so when/if u-boot goes GPLv3, please dont do your own thing in a vacuum. there will be others who would support a GPLv2 split, so we might as well collaborate. u-boot-v2 looks fairly attractive at this point. -mike
On Jul 9, 2009, at 12:54 PM, Mike Frysinger wrote:
On Thursday 09 July 2009 12:10:48 Kumar Gala wrote:
I ask because its my understanding from internal Freescale discussions (from the PPC group) that its Freescale's preference to stick with GPLv2. What Freescale will decide to do if the decision is to move to GPLv3 is not clear at this point.
Freescale isnt alone here, so when/if u-boot goes GPLv3, please dont do your own thing in a vacuum. there will be others who would support a GPLv2 split, so we might as well collaborate. u-boot-v2 looks fairly attractive at this point.
My personal opinion (not necessarily Freescale's) is that working on a community boot loader is beneficial and doing something in a vacuum is a bad idea.
- k
Hello Robert and Sascha,
Freescale isnt alone here, so when/if u-boot goes GPLv3, please dont do your own thing in a vacuum. there will be others who would support a GPLv2 split, so we might as well collaborate. u-boot-v2 looks fairly attractive at this point. -mike
Well, now Mike brought it up, I think it is time to get the picture complete: What is the standpoint of the u-boot-v2 team on this subject?
Kind Regards,
Remy
On Thursday 09 July 2009 15:49:31 Remy Bohmer wrote:
Freescale isnt alone here, so when/if u-boot goes GPLv3, please dont do your own thing in a vacuum. there will be others who would support a GPLv2 split, so we might as well collaborate. u-boot-v2 looks fairly attractive at this point.
Well, now Mike brought it up, I think it is time to get the picture complete: What is the standpoint of the u-boot-v2 team on this subject?
Kumar posted the question in a dedicated thread -mike
Hi Remy,
On Thu, Jul 09, 2009 at 09:49:31PM +0200, Remy Bohmer wrote:
Freescale isnt alone here, so when/if u-boot goes GPLv3, please dont do your own thing in a vacuum. there will be others who would support a GPLv2 split, so we might as well collaborate. u-boot-v2 looks fairly attractive at this point. -mike
Well, now Mike brought it up, I think it is time to get the picture complete: What is the standpoint of the u-boot-v2 team on this subject?
Seen from our side, we don't plan any license change for u2 over what we have now. Although I must say that I havn't read the recent u-boot flamewar about this topic yet :)
rsc
Dear Kumar,
In message CCBA64F3-2821-475E-8895-4C976032EDBE@kernel.crashing.org you wrote:
Medium term goal:
Analyze which parts of U-Boot are implemented by GPLv2-only code, and evaluate options to convert these into GPLv2+later.Long term goal:
Move U-Boot to GPLv3.
Its not clear if you've decided that u-boot will move to GPLv3 or not. If you haven't how will that decision be made? Will we vote as a community with some bias given to how much one has contributed? Will you just decide?
As far as I'm concerned, the decision is clear. It is my long term goal to move U-Boot to GPLv3. Note that this is a goal, a landmark at the horizon. I cannot tell what time or whet efforts it will take to rech this goal, or if it will ever be reached at all. This depends on a lot of things, last but not least on how many developers actively support (or make a stand against) such activities.
I tend to be a sequential type: to one step after another. Let's get the current, serious licensing issues in U-Boot fixed first. When this has been done (and I guess it may easily extend into next year), we can try and to the next step - having a closer look at what needs to be done to got forward to GPLv3
I ask because its my understanding from internal Freescale discussions (from the PPC group) that its Freescale's preference to stick with GPLv2. What Freescale will decide to do if the decision is to move to GPLv3 is not clear at this point.
I am pretty sure that such positions will shift over time. I've seen this so many times before. In any way, if you have any specific contacts or names of people within Freescale who are concerned about goind GPLv3 please feel free to tell them to contact me directly. I'll be happy to dicuss details with them - maybe I can then at least understand what their actual problem with GPLv3 is.
May of the concerns raised about GPLv3 are eventually based on mis- understandings either of the current legal situation (GPLv2), or the legal consequences of going GPLv3, or most likely both.
Best regards,
Wolfgang Denk
participants (11)
-
Jerry Van Baren -
Jon Smirl -
ksi＠koi8.net -
Kumar Gala -
Mike Frysinger -
Remy Bohmer -
Richard Stallman -
Robert Schwebel -
Robin Getz -
Scott Wood -
Wolfgang Denk