If Space Tourism gets off the ground, there's going to be waiters and busboys and skycaps and the annoying guy who wants a tip because he touched your bags when you carried them into the hotel.
If the key owner is a responsible software developer today, they're unlikely to turn into a script kiddie overnight.
That's not the point.
The problem is that that given the way 0install works... once you have agreed to accept a key, that key now has the ability to access your computer without any further explicit action. If the application is deleted to save space, it will automatically be redownloaded the next time you run it, right?
Right now if gimp.org is compromised, the only people who have to worry about that compromise are peolpe who explicitly downloaded and installed gimp. They know they did it.
With 0install, anyone who clicked on gimp and went off to make a cup of coffee while this fairly large application was started may miss it reinstalling, because it never asked them if they wanted to reinstall it... because it trusted the gimp.org key.
I'll just get used to clicking on accept.
Maybe you will, but at least you'll know you've potentially been exposed.
Automatic install, without an explicit request from the user, is dangerous. It must be possible to turn it off in all circumstances.
Steve is a great guy, and he did some wonderful stuff for Microsoft, and for the rest of us as well. Interix makes all the difference for me... it's like a shoulder-length rubber glove between me and the Win32 subsystem.
But maybe he doesn't quite appreciate the damage Microsoft has done to their reputation by bundling together true open source programs and traditional restricted source releases to customers under a single banner. It's confusing, and they should at least downplay it... they should separate out the truly Open Source components and make it clear that they do Get It, if only in little bits here and there.
And if they'd open-source Interix, whooo... it'd be like attaching a Jato unit to their public relations problem...
The interface is correctly signed with the following keys: - Valid signature from 92429807C9853C0744A68B9AAE07828059A53CC1 Do you want to trust all of these keys to sign interfaces?
Not unless you're prepared to ask me this question every time you download and run anything off the net.
Not having a Linux box to test it on, I have to go by their documentation, and it sounds like they're embedding their launcher into the Konqueror engine.
By that logic, we should all run everything as root all the time
Don't be silly, I'm just making the point that running something as a normal user instead of as root is not nearly as strong a protection as people imply.
Local files aren't 'generally trusted' (at least, not on multi-user system like Linux).
For most users, their Linux box isn't a multi-user system. For most of the rest, they know the other users of their machines, there is a social relationship between them, and damaging the shared server will damage all of them. Even in extereme cases, like a shared university server, the relationship between account holders is still orders of magnitude greater than between the owners of arbitrary websites.
And filemanagers are routinely used to access NFS directories and shares on other computers.
There is explicitly at least a partial truct relationship between computers that have access to each other's NFS shares. That's the way NFS works. Resources accessed through NFS are not significantly different from local resources.
Any user can already run any software from the web.
But, as far as I can tell from that website, Zero Install makes running that software from the web a transparent operation that is almost indistinguishable from running that same software after someone has explicitly and deliberately downloaded and installed it. It makes a remote untrusted resource appear local, and removes that final "OK, I'm installing software from the Internet now" step.
Losing that step has proven remarkably useful for malware authors on Windows. Losing that step is a bad thing.
Users run their applications directly from the Internet from the software author's pages.
Through a web interface?
If they can make that secure, they deserve three Nobel Prizes and a Fields Medal. Since I don't think they're the reincarnation of Alan Turing, Richard Feynman, and Albert Eienstein combined my reaction is "stercus, stercus, stercus, moriturus sum...".
and since it doesn't run any of the remote code as root, you can try software out safely as a 'guest' user.
All that means is "now all your local root exploits are remote root exploits". stercus, stercus, stercus...
You open the directory containing Memo (on the remote machine) with your file manager [...]
No, I don't. This step... using a program (the file manager) whose security is based around managing local and generally trusted files to access remote an generally untrusted files... is one that should not be taken. It's not acceptable when Microsoft does it, it's not acceptable when Apple does it, and it's not acceptable when these guys do it. This has all the same security issues as Internet Enabled Disk Images, Active X, Launchservices, and the Microsoft HTML control. It's not nearly as bad as ActiveX and the Microsoft HTML control, but it's the wrong direction to go.
There really does need to be a clear and obvious distinction between trusted and untrusted resources. Any application or interface that blurs that distinction for the user is a bad thing.
Tied to a chair in a UI concentration camp forced to use dselect while the rest of us forgot that both the camp and dselect even existed.
You bastards, here I am, still stuck in my formative experience with Debian back in, oh, I don't know, 1998... screaming at the humanity of it all...
I didn't say Debian had traumatised me lately. It hasn't. After several nasty shocks like that from Linux I shook the dust off my sandals and went back to BSD-land. It hasn't had a chance to piss me off, and I'm not going to give it one.
And a pox on Gnome and KDE both. Give me a good GNUstep-based Linux distro and I'll give it another chance, but not if they can't figure out that installers are evil, EVIL I tell you! (crazed laughing and wretched sobs...)
Interesting things to point out - I think.app/.dmg is an interesting approach to the problem of software installation[...].app and.dmg are separate things. DMG is an archive format, here, NOT a package format. You don't need.dmg to get the benefit of bundles. You can put appdirs and other bundles in ZIP files, Stuffit archives, tarballs, PAX archives, and so on.
Setting aside the irrelevant issue of self-mounting disk images... which has nothing to do with the package format.
You can drag the appfolder from removable media to your system and vice-versa, but you cannot drag the appfolder into an email or IM conversation due to the way the system is implemented.
Why would you expect to? Can you drag/usr/bin/somapplication into an email or IM conversation and expect the result to be something that your recipient can usefuly work with?
You *can* reight-click on the appfolder, select "Create an Archive...", and drag that into your IM or Email.
Many applications make assumptions about being able to write to their appfolder. This means you sometimes have to move the appfolder to the hard disk before it will run - but this is not always intuitive nor obvious.
No well-behaved application does so, any more than a well-behaved application assumes it can write to/usr/local/lib on Linux. If an application breaks when you don't have write-access to the appfolder, complain to the publisher or author... ALL configuration is supposed to happen in the system or user Library directory.
Little attempt is made to manage multi-user setups. With a large library of software, the "menu" (normally the file manager is used) can become cluttered with programs irrelevant to the user. If all users can install/uninstall software, you have to manually track what people are using so you don't accidentally remove something another user wants to keep.
And it is so hard to create ~/Applications and put your personal applications there?
You have access to the documentation for the programming interfaces,
But no published standard specifying what parts of those interfaces are fixed and which are allowed to change.
hell, you can just load the objects and query them.
You mean, reverse engineer them?
Interfaces determined by inspection are not guaranteed to remain unchanged, Microsoft could easily release even a minor patch that breaks interfaces your replacement applet depends on.
Your response indicated that the only reason to not use a company's built-in software was security.
That is the most important reason, If the software is insecure, then there's no point even looking further. If the software isn't insecure, then pretty much every other reason comes down to either compatibility or taste... and different people can well disagree on that... but there is no room to disagree on security. If the software is inherently insecure (as, for example, the Microsoft HTML control is) then it should not be used, period. I see no room for debate there.
I disagree.
Most vehemently. You said "who cares about security". Clearly you disagree with me, so radically that I see no reason to proceed beyond that point.
In order to integrate with the web, MacOS X has some pretty awful hacks: self mounting disk images spring to mind.
I would say rather "For some reason known only to Apple, and with absolutely no justification, and certainly unrelated to the DMG format, the standard NeXTSTeP/Cocoa application bundle, or the normal Mac OS installer bundle, SOME dmg packages are configured to automatically install...."
DMG is a disk image format. A DMG is pretty much similat to an ISO, and in fact many DMGs *are* ISO images. A DMG is not an Apple installer bundle, and this is unrelated to Apple's installers and applications other than by accident of birth.
There are many reasons that I recommend everyone should disable *any* automatic package opening in their web browser. This is one of them, but no OS and no application should be considered an exception.
You just have to make damn sure you return in the same format and with the same result codes.
That's the crux of the biscuit, isn't it? WMP is proprietary, unlike OpenGL (the example you used), so to emulate the WMP plugin you have to reverse-engineer it.
Who cares about security?
And that sentence there is why Microsoft is still in business and Bill Gates isn't in jail.
Is it me, or does each revision of Longhorn look more and more like OSX ?
It's just you.
It doesn't look much like OS X, unless you have one of the more amateurish "Themes" in place. What it looks more and more like is Windows Media Player... and that's making you think of OS X because Steve Jobs keeps making bits of OS X look like iTunes.
The problem with Symantec's FUD bombs isn't that it's impossible to infect a Mac, it's that Symantec's software doesn't patch exploits... it just catches known malware (well, except for spyware, that's apparently OK) after it's already got to you... hopefully before it has a chance to run.
So the problem is... unless there's an actual virus out in the wild, there's nothing for Symantec's software to check for.
And since it hooks into the OS, at a fairly deep level, any bugs or incompatibilities in their software are effectively new system bugs. So they can only make your computer less reliable and stable. It's not sensible to install AV software in the absence of viruses. It can't possibly help, it can only hurt.
6. Don't get locked into one online store. Have you ever been on the hunt for a particular song? Some obscure indie rock tune or rare jazz performance you heard on the radio? You might have to shop at more than one store before you find the song you're looking for.
Do the different "stores" actually have significantly different content, other than artificial differentiation (like Apple Records hating Apple Computer)? Should they? I mean, there's no significant overhead for online stores to carry every track out there.
In practice, online DRM-protected music distribution will tend to become a "natural monopoly" like operating system software. You'd have your choice of half a dozen Clear Channel Radio equivalents all with he same content and all tied together behind the scenes to Microsoft. Choice would become the choice of buying your copy of Windows XP from CompUSA or MicroCenter.
Meanwhile, the "obscure indie bands and rare jazz performances" can be found without DRM on a CD from the band's own website or Amazon. I buy individual tracks from iTMS, but when I go to buy an album I pay a bit more and wait a bit longer to get a "clean" version.
I've bought more CDs in the past couple of months, since I got my iPod, than I've bought in the past couple of years before it. This makes me wonder about the industry. I sometimes wonder if they're not pushing DRM-protected music so hard they're trying to hurt CD sales...
One of Window's main features has ALWAYS been DDE/OLE/ActiveX. I *like* the fact that simply by installing a properly made Windows program, I suddenly have programmatic COM access to all of it's bits, with the only hoops needing jumping through being the need to find documentation.
If that were the case then you should be EASILY able to write a plugin that could replace WMP, right?
Tell me, can I put my own PDF engine into MacOS X, in place of the built in one?
If the built-in one was the kind of security hole that ActiveX is, I'd worry about questions like that.
2. "the inconvinence of the library."... so, they just have to make downloading from whatever free illicit sources exist (P2P is often used that way, but that's not all it's used for an there are lots of other avenues) less convenient than buying the music online. How do you propose to do this?
It doesn't have to be "too bad", it just has to be "bad enough".
Plus its arguable that an LGPL type license is not in the spirit of the GPL, that would be the spirit of the LGPL.
The fact that it's arguable means that if the OP's customers pull the ripcord and bale out, if he wants to get them back he'll have to go to court. And don't forget "the courts are always open, but so's the Hilton"... the OP may not be able to afford that. It's *much* easier and more practical to leave the "... or later" bit out and then pick up on later versions of the GPL when appropriate.
We should also remember the part of the GPL that says something like "future versions of the gpl will be of the same spirit but with different bits to address new concerns"
That still leaves plenty of room for licenses that reduce the value of dual-license strategies. Some future GPL may include LGPL-like terms, for example, and the OP's commercial customers will find they can switch to the GPL version of his library and quit paying him. It's not likely, but it's not impossible, and it certainly fits in the "same spirit" as the GPL.
# As the copyright holder, you can always decide to release your code under another license.
But the code under GPLv2, GPLv3, etcetera will still be out there.
# The "or later" clause is at your option, "you" being the licensee. This means that that clause can only grant new rights, not remove rights, since anybody can always decide to chose to see the software as licensed under GPL v2. This is similar to dual licensing.
The issue isn't whether anyone can see the software as licensed under GPLv2, but whether they can see it as licensed under GPLv3/4/5/2010/..., which is what the "... or later" clause allows.
The concern the OP seems to have is that some later version of the GPL may contain clauses that are less restrictive to some proprietary use, and thus reduce the value of his own dual-license strategy. I personally don't think it likely that something like the LGPL will be included in the GPL, but I sure wouldn't want to say it would never happen.
Slashdot Mirror
There is going to be a waiter in space?
If Space Tourism gets off the ground, there's going to be waiters and busboys and skycaps and the annoying guy who wants a tip because he touched your bags when you carried them into the hotel.
Useful Phrases for the Space Tourist, in many languages.
If the key owner is a responsible software developer today, they're unlikely to turn into a script kiddie overnight.
That's not the point.
The problem is that that given the way 0install works... once you have agreed to accept a key, that key now has the ability to access your computer without any further explicit action. If the application is deleted to save space, it will automatically be redownloaded the next time you run it, right?
Right now if gimp.org is compromised, the only people who have to worry about that compromise are peolpe who explicitly downloaded and installed gimp. They know they did it.
With 0install, anyone who clicked on gimp and went off to make a cup of coffee while this fairly large application was started may miss it reinstalling, because it never asked them if they wanted to reinstall it... because it trusted the gimp.org key.
I'll just get used to clicking on accept.
Maybe you will, but at least you'll know you've potentially been exposed.
Automatic install, without an explicit request from the user, is dangerous. It must be possible to turn it off in all circumstances.
Steve is a great guy, and he did some wonderful stuff for Microsoft, and for the rest of us as well. Interix makes all the difference for me... it's like a shoulder-length rubber glove between me and the Win32 subsystem.
But maybe he doesn't quite appreciate the damage Microsoft has done to their reputation by bundling together true open source programs and traditional restricted source releases to customers under a single banner. It's confusing, and they should at least downplay it... they should separate out the truly Open Source components and make it clear that they do Get It, if only in little bits here and there.
And if they'd open-source Interix, whooo... it'd be like attaching a Jato unit to their public relations problem...
I think you misspelled "Klaatu barada nikto."
"Me ihmiset emme regeneroidu."
"Hvor er det naermeste taenkende pattedyr?"
"Det her er min kammerat, ikke drikkepenge."
"Ceci ne peut pas être ma chambre, puisque je ne respire pas de l'ammoniac."
"Tjener, denne ret er stadig levende."
"ore no hovercraft ha unagi de ippai."
(apologies to Joanna Russ)
The interface is correctly signed with the following keys:
- Valid signature from 92429807C9853C0744A68B9AAE07828059A53CC1
Do you want to trust all of these keys to sign interfaces?
Not unless you're prepared to ask me this question every time you download and run anything off the net.
No. With their application launcher.
Not having a Linux box to test it on, I have to go by their documentation, and it sounds like they're embedding their launcher into the Konqueror engine.
By that logic, we should all run everything as root all the time
Don't be silly, I'm just making the point that running something as a normal user instead of as root is not nearly as strong a protection as people imply.
Local files aren't 'generally trusted' (at least, not on multi-user system like Linux).
For most users, their Linux box isn't a multi-user system. For most of the rest, they know the other users of their machines, there is a social relationship between them, and damaging the shared server will damage all of them. Even in extereme cases, like a shared university server, the relationship between account holders is still orders of magnitude greater than between the owners of arbitrary websites.
And filemanagers are routinely used to access NFS directories and shares on other computers.
There is explicitly at least a partial truct relationship between computers that have access to each other's NFS shares. That's the way NFS works. Resources accessed through NFS are not significantly different from local resources.
Any user can already run any software from the web.
But, as far as I can tell from that website, Zero Install makes running that software from the web a transparent operation that is almost indistinguishable from running that same software after someone has explicitly and deliberately downloaded and installed it. It makes a remote untrusted resource appear local, and removes that final "OK, I'm installing software from the Internet now" step.
Losing that step has proven remarkably useful for malware authors on Windows. Losing that step is a bad thing.
Have you looked at 0install.net?
No. Let's see.
Users run their applications directly from the Internet from the software author's pages.
Through a web interface?
If they can make that secure, they deserve three Nobel Prizes and a Fields Medal. Since I don't think they're the reincarnation of Alan Turing, Richard Feynman, and Albert Eienstein combined my reaction is "stercus, stercus, stercus, moriturus sum...".
and since it doesn't run any of the remote code as root, you can try software out safely as a 'guest' user.
All that means is "now all your local root exploits are remote root exploits". stercus, stercus, stercus...
You open the directory containing Memo (on the remote machine) with your file manager [...]
No, I don't. This step... using a program (the file manager) whose security is based around managing local and generally trusted files to access remote an generally untrusted files... is one that should not be taken. It's not acceptable when Microsoft does it, it's not acceptable when Apple does it, and it's not acceptable when these guys do it. This has all the same security issues as Internet Enabled Disk Images, Active X, Launchservices, and the Microsoft HTML control. It's not nearly as bad as ActiveX and the Microsoft HTML control, but it's the wrong direction to go.
There really does need to be a clear and obvious distinction between trusted and untrusted resources. Any application or interface that blurs that distinction for the user is a bad thing.
Tied to a chair in a UI concentration camp forced to use dselect while the rest of us forgot that both the camp and dselect even existed.
You bastards, here I am, still stuck in my formative experience with Debian back in, oh, I don't know, 1998... screaming at the humanity of it all...
I didn't say Debian had traumatised me lately. It hasn't. After several nasty shocks like that from Linux I shook the dust off my sandals and went back to BSD-land. It hasn't had a chance to piss me off, and I'm not going to give it one.
And a pox on Gnome and KDE both. Give me a good GNUstep-based Linux distro and I'll give it another chance, but not if they can't figure out that installers are evil, EVIL I tell you! (crazed laughing and wretched sobs...)
Interesting things to point out - I think .app/.dmg is an interesting approach to the problem of software installation[...] .app and .dmg are separate things. DMG is an archive format, here, NOT a package format. You don't need .dmg to get the benefit of bundles. You can put appdirs and other bundles in ZIP files, Stuffit archives, tarballs, PAX archives, and so on.
I have never forgiven Debian for dselect.
Setting aside the irrelevant issue of self-mounting disk images... which has nothing to do with the package format.
/usr/bin/somapplication into an email or IM conversation and expect the result to be something that your recipient can usefuly work with?
/usr/local/lib on Linux. If an application breaks when you don't have write-access to the appfolder, complain to the publisher or author... ALL configuration is supposed to happen in the system or user Library directory.
You can drag the appfolder from removable media to your system and vice-versa, but you cannot drag the appfolder into an email or IM conversation due to the way the system is implemented.
Why would you expect to? Can you drag
You *can* reight-click on the appfolder, select "Create an Archive...", and drag that into your IM or Email.
Many applications make assumptions about being able to write to their appfolder. This means you sometimes have to move the appfolder to the hard disk before it will run - but this is not always intuitive nor obvious.
No well-behaved application does so, any more than a well-behaved application assumes it can write to
Little attempt is made to manage multi-user setups. With a large library of software, the "menu" (normally the file manager is used) can become cluttered with programs irrelevant to the user. If all users can install/uninstall software, you have to manually track what people are using so you don't accidentally remove something another user wants to keep.
And it is so hard to create ~/Applications and put your personal applications there?
You have access to the documentation for the programming interfaces,
But no published standard specifying what parts of those interfaces are fixed and which are allowed to change.
hell, you can just load the objects and query them.
You mean, reverse engineer them?
Interfaces determined by inspection are not guaranteed to remain unchanged, Microsoft could easily release even a minor patch that breaks interfaces your replacement applet depends on.
Your response indicated that the only reason to not use a company's built-in software was security.
That is the most important reason, If the software is insecure, then there's no point even looking further. If the software isn't insecure, then pretty much every other reason comes down to either compatibility or taste... and different people can well disagree on that... but there is no room to disagree on security. If the software is inherently insecure (as, for example, the Microsoft HTML control is) then it should not be used, period. I see no room for debate there.
I disagree.
Most vehemently. You said "who cares about security". Clearly you disagree with me, so radically that I see no reason to proceed beyond that point.
In order to integrate with the web, MacOS X has some pretty awful hacks: self mounting disk images spring to mind.
I would say rather "For some reason known only to Apple, and with absolutely no justification, and certainly unrelated to the DMG format, the standard NeXTSTeP/Cocoa application bundle, or the normal Mac OS installer bundle, SOME dmg packages are configured to automatically install...."
DMG is a disk image format. A DMG is pretty much similat to an ISO, and in fact many DMGs *are* ISO images. A DMG is not an Apple installer bundle, and this is unrelated to Apple's installers and applications other than by accident of birth.
There are many reasons that I recommend everyone should disable *any* automatic package opening in their web browser. This is one of them, but no OS and no application should be considered an exception.
You just have to make damn sure you return in the same format and with the same result codes.
That's the crux of the biscuit, isn't it? WMP is proprietary, unlike OpenGL (the example you used), so to emulate the WMP plugin you have to reverse-engineer it.
Who cares about security?
And that sentence there is why Microsoft is still in business and Bill Gates isn't in jail.
I was thinking of running your screen-saver modules on the desktop, under a translucent image layer.
Is it me, or does each revision of Longhorn look more and more like OSX ?
It's just you.
It doesn't look much like OS X, unless you have one of the more amateurish "Themes" in place. What it looks more and more like is Windows Media Player... and that's making you think of OS X because Steve Jobs keeps making bits of OS X look like iTunes.
What an Ultramaroon!
The problem with Symantec's FUD bombs isn't that it's impossible to infect a Mac, it's that Symantec's software doesn't patch exploits... it just catches known malware (well, except for spyware, that's apparently OK) after it's already got to you... hopefully before it has a chance to run.
So the problem is... unless there's an actual virus out in the wild, there's nothing for Symantec's software to check for.
And since it hooks into the OS, at a fairly deep level, any bugs or incompatibilities in their software are effectively new system bugs. So they can only make your computer less reliable and stable. It's not sensible to install AV software in the absence of viruses. It can't possibly help, it can only hurt.
6. Don't get locked into one online store. Have you ever been on the hunt for a particular song? Some obscure indie rock tune or rare jazz performance you heard on the radio? You might have to shop at more than one store before you find the song you're looking for.
Do the different "stores" actually have significantly different content, other than artificial differentiation (like Apple Records hating Apple Computer)? Should they? I mean, there's no significant overhead for online stores to carry every track out there.
In practice, online DRM-protected music distribution will tend to become a "natural monopoly" like operating system software. You'd have your choice of half a dozen Clear Channel Radio equivalents all with he same content and all tied together behind the scenes to Microsoft. Choice would become the choice of buying your copy of Windows XP from CompUSA or MicroCenter.
Meanwhile, the "obscure indie bands and rare jazz performances" can be found without DRM on a CD from the band's own website or Amazon. I buy individual tracks from iTMS, but when I go to buy an album I pay a bit more and wait a bit longer to get a "clean" version.
I've bought more CDs in the past couple of months, since I got my iPod, than I've bought in the past couple of years before it. This makes me wonder about the industry. I sometimes wonder if they're not pushing DRM-protected music so hard they're trying to hurt CD sales...
Like Gmail and Orkut are search related?
Oh yeh they are... they feed enormous amounts of useful data into the Google database, particularly Gmail's ever growing spam recognition engine.
One of Window's main features has ALWAYS been DDE/OLE/ActiveX. I *like* the fact that simply by installing a properly made Windows program, I suddenly have programmatic COM access to all of it's bits, with the only hoops needing jumping through being the need to find documentation.
If that were the case then you should be EASILY able to write a plugin that could replace WMP, right?
Tell me, can I put my own PDF engine into MacOS X, in place of the built in one?
If the built-in one was the kind of security hole that ActiveX is, I'd worry about questions like that.
What if your 20% is a videogame, IRC client, MUD, or new GUI/Window system?
1. HypocrIte, not hypocrAte.
... so, they just have to make downloading from whatever free illicit sources exist (P2P is often used that way, but that's not all it's used for an there are lots of other avenues) less convenient than buying the music online. How do you propose to do this?
2. "the inconvinence of the library."
My point was that it cant be too bad.
It doesn't have to be "too bad", it just has to be "bad enough".
Plus its arguable that an LGPL type license is not in the spirit of the GPL, that would be the spirit of the LGPL.
The fact that it's arguable means that if the OP's customers pull the ripcord and bale out, if he wants to get them back he'll have to go to court. And don't forget "the courts are always open, but so's the Hilton"... the OP may not be able to afford that. It's *much* easier and more practical to leave the "... or later" bit out and then pick up on later versions of the GPL when appropriate.
We should also remember the part of the GPL that says something like "future versions of the gpl will be of the same spirit but with different bits to address new concerns"
That still leaves plenty of room for licenses that reduce the value of dual-license strategies. Some future GPL may include LGPL-like terms, for example, and the OP's commercial customers will find they can switch to the GPL version of his library and quit paying him. It's not likely, but it's not impossible, and it certainly fits in the "same spirit" as the GPL.
# As the copyright holder, you can always decide to release your code under another license.
But the code under GPLv2, GPLv3, etcetera will still be out there.
# The "or later" clause is at your option, "you" being the licensee. This means that that clause can only grant new rights, not remove rights, since anybody can always decide to chose to see the software as licensed under GPL v2. This is similar to dual licensing.
The issue isn't whether anyone can see the software as licensed under GPLv2, but whether they can see it as licensed under GPLv3/4/5/2010/..., which is what the "... or later" clause allows.
The concern the OP seems to have is that some later version of the GPL may contain clauses that are less restrictive to some proprietary use, and thus reduce the value of his own dual-license strategy. I personally don't think it likely that something like the LGPL will be included in the GPL, but I sure wouldn't want to say it would never happen.