You don't lose patents (or copyrights) for failure to enforce them -- that's trademarks you're thinking of there (and trade secrets, but in a different way).
See, this is one of the things that's annoying about the term "intellectual property" -- it leads to people getting confused about what's what. Patents, copyrights, trademarks and trade secrets are all very different things, and have very different rules that apply.
The recent case was involving the Artistic License, not the GPL. Unlike the Artistic License, the GPL explicitly specifies that in the event that one violates any of its terms, it no longer grants permission to use the copyrighted work. Breaking the contract (if a software license is in fact a contract) may not automatically revoke the license -- but in the case of the GPL, breaking the contract explicitly revokes the license.
Consequently, I believe that the case in question would likely have had a very different outcome had the license in question been the GPL -- and that the cases are distinguishable such that the outcome of the first may not be controlling precedent towards any otherwise similar case where the GPL is in use.
I'm not normally pedantic about spelling -- but I'd argue that this in particular is not just a spelling difference but a conceptual one: copyright is about rights to a work.
But that said -- meh, not worth making a federal case over, and I've probably wasted too many words on the subject already. Cheers.
It's "copyright", not "copywrite". I'm consistently surprised that so many people get it wrong, but most particularly when an individual is making a generally cognizant argument on the subject.
Even if you have your own PRI, you get allocated (or can buy) a block of 30 numbers to go with it. You can assign any of those thirty numbers as the visible ident on any of your thirty B-channels, even to all of them at once; but if you try to assign a number that isn't yours to one of your lines, then it won't work -- it will come up on the far end's telephone as "number withheld". This all happens transparently and you do not receive any error messages.
Time Warner Telecom only implemented this correctly within the last few years. When we first got our PRI, any arbitrary CID value was passed through transparently.
(What's this about 30 b-channels, btw? I'm used to 23 b-channels and 1 d-channel).
git's chunk-based rename handling is interesting, but bzr's directory-level handling is closer to what most users expect. (Does the git behavior make more sense for the kernel source tree? Sure! Does it make more sense for Joe Blow's home directory? I'd need some convincing there).
Out here in the Real World, folks setting up revision control systems need to count "stupid people" (read: artists and web designers who are too busy making art or designing web pages to care about revision control except inasmuch as it's a way to back up and distribute their work) among their customers. For a great many cases, subversion is Good Enough, and it has excellent Windows support, integration with just about every IDE under the sun, TortoiseSVN and other nice pretty hand-holdy tools available which simply aren't ubiquitous among SCMs written with hardcore users in mind (seemingly to the exclusion of those that aren't). SVN isn't distributed, which sucks. SVN has an ugly hack of an excuse for a rename handling algorithm, which sucks. SVN is slow as molasses compared to some of its competition and lacks merge tracking (and thus history-sensitive merging) and has a gawdawful working tree library and sucks in any number of other ways -- but it is a compelling replacement to CVS, and sometimes that's what the customer needs, no matter what shiny happy features ${YOUR_FAVORITE_SCM} may have and no matter how many ways SVN manages to annoy the power user.
And trust me, I learned this one the hard way.
As for the 4NT copy suggestion, the whole bidirectionality and rename handling arguments come into play.
The one-master-many-slaves model isn't really as suitable for this as a multi-master model; who wants to be able to adjust their configuration files only when on their desktop system, and be unable to persist changes made while running off the laptop for a week? (Reverse if the laptop holds the master and the desktop the sync source -- having only a single writable location makes SVN suboptimal in this use case as opposed to distributed SCMs where new commits can be introduced in any repository and merged from there to the others).
As for rsync, it also isn't entirely suitable, because the problem space the poster is looking to solve is best addressed with file-level bidirectional synchronization -- presumably with deletes cascaded only when intentional, and with proper merge handling in cases where a file is modified in one side and moved into a new directory on another -- or possibly even sub-file-level resolution (in cases where a file has been updated in both places in a manner where a merge algorithm can resolve the resulting conflicts). Cascading only from the laptop to the desktop or only from the desktop to the laptop doesn't help much if you've updated File A on the desktop and File B on the laptop -- but a distributed SCM will manage that case just fine so long as the changes can be merged. Simply put, it handles a wider range of the set of cases one can run into in the task at hand -- and thus is a much better fit.
[On a larger scale: SVN and rsync are good tools, but there are other good tools out there too -- and places where they make more sense. It's fine and well that you have a shiny hammer and a crowbar and know how to use them -- but it wouldn't hurt to play around with a screwdriver for a while and figure out what it does best]
subversion is intended for a case where you have a single data store. A modern distributed SCM -- designed for disconnected use -- would make more sense.
Personally, I play with bzr most frequently; it has a nifty Python interface (and an extensive plugin architecture) which makes it quite conducive to local scriptage. (As an example -- I have a local, filesystem-backed set of CA scripts which use bzr for transactional semantics; if a method is called which throws an exception, all filesystem changes are automatically rolled back; if a method succeeds, a commit is done to record the operation and [effectively] set a rollback point). The separation between working tree and repository is optional (by default, all working trees are also repositories -- much like BitKeeper in that respect), which makes it very handy for situations like this where you don't necessarily *have* a separate, central location which all nodes can always communicate with, and where the different trees are allowed and expected to temporarily diverge.
There is a better way (the getpwent() call through the standard C library -- which will use LDAP or whatnot instead of/etc/password as appropriate); further,/etc/passwd doesn't actually contain passwords on any halfway modern system.
Most people don't need to. One person needs to. That's a much lower bar.
Additionally (and perhaps more importantly) -- in the case of OSS, the individual programmer is putting their public reputation on the line. In the case of proprietary software, the credit and blame generally goes to a faceless corporation.
So if you die building and testing rockets for the government, that's noble -- but if you die building and testing rockets for a private company, that's ignoble.
Bullshit.
Advancing the state of the art is a noble cause no matter who pays the bills -- whether it's the taxpayers as a whole or a few millionaires who want to go on expensive vacations, working on spaceflight is a just and honorable vocation. To the extent that this research -- whatever the immediate funding source -- helps to bring down the cost of launching payloads into orbit in the long term or leads to the use of less expensive, reusable launch vehicles, the people involved in it are doing something they can legitimately decide is an activity worth risking death over.
Legislatively restricting spaceflight to governments in the name of protecting those people who may otherwise voluntarily choose to work in a field which they know has more risk than some desk job is an example of the worst sort of "mother-knows-best" nanny state bullshit governance. You can have your safe office job if you want it -- but don't you presume to speak for my interests when you lobby against letting me choose to work on something more interesting and useful to humanity as a whole than 99% of the population has any opportunity to be a part of.
Exploration for profit has a long and proud history -- what do you think brought Columbus out of Spain? The profit motive makes the work itself no less worthy of respect.
Sierra's writing? Bah. The writing in the best of modern IF (try Spider and Web) is significantly better than what Infocom and Sierra used to put out in KQ and PQ. As for Space Quest, I have very fond memories -- but going back and trying to play them again, the games are a mixed bag, and I spend far too much of my time frustrated.
No, if you want to get reminiscent about games with outstanding plots that still have playability (almost) a decade and a half later, I think it needs to be LucasArts. The Secret of Monkey Island, Sam & Max Hit The Road, Day of the Tentacle... those are the classics that stand the test of time.
Since when was depression the same kind of problem that lack of ambition is?
I know lots of people who've been depressed from time to time. They get out of it. I find an interesting project or problem to focus on, my wife goes back to school or finds regular employment, folks with chemical imbalances have those treated appropriately; life goes on, and folks who've been depressed can go on to do some useful and interesting things. Lack of ambition, on the other hand, makes an individual's life an utter waste. It's an absolute travesty when an individual who has the talent to be a professional artist would rather spend his life restocking shelves at Target or a woman who was at the top of her class in high school ends up wasting her days with a dead-end job she hates at Wal-Mart.
"I'm okay, you're okay" is abso-fucking-lutely not OK at all. Too many people with wonderful potential simply waste it because they were never motivated, growing up, to expect great things of themselves. Am I sometimes a little bit depressed because I squandered some of the potential I saw in myself around age 21 or so? Sure -- but I've still gone on to do useful things; I'm working in an interesting and important field, my coworkers respect me, and I can live with not being one of the best in the world (as one of my peers from '01 is now).
Society should not be optimized to maximize the perceived self-worth of its members at the expense of maximizing the value of individuals' actual contributions.
I didn't get that after junior high. Cultivating a few of the right friends (and rumored access to the VAX that stored grades) stopped most of the physical abuse.
One high-profile instance of fighting back successfully (in a case where the bully was a teacher's kid -- and I got away scott free) didn't hurt either.
The OP is right, if the key is nonrandom. If the key is a hash of a password or passphrase and you know the algorithm in use, one can then attempt a dictionary attack.
Stupid way to implement anything that's supposed to be secure (and you're right that there are better attack vectors), but that's not to say it isn't sometimes done that way.
First is that Linux has created a sort of exception to the GPL where he claims it is ok to run anything as long as it uses normal system call from the kernel.
There's not much question about that exception (and it's a "clarification", not an "exception" -- its effect is just to reinforce what a plain reading of the license arguably does anyhow); the one there's a controversy over is the exception permitting some proprietary kernel modules. Even in this case, there's a question of propriety only to the extent to which third parties contributed code under the unmodified GPL prior to Linus announcing this exception. Unless an individual who objects to this change in terms can trace code they own in the kernel back to before the exception was announced (or their code was included in Linux without them consenting to its inclusion within the modified-GPL codebase), they have no standing to object. My full expectation is that if someone who contributed before that time (or whose code was included without their permission more recently) did object, their code would be removed and the community would work around it. In any event, it's pretty much moot: The exemption is there and is widely known to be there, and any individual making use of it can easily show in court that they acted in good faith under the license terms which were expressed to them. To put it a little differently: A few old copyright holders may have a case against Linus (though they're going to have a hard time actually getting any recovery -- if nothing else they're in trouble for failure to mitigate), but they don't have any kind of a case against end users.
[...]shows how GPLv2 only and GPLv3 libraries and programs cannot be linked or put together. Even GPLv2 and LGPLv3 is incompatible[...]
I agree that there is a great deal of uncertainty with regard to interaction between different Free licenses. For companies making proprietary software, however, those interactions are pretty much moot -- they don't need to worry about how Free licenses interact with each other, but only with how they need to interact with Free licenses.
Second, the exception your mentioning is if there is a proprietary work and you create a GPLed work that uses it. I believe you even represented it this way. Where the problem comes in is when a proprietary app links into a GPLed work. This is what I think the parent was attempting to say which I agreed with.
Higher in this thread, there was an assertion that the GNU project's software would be considered derivative of proprietary Unix vendors' code if said UNIX vendors applied the same rules the FSF wishes to use themselves. The exception I mentioned is entirely relevant in that regard, because the FSF's software is written to standard interfaces -- such as the standard C library -- such that an alternate C library could be used in stead of the vendor-provided one. Thus, even if the traditional UNIX vendors used the FSF's own rules, the FSF's software would not be so encumbered.
Third, You mention the uses of BSD and LGPL style licenses. I know the list is long and that I would certainly miss a lot if I tried to name them. But these weren't the ones we were talking about.
You were talking about licensing as an impediment to adoption of Linux as a platform for proprietary software. BSD and LGPL-licensed software is absolutely relevant in that context, because libraries under such licenses provide proprietary software companies with a safe haven in which they have very little to worry about with regard to compliance.
Here is another site that attempts to deal with the issue for embedded developers It brings up the same concerns and lists some of the issues surounding the Linus position and all.
Funny you bring that up as an example. See, I was an embedded developer six years ago, working for MontaVista Software (a Linux-based embedded systems house).
He's not right. The GPL has an exception -- shared linking is acceptable if a non-GPLed work exists such that the generated binary could, unmodified, link and run with the non-GPLed work. It's only when the interface is specific to a GPLed work that the GPL attempts to be viral on shared linking.
Now, there are a lot of libraries which included with modern Linux distributions which are intended to be usable by just about anything -- ranging from the standard C library to GTK, the X11 libraries, and much much more; all of these are under the LGPL, a BSD-style license, or something else that's explicitly nonrestrictive. It's pretty much just the folks who are trying to profit off of software licensing (MySQL and TrollTech) who make libraries which are important to application-level development on Linux but which aren't freely available for commercial use -- but neither of these packages has anything remotely near to a monopoly status.
No, I don't think that unavailability of libraries licensed for use in developing commercial products is a reasonable explanation for any lack of commercial application availability on Linux.
bzzt. You can do shared-library linking to GPLed code just fine so long as that same code is not written to the API of a specific GPLed application. That is to say -- if you write a program A which requires program B to run, and there exists both proprietary (B1) and GPLed (B2) implementations of program B, dynamically linking to the B2 implementation won't touch you at all so long as you can also run the same generated binary against the B1 implementation.
Read The Fine License. There are indeed conditions where you can do shared-library linking to GPLed code without contamination.
The only question is whether I have to accept the GPL in order to distribute my non-GPL'd program because my non-GPL'd program constitutes a derived work according to the legal definition of "derived work". I don't have to use the FSF's broader definition because unless the courts agree that my non-GPL'd program is in fact a derived work I am not doing anything that is prohibited by copyright law, and all the GPL does is give me additional privileges that would otherwise be disallowed by copyright law.
It's [probably] true that you're a nonparty if you aren't redistributing the GPLed work or preparing a derivative work using its code.
However, in practice, how often does that happen? If you're building an application that uses Qt on Windows, you distribute and install Qt on Windows even though you aren't modifying it, because users won't be able to use your application otherwise. If you're building a black-box appliance which uses an unmodified Linux kernel, you're distributing that unmodified Linux kernel, and need a license to do so. Somewhere, for some purpose, you're going to be needing to agree to the GPL -- even if it isn't on account of your proprietary product having derivative status under black-letter copyright law.
In most cases where an entity is in the grey area of shared library linkages (where the FSF's claim is not clear at all), they'll also be in the more black-and-white area of distribution. Distribution of a covered work alongside a proprietary work certainly does not imply that the proprietary work is derived, but it does imply the need for a license for the distribution itself. If they were to codify it (I haven't read even most of GPLv3, but my impression is that they haven't explicitly done this) such that acceptance of the license for the purpose of distribution means agreeing to their definition with regard to shared library linking... well, there's the (opportunity to place a) hook.
Slashdot Mirror
You don't lose patents (or copyrights) for failure to enforce them -- that's trademarks you're thinking of there (and trade secrets, but in a different way).
See, this is one of the things that's annoying about the term "intellectual property" -- it leads to people getting confused about what's what. Patents, copyrights, trademarks and trade secrets are all very different things, and have very different rules that apply.
The recent case was involving the Artistic License, not the GPL. Unlike the Artistic License, the GPL explicitly specifies that in the event that one violates any of its terms, it no longer grants permission to use the copyrighted work. Breaking the contract (if a software license is in fact a contract) may not automatically revoke the license -- but in the case of the GPL, breaking the contract explicitly revokes the license.
Consequently, I believe that the case in question would likely have had a very different outcome had the license in question been the GPL -- and that the cases are distinguishable such that the outcome of the first may not be controlling precedent towards any otherwise similar case where the GPL is in use.
I'm not normally pedantic about spelling -- but I'd argue that this in particular is not just a spelling difference but a conceptual one: copyright is about rights to a work.
But that said -- meh, not worth making a federal case over, and I've probably wasted too many words on the subject already. Cheers.
It's "copyright", not "copywrite". I'm consistently surprised that so many people get it wrong, but most particularly when an individual is making a generally cognizant argument on the subject.
Isn't there a nonproprietary, 3rd-party flash implementation or two available? Might not hurt to see if any of those work.
(What's this about 30 b-channels, btw? I'm used to 23 b-channels and 1 d-channel).
git's chunk-based rename handling is interesting, but bzr's directory-level handling is closer to what most users expect. (Does the git behavior make more sense for the kernel source tree? Sure! Does it make more sense for Joe Blow's home directory? I'd need some convincing there).
Out here in the Real World, folks setting up revision control systems need to count "stupid people" (read: artists and web designers who are too busy making art or designing web pages to care about revision control except inasmuch as it's a way to back up and distribute their work) among their customers. For a great many cases, subversion is Good Enough, and it has excellent Windows support, integration with just about every IDE under the sun, TortoiseSVN and other nice pretty hand-holdy tools available which simply aren't ubiquitous among SCMs written with hardcore users in mind (seemingly to the exclusion of those that aren't). SVN isn't distributed, which sucks. SVN has an ugly hack of an excuse for a rename handling algorithm, which sucks. SVN is slow as molasses compared to some of its competition and lacks merge tracking (and thus history-sensitive merging) and has a gawdawful working tree library and sucks in any number of other ways -- but it is a compelling replacement to CVS, and sometimes that's what the customer needs, no matter what shiny happy features ${YOUR_FAVORITE_SCM} may have and no matter how many ways SVN manages to annoy the power user.
And trust me, I learned this one the hard way.
As for the 4NT copy suggestion, the whole bidirectionality and rename handling arguments come into play.
The one-master-many-slaves model isn't really as suitable for this as a multi-master model; who wants to be able to adjust their configuration files only when on their desktop system, and be unable to persist changes made while running off the laptop for a week? (Reverse if the laptop holds the master and the desktop the sync source -- having only a single writable location makes SVN suboptimal in this use case as opposed to distributed SCMs where new commits can be introduced in any repository and merged from there to the others).
As for rsync, it also isn't entirely suitable, because the problem space the poster is looking to solve is best addressed with file-level bidirectional synchronization -- presumably with deletes cascaded only when intentional, and with proper merge handling in cases where a file is modified in one side and moved into a new directory on another -- or possibly even sub-file-level resolution (in cases where a file has been updated in both places in a manner where a merge algorithm can resolve the resulting conflicts). Cascading only from the laptop to the desktop or only from the desktop to the laptop doesn't help much if you've updated File A on the desktop and File B on the laptop -- but a distributed SCM will manage that case just fine so long as the changes can be merged. Simply put, it handles a wider range of the set of cases one can run into in the task at hand -- and thus is a much better fit.
[On a larger scale: SVN and rsync are good tools, but there are other good tools out there too -- and places where they make more sense. It's fine and well that you have a shiny hammer and a crowbar and know how to use them -- but it wouldn't hurt to play around with a screwdriver for a while and figure out what it does best]
subversion is intended for a case where you have a single data store. A modern distributed SCM -- designed for disconnected use -- would make more sense.
Personally, I play with bzr most frequently; it has a nifty Python interface (and an extensive plugin architecture) which makes it quite conducive to local scriptage. (As an example -- I have a local, filesystem-backed set of CA scripts which use bzr for transactional semantics; if a method is called which throws an exception, all filesystem changes are automatically rolled back; if a method succeeds, a commit is done to record the operation and [effectively] set a rollback point). The separation between working tree and repository is optional (by default, all working trees are also repositories -- much like BitKeeper in that respect), which makes it very handy for situations like this where you don't necessarily *have* a separate, central location which all nodes can always communicate with, and where the different trees are allowed and expected to temporarily diverge.
Correct; that's all functionality hidden behind getpwent() call.
There is a better way (the getpwent() call through the standard C library -- which will use LDAP or whatnot instead of /etc/password as appropriate); further, /etc/passwd doesn't actually contain passwords on any halfway modern system.
Most people don't need to. One person needs to. That's a much lower bar.
Additionally (and perhaps more importantly) -- in the case of OSS, the individual programmer is putting their public reputation on the line. In the case of proprietary software, the credit and blame generally goes to a faceless corporation.
Don't blame me, I voted Libertarian.
So if you die building and testing rockets for the government, that's noble -- but if you die building and testing rockets for a private company, that's ignoble.
Bullshit.
Advancing the state of the art is a noble cause no matter who pays the bills -- whether it's the taxpayers as a whole or a few millionaires who want to go on expensive vacations, working on spaceflight is a just and honorable vocation. To the extent that this research -- whatever the immediate funding source -- helps to bring down the cost of launching payloads into orbit in the long term or leads to the use of less expensive, reusable launch vehicles, the people involved in it are doing something they can legitimately decide is an activity worth risking death over.
Legislatively restricting spaceflight to governments in the name of protecting those people who may otherwise voluntarily choose to work in a field which they know has more risk than some desk job is an example of the worst sort of "mother-knows-best" nanny state bullshit governance. You can have your safe office job if you want it -- but don't you presume to speak for my interests when you lobby against letting me choose to work on something more interesting and useful to humanity as a whole than 99% of the population has any opportunity to be a part of.
Exploration for profit has a long and proud history -- what do you think brought Columbus out of Spain? The profit motive makes the work itself no less worthy of respect.
Sierra's writing? Bah. The writing in the best of modern IF (try Spider and Web) is significantly better than what Infocom and Sierra used to put out in KQ and PQ. As for Space Quest, I have very fond memories -- but going back and trying to play them again, the games are a mixed bag, and I spend far too much of my time frustrated.
No, if you want to get reminiscent about games with outstanding plots that still have playability (almost) a decade and a half later, I think it needs to be LucasArts. The Secret of Monkey Island, Sam & Max Hit The Road, Day of the Tentacle... those are the classics that stand the test of time.
Since when was depression the same kind of problem that lack of ambition is?
I know lots of people who've been depressed from time to time. They get out of it. I find an interesting project or problem to focus on, my wife goes back to school or finds regular employment, folks with chemical imbalances have those treated appropriately; life goes on, and folks who've been depressed can go on to do some useful and interesting things. Lack of ambition, on the other hand, makes an individual's life an utter waste. It's an absolute travesty when an individual who has the talent to be a professional artist would rather spend his life restocking shelves at Target or a woman who was at the top of her class in high school ends up wasting her days with a dead-end job she hates at Wal-Mart.
"I'm okay, you're okay" is abso-fucking-lutely not OK at all. Too many people with wonderful potential simply waste it because they were never motivated, growing up, to expect great things of themselves. Am I sometimes a little bit depressed because I squandered some of the potential I saw in myself around age 21 or so? Sure -- but I've still gone on to do useful things; I'm working in an interesting and important field, my coworkers respect me, and I can live with not being one of the best in the world (as one of my peers from '01 is now).
Society should not be optimized to maximize the perceived self-worth of its members at the expense of maximizing the value of individuals' actual contributions.
I didn't get that after junior high. Cultivating a few of the right friends (and rumored access to the VAX that stored grades) stopped most of the physical abuse.
One high-profile instance of fighting back successfully (in a case where the bully was a teacher's kid -- and I got away scott free) didn't hurt either.
The OP is right, if the key is nonrandom. If the key is a hash of a password or passphrase and you know the algorithm in use, one can then attempt a dictionary attack.
Stupid way to implement anything that's supposed to be secure (and you're right that there are better attack vectors), but that's not to say it isn't sometimes done that way.
There's not much question about that exception (and it's a "clarification", not an "exception" -- its effect is just to reinforce what a plain reading of the license arguably does anyhow); the one there's a controversy over is the exception permitting some proprietary kernel modules. Even in this case, there's a question of propriety only to the extent to which third parties contributed code under the unmodified GPL prior to Linus announcing this exception. Unless an individual who objects to this change in terms can trace code they own in the kernel back to before the exception was announced (or their code was included in Linux without them consenting to its inclusion within the modified-GPL codebase), they have no standing to object. My full expectation is that if someone who contributed before that time (or whose code was included without their permission more recently) did object, their code would be removed and the community would work around it. In any event, it's pretty much moot: The exemption is there and is widely known to be there, and any individual making use of it can easily show in court that they acted in good faith under the license terms which were expressed to them. To put it a little differently: A few old copyright holders may have a case against Linus (though they're going to have a hard time actually getting any recovery -- if nothing else they're in trouble for failure to mitigate), but they don't have any kind of a case against end users.
I agree that there is a great deal of uncertainty with regard to interaction between different Free licenses. For companies making proprietary software, however, those interactions are pretty much moot -- they don't need to worry about how Free licenses interact with each other, but only with how they need to interact with Free licenses.
Higher in this thread, there was an assertion that the GNU project's software would be considered derivative of proprietary Unix vendors' code if said UNIX vendors applied the same rules the FSF wishes to use themselves. The exception I mentioned is entirely relevant in that regard, because the FSF's software is written to standard interfaces -- such as the standard C library -- such that an alternate C library could be used in stead of the vendor-provided one. Thus, even if the traditional UNIX vendors used the FSF's own rules, the FSF's software would not be so encumbered.
You were talking about licensing as an impediment to adoption of Linux as a platform for proprietary software. BSD and LGPL-licensed software is absolutely relevant in that context, because libraries under such licenses provide proprietary software companies with a safe haven in which they have very little to worry about with regard to compliance.
Funny you bring that up as an example. See, I was an embedded developer six years ago, working for MontaVista Software (a Linux-based embedded systems house).
Now, there are a lot of libraries which included with modern Linux distributions which are intended to be usable by just about anything -- ranging from the standard C library to GTK, the X11 libraries, and much much more; all of these are under the LGPL, a BSD-style license, or something else that's explicitly nonrestrictive. It's pretty much just the folks who are trying to profit off of software licensing (MySQL and TrollTech) who make libraries which are important to application-level development on Linux but which aren't freely available for commercial use -- but neither of these packages has anything remotely near to a monopoly status.
No, I don't think that unavailability of libraries licensed for use in developing commercial products is a reasonable explanation for any lack of commercial application availability on Linux.
bzzt. You can do shared-library linking to GPLed code just fine so long as that same code is not written to the API of a specific GPLed application. That is to say -- if you write a program A which requires program B to run, and there exists both proprietary (B1) and GPLed (B2) implementations of program B, dynamically linking to the B2 implementation won't touch you at all so long as you can also run the same generated binary against the B1 implementation.
Read The Fine License. There are indeed conditions where you can do shared-library linking to GPLed code without contamination.
However, in practice, how often does that happen? If you're building an application that uses Qt on Windows, you distribute and install Qt on Windows even though you aren't modifying it, because users won't be able to use your application otherwise. If you're building a black-box appliance which uses an unmodified Linux kernel, you're distributing that unmodified Linux kernel, and need a license to do so. Somewhere, for some purpose, you're going to be needing to agree to the GPL -- even if it isn't on account of your proprietary product having derivative status under black-letter copyright law.
In most cases where an entity is in the grey area of shared library linkages (where the FSF's claim is not clear at all), they'll also be in the more black-and-white area of distribution. Distribution of a covered work alongside a proprietary work certainly does not imply that the proprietary work is derived, but it does imply the need for a license for the distribution itself. If they were to codify it (I haven't read even most of GPLv3, but my impression is that they haven't explicitly done this) such that acceptance of the license for the purpose of distribution means agreeing to their definition with regard to shared library linking... well, there's the (opportunity to place a) hook.