| |||||||||||||
Planning for decadesPlanning for decadesPosted Mar 30, 2012 0:14 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: Planning for decades by xtifr Parent article: A turning point for GNU libc
> Bottom line: "the FSF might do things I don't like in the future" is a mostly-hypothetical bad thing, while removing the "or later" clause is license proliferation, which is a right-now bad thing.
you've obviously missed all the people (including a large number of linux kernel developers) who consider GPLv3 a perfect example of the FSF doing something that they didn't like with a future license change.
for them this is not a hypothetical thing, it's the reality, and they especially don't like being bullied into changing the license on their code because not doing so leads to license proliferation, especially as they made their concerns (including the problem of license proliferation) very clear before the GPLv3 was published.
I'm not saying that you are doing the bullying, but there are others who are doing so.
(Log in to post comments)
Planning for decades Posted Mar 30, 2012 6:12 UTC (Fri) by xtifr (subscriber, #143) [Link] No, I had them in mind when I said mostly. And, while I've heard a lot of people bitch about the GPLv3, in my experience, the majority of the bitching boils down to "wah, it's so long and complicated--v2 was so much simpler and more elegant!" The people I've heard complain about actual terms of the GPLv3 are...well, greater than zero, but not a whole lot greater. The main thing among the actual terms I've heard people complain about is the anti-tivoization stuff, which is why I explicitly covered that in my earlier post. (In fact, if enough people followed my earlier advice, it might actually make my improbable hypothetical come true, and persuade the FSF to conditionally allow tivoization in a future version.) (Also, a lot of people don't seem to grasp the difference between "GPLv2 or later" can always be used under the GPLv2, no matter how many later versions may have been published. The GPLv3 wouldn't prevent the Linux kernel from being Tivoized even if the kernel were "v2 or later", because anyone can still continue to use the code under the terms of v2. But I'm trying to ignore idiotic arguments, even though it's hard when this topic has generated so much heat and so little light.) In any case, you seem to be ignoring the fact that my solution works for both sides! It minimizes the license proliferation problem, while preventing the FSF from adding conditions you don't like to your code. It's not necessarily perfect (you have to have guess which terms might turn out to be important), but I think it's good enough that I'll probably try using it myself.
Planning for decades Posted Mar 30, 2012 6:27 UTC (Fri) by sfeam (subscriber, #2841) [Link] "a lot of people don't seem to grasp the difference between "GPLv2 or later" can always be used under the GPLv2, no matter how many later versions may have been published." Only if you are talking about a standalone bit of code. If someone takes my GPLv2orlater code and incorporates it in a larger GPL3 program, then the result cannot be used under GPL2, only under GPL3. If I don't want that to happen then GPL2orlater is not an option.
Planning for decades Posted Mar 30, 2012 6:59 UTC (Fri) by xtifr (subscriber, #143) [Link] Once again, you're completely ignoring what I actually said in order to argue with some straw man. If there's some change in the GPLv3 you don't like, then say "GPLv2 or any later version which has [the GPLv2 version of that feature]". That doesn't make you more any more compatible with v3, but allows you compatibility if the FSF rethink their position and add the feature as an option in v4. (And even puts some pressure on them to do so, if your program is widespread and popular enough.)
Planning for decades Posted Mar 30, 2012 9:03 UTC (Fri) by paulj (subscriber, #341) [Link]
A likely problem with "GPLv2 or any later version which has [feature list]" is that then the "[feature list]" itself turns into a licence, with attendant complexity of text etc..
A simpler solution perhaps, if you don't fully trust the FSF, would be to add additional authorities as to which later versions are blessed? E.g.: "GPLv2 or any later version approved by [authority]", where authority could be, say, Linus Torvalds, or some cabal. ??
Planning for decades Posted Mar 31, 2012 3:05 UTC (Sat) by xtifr (subscriber, #143) [Link]
yes, that could definitely work too.
Planning for decades Posted Mar 30, 2012 15:21 UTC (Fri) by mcoleman (guest, #70990) [Link] ...then the result cannot be used under GPL2, only under GPL3Of course. Why would you expect to be able to use someone else's code in a manner that they forbid? Microsoft won't let you do that either...
Planning for decades Posted Mar 31, 2012 10:13 UTC (Sat) by mpr22 (subscriber, #60784) [Link] Part of the point of the GPL is "share and share alike" (or so it seems to me). GPLv3+'ing a derivative of a GPLv2+ project is, at best, shockingly rude, since it amounts to saying "I don't want to share with you" to the upstream maintainer.
Planning for decades Posted Mar 31, 2012 11:41 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link] Ah, but what if a GPL v3+ project decides to integrate a non-trivial part of your GPL v2+ code base into the larger GPL v3+ project, as sfeam suggested a few comments up? For example, I'm making a GPL v3/v3+ paint program, and you wrote a nice chunk of GPL v2+ code for handling the whizzy new Frobnitz N-dimensional drawing tablet. Now I integrate your Frobnitz handling code into my paint program. The resulting application is GPL v3+. What's the point of GPL v2+ if not to allow such forward compatibility? Sure, if I were to release a GPL v3/v3+ only application that was created by taking someone else's GPL v2+ app and adding only a little bit of GPL v3 code, that would be somewhat rude (unless I had the author's blessing), but entirely legit by the license. But sfeam's example had the sizes the other way around -- smaller GPL v2+ code subsumed into a larger GPL v3 / v3+ project. I don't think anyone should find that rude. (I almost said "I don't think anyone would find that rude," but I thought better of it. The Internet is a big place.) I imagine it happens with large GPL v3 projects somewhat regularly. Speaking of which, aside from GCC, what are some somewhat large GPL v3 projects out there? Or did most everyone hang back with GPL v2/2+?
Planning for decades Posted Mar 31, 2012 15:47 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
Looking through a repoquery on Rawhide, some of note (ignoring GNU projects):
- audacious
Planning for decades Posted Mar 31, 2012 15:57 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link]
Cool. Looks like it has picked up at least a little steam outside GNU. I guess we'll see in 20 years whether it becomes as popular as GPL v2 did in its ~20 year run as the leading GNU license.
Planning for decades Posted Apr 5, 2012 11:03 UTC (Thu) by njs (guest, #40338) [Link]
The Samba project enthusiastically supports GPLv3; IIUC their experiences with messy court cases, license enforcement, etc., were strong influences on GPLv3's design.
Planning for decades Posted Apr 5, 2012 20:10 UTC (Thu) by Wol (guest, #4433) [Link]
What you should do then (if you can) is to treat the GPL2 code like a LGPL2 library - keep it in its own section of the source tree, and leave it at GPL2+.
If you make major changes you can then decide whether to move it into the main GPL3 tree or not.
Cheers,
Planning for decades Posted May 29, 2012 12:31 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
This is actually wrong.
The combined work can be shared under GPLv3 only. (The act of running the program, coll. using, is not restricted by the GNU GPL.)
But if your original source code is still intact (and copyright law apparently – IANAL, TINLA – forbids removing copyright notices) within the combined work and a visibly separate entity, you can still take that (possibly patched) file under GPLv2+ as it originally was, because the GNU GPL in no version has the power of actually changing *other* peoples’ copyright licences.
|
|||||||||||||