Section 2b and 3. For a more through discussion of this refer to archives of debian-legal, gnu.misc.discuss or any other medium carrying this form of discussion. James Ramseys recent editorials on freshmeat.net sums it up pretty well, and deals with some common misconceptions.
He can ignore it if he takes code with implicit permission and includes in ordinary GPL projects, but he cannot take code without implicit permission and include it in KDE, despite the licenses saying the exact same thing. In one direction it works like normal GPL in the other it doesnt.
Dont you think the average programmer finds it difficult enough to througly understand the licenses in question without the licenses containing things that arent expressedly written down?
That's just the thing, the GPL does limit what a GPL'ed program can use.
There is solid reasoning behind this; for example, imagine some company develops a new CPU. They want a compiler for it, want to keep it proprietary and not pay for the entire development. Thus they take gcc and add their code generating backend *as a library*. Instantly bypassing the GPL. Imagine things like proprietary mp3 decoders, document format converters, etc etc etc. The GPL prevents that.
So, no, it isnt ok. That means, if you intend to link against any proprietary or non-GPL compatible libraries do _not_ use the GPL, or add a clause stating that you further allow linking against the library in question so there is no problem. There must be no doubt about the fact that you are adding this extra permission because while you may have this extra permission, no other GPL code that you or anyone else may add to your code has this permission unless you ask the author of that code for it.
So? That changes nothing as regards other peoples code and the fact that you get a situation where the GPL on KDE isnt the GPL but a GPL with 'implicit permission' which makes it unmixable with other GPL code, despite the fact that the licenses dont diff except on some imaginary level.
Most they developed, some they didnt and they placed it under a license that made it undistributable.
Now, lets look at this from a practical point of view. I develop some code that I place under the GPL. Joe-K-I'm-a-programmer-not-a-lawyer sees my code, and figures that it's cool! He takes the code (under the GPL) and inserts it into his own KDE (also under the GPL) code. Perfectly fine, he thinks, because he doesnt understand that KDE *ISNT* under the GPL, it's under some form of imaginary GPL-with-implicit-permission-to-link-to-Qt. The license has some form of metaphysical part in KDE's mind that the license doesnt spell out in text. But how the hell is the 'programmer' who can say that linking GPL code to other GPL code going to figure out that he's not actually doing that, and that he's in violation because there is an implicit clause in one of the licenses?
The license says what it says. The GPL forbids linking to non GPL compatible libraries. If that is not what is wanted you *have* to chose a different license or the product is not distributable.
It isnt really one person. The FSF have several lawyers and legal academics who have been over the GPL time and time again. RMS wrote it. They read it and corrected it. Together I'd say there is no greater authority on the GPL.
And, personally having been following the debates surrounding the GPL since the early 90's, I can only say that RMS has made very very few mistakes where the interpretation of the GPL is involved.
People are, of course, free to go start their own revolution. But I trust RMS will do his best to ensure that anyone who wants will retain the freedom to do that, a freedom that those who do not understand or take for granted would sell out to take a programming shortcut.
No. KDE was technically illegal to *distribute* because of the licensing issue (and, depending on which interpretation of the system component exception clause in the GPL you subscribe to, only illegal to distribute with an operating system containing Qt). You'd be perfectly within your rights to compile it.
Of course, the interesting consequence would be that since all major distributions except Debian have violated the GPL on KDE and forfeited their right to use KDE under GPL terms, Debian is the only distribution who can actually, in theory, legally distribute KDE, until such a time that the KDE authors regrant the rights to those distributions.
Hmmm, you mean, Troll Tech has done more than could ever be expected by being gracious enough to fix KDE's problem for them. KDE themselves, if you ever read the kde-licensing have been anything but interested in fixing their licensing problem; they consistently refuse to admit the problems.
Most of those cases are ok under the system component exception clause. If you find a violation of the GPL where the FSF is the copyright holder, do contact them.
There is no problem with XFree86 code since the MIT X license is more free than the GPL. You only get conflicts with the GPL when a license is less free than the GPL.If the license is more free you can combine and distribute the entire code under the terms of the GPL, since no term in the X license is in conflict with any term in the GPL.
Actually, no need to do the work again:). The FSF has such a list (with some comments). Just go to http://www.fsf.org/philosophy/license-list.html for the information. It lists both compatible and incompatible licenses and non-free (FSF style) licenses. The number of licenses and the ways they are and arent compatible is rather amazing...
There is no really big deal about the GPL, as long as people understand what they're doing (as you seem to be).
However, there are consequences to not being compatible with the GPL, in the form that GPL code cannot be included in NASM, nor can NASM code be included in GPL software.
But as far as I can tell, from what you say you wish to provide further freedoms beyond what the GPL allows. Constructing such a license is not impossible; the easiest way would be to simply take the GPL and add several clauses specifying exactly what added permissions are granted. Of course it would still mean that GPL code cannot be used in NASM (well, it could, but if it was tightly integrated so the GPL Software couldnt be separated then NASM would be effectively under GPL anyway), but at least GPL projects could include NASM code.
Reading the license there are just a few points where there is a problem:
In clause I, the license forbids charging for the software; the GPL does allow charging, and thus NASM would be more restrictive, and not compatible. In my opinion it is a bit redundant, since anyone could come to the NASM team instead of buying it from someone overcharging for it. The "as long as this license remains with it..." is redundant too, since you may not remove the license in any case.
In clause II, the credit of authors is redundant since this is required by copyright law either way. Requirement of notification conflicts with the GPL, as far as I can tell, and again, the 'remain under this license' is redundant.
Clause III, conflicting informing requirement, redundant license clause redundant copyright notice clause and conflicting statement about differing from the original form.
Clause IV, rather redundant. You already have (as long as you hold copyright to the entire code) the ability to give any form of license to anyone under copyright law.
Clause V. Redunant; collections and/or archives are in themselves (in some cases) copyrightable entities in which the copyright holder holds copyright to the 'collection'. I dont think the GPL affects this. License clause redundant here too.
Clause VI. Great. Necessary. Good one.
The rest, pretty good until:
XI. Invalid. You cannot decide who the original authors are if you accept any code copyright anyone else. They retain copyright to any and all code they write until such a point in time that they sign over copyright to you (a possible exception would be 'fair use', but that is up to the courts and whatever is regarded fair use currently in quoting source code, not you to decide. This also leads to IV being invalid.
Basically, there are a lot of redundant parts and just very small parts requireing information to be sent to you that conflict with the GPL. The _major_ problem you have is with granting the right for binary only vendors to use the code, but this is really not tied to the GPL.
In my knowledge there are only two ways to do that; either you go the BSD way and allow anyone, or you _must_ obtain copyright to all code in question. There is no middle way that will allow you on a case by case basis to grant specific other licenses.
The NASM license stating compatibility with the GPL may be enough to allow GPL code to be linked to NASM, from NASM's point of view. It isnt enough to allow NASM code to be linked to GPL code from the GPL point of view tho. So it's a no-go.
Nothing in the license is rendered (legally) unenforcable until a court of law renders it thus. Therefore, from a GPL point of view all of it remains until explicitly stricken by a court.
The only way to avoid the issues is to dual license NASM under the GPL or a GPL compatible license (MIT, BSD, etc) (no extra 'must include NASM license too', no extra language no nothing).
Of course, relicensing under GPL would also require a special licensing for any NASM code included into executables; see the gcc special license for crt.o for example.
Still, it doesnt work. The wording of the clause in the NASM license is imperfect; "the Software may be distributed in such a way as to be compliant with the GNU General Public License" does not equate to "the Software can be distributed under the terms of the GNU General Public License". Furthermore the clause specifies that the NASM license must be included in in such a distribution which immediately renders it non-GPL compliant through a restriction above and beyond the GPL.
And, the final problem is that while the NASM license may allow and/or claim any kind of GPL compatibility, the GPL itself has to be satisfied. NASM code might be legally linkable to GPL code, but GPL code would not be legally linkable to NASM code.
Oh, yes, I most definitely care, and so do many others.
You fail to see the problem here. Linking any GPL code to NASM is a violation of the GPL license. Freely allowing such violation undermines the very foundation of the GPL. It is not a question of what the other license says or if it is acceptable or not, it is the fact that it *IS* a violation. It makes no difference from a legal standpoint wether the NASM license requires you to stand on your head coding Win32 apps for all eternity, or to mention the copyright.
This is the same problem KDE (soon-to-be) used to have. If you link GPL code together with something not compatible with the GPL you *have* to have permission by the authors of the GPL code. Anything else is a violation of the authors license. It doesnt matter if it's a big thing or a small thing; YOU DO NOT HAVE PERMISSION. If it's a small thing, just ask and you will likely get an exception, but until you do get that permission from the authore, let me restate that: _YOU DO NOT HAVE PERMISSION_. And that is FINAL.
A good attitude, but I do wish that OSI would be a bit more careful and that you would make it _very_ _very_ clear that a Certified Open Source license does not solve any license conflicts.
The confusion and annoyance caused by the differing licenses is not (as some appear to believe) because the license for an application is not open and free, anyone is free to license however they want; it is because the code can not be mixed with other code, and even worse, the risk that some 'not-a-lawyer-a-programmer' guy will take code under, for example, the GPL and merge it into a non-GPL application, which is a serious violation of the license and the original authors purpose.
The worries expressed by the NASM programmer in question is exactly the kind of worries that OSI does not seem to address strongly enough. These problems should be pointed out to companies and individuals very early in the process; for example Mozilla would have been able to avoid a very painful license change, and Qt would have been able to avoid years of problems had they understood the implications of not being GPL compatible in the open source community.
This is not to say that you have to be GPL compatible to release perfectly acceptable open source code, but the consequences are that you will never be able to use GPL code, and no GPL project will be able to use your code. This is sometimes tragic and unnecessary, since a dual licensing scheme with the GPL will satisfy even most corporate interests (protecting the code against their competitors using it against them); sadly, they rarely bother to read the GPL carefully enough and analyze the concepts to figure this out.
If they already want to use KDE (not to mention Linux) as the foundation for their applications, how likely are they to want/care about commercial support of one library? The model only works for developers using only Qt, who could concievably have an interest in commercial support.
Re:Reasons from GPLing from the authors
on
Qt Going GPL
·
· Score: 1
Very interesting article. If they've changed their opinion on what the GPL says do they agree with Debians analysis on the distributability of KDE together with QPL Qt now?
You're wrong. The gripe in the free software community has been that KDE had a serious license problem since the QPL wasnt compatible with the GPL, which KDE is licensed under, effectively preventing KDE to be distributed together with Qt.
That Qt cant be used in a proprietary fashion without paying TrollTech is another matter entirely and not in any way a problem or anything to gripe about. Of course, it likely means that KDE wont be accepted by proprietary software makers as a standard, but there is no problem from a free software point of view.
Re:My e-mail to TrollTech.
on
Qt Going GPL
·
· Score: 1
The QPL has always been 'opensource', the problem has been that it wasnt GPL compatible, rendering KDE undistributable together with Qt. Changing it to the GPL changes very little for Troll Tech, it just makes KDE entirely OK from a licensing point of view (just the two points of disclosing internal source code to Troll Tech and distributing changes to Qt as patches).
Most of gnome (as in almost all libraries) is under LGPL.
You wont likely see any flamewar between GPL and LGPL 'supporters', because there is no real rift there, they're good for different things.
Of course, GNOME with its LGPL infrastructure will be more palatable for proprietary developers, but then it always has been.
Having one and just turning it off when you dont want to be reached doesnt make much sense if you have will just have it shut off 99% of the time. Then again, I unplug my phone (dont have an answering service, altho I do have number presentation (good for both sorting out calls you're not interested in, and calling back people if you feel like it)) and procmail email to somewhere around blackholing.
The fact is, I've had enough of people reaching me. I do not want to encourage it. I have enough to do with my time to last me 96 hours per day, and a cellphone just compounds that.
In the case of EverQuest, no intellectual property is 'stolen'; virtually all IP there is resides in the client itself. The server merely tracks locations and some actions; namely the ones that, if client based, could allow cheating. It is a pretty clean reverse engineering for compatibility.
Microsoft has not really done anything of those things; the other home computers were both cheaper, more innovative, more powerful and easier to use (Apple (well, not cheaper that one), Amiga, Atari).
Microsoft managed to keep useful graphics, a useful GUI, sound, multitasking and plug'n'play out of the hands of the mainstream, and even back things up for a long while. And a whole host of other things.
Nah, he'd just show you a videotape where they 'installed' windows on the machines in question (and dont mind the hiccups and obvious doctoring of the tape).
None of it matters. Microsoft themselves have absolutely no credibility whatsoever at all. After several paid for 'market researches', the blatant lies and getting caught forging evidence in front of a judge, Microsoft automatically lies whatever they say. If they say they run NT they lie. If they say NT is useful they lie. If they say this version is good they lie.
They have completely and utterly destroyed any credibility the company has ever had. They cannot even open their mouth without lying.
Why should you ever trust a company who will commit perjury as readily as they'll sell you an email solution?
Slashdot Mirror
Section 2b and 3. For a more through discussion of this refer to archives of debian-legal, gnu.misc.discuss or any other medium carrying this form of discussion. James Ramseys recent editorials on freshmeat.net sums it up pretty well, and deals with some common misconceptions.
He can ignore it if he takes code with implicit permission and includes in ordinary GPL projects, but he cannot take code without implicit permission and include it in KDE, despite the licenses saying the exact same thing. In one direction it works like normal GPL in the other it doesnt.
Dont you think the average programmer finds it difficult enough to througly understand the licenses in question without the licenses containing things that arent expressedly written down?
That's just the thing, the GPL does limit what a GPL'ed program can use.
There is solid reasoning behind this; for example, imagine some company develops a new CPU. They want a compiler for it, want to keep it proprietary and not pay for the entire development. Thus they take gcc and add their code generating backend *as a library*. Instantly bypassing the GPL. Imagine things like proprietary mp3 decoders, document format converters, etc etc etc. The GPL prevents that.
So, no, it isnt ok. That means, if you intend to link against any proprietary or non-GPL compatible libraries do _not_ use the GPL, or add a clause stating that you further allow linking against the library in question so there is no problem. There must be no doubt about the fact that you are adding this extra permission because while you may have this extra permission, no other GPL code that you or anyone else may add to your code has this permission unless you ask the author of that code for it.
So? That changes nothing as regards other peoples code and the fact that you get a situation where the GPL on KDE isnt the GPL but a GPL with 'implicit permission' which makes it unmixable with other GPL code, despite the fact that the licenses dont diff except on some imaginary level.
Most they developed, some they didnt and they placed it under a license that made it undistributable.
Now, lets look at this from a practical point of view. I develop some code that I place under the GPL. Joe-K-I'm-a-programmer-not-a-lawyer sees my code, and figures that it's cool! He takes the code (under the GPL) and inserts it into his own KDE (also under the GPL) code. Perfectly fine, he thinks, because he doesnt understand that KDE *ISNT* under the GPL, it's under some form of imaginary GPL-with-implicit-permission-to-link-to-Qt. The license has some form of metaphysical part in KDE's mind that the license doesnt spell out in text. But how the hell is the 'programmer' who can say that linking GPL code to other GPL code going to figure out that he's not actually doing that, and that he's in violation because there is an implicit clause in one of the licenses?
The license says what it says. The GPL forbids linking to non GPL compatible libraries. If that is not what is wanted you *have* to chose a different license or the product is not distributable.
It isnt really one person. The FSF have several lawyers and legal academics who have been over the GPL time and time again. RMS wrote it. They read it and corrected it. Together I'd say there is no greater authority on the GPL.
And, personally having been following the debates surrounding the GPL since the early 90's, I can only say that RMS has made very very few mistakes where the interpretation of the GPL is involved.
People are, of course, free to go start their own revolution. But I trust RMS will do his best to ensure that anyone who wants will retain the freedom to do that, a freedom that those who do not understand or take for granted would sell out to take a programming shortcut.
No. KDE was technically illegal to *distribute* because of the licensing issue (and, depending on which interpretation of the system component exception clause in the GPL you subscribe to, only illegal to distribute with an operating system containing Qt). You'd be perfectly within your rights to compile it.
Of course, the interesting consequence would be that since all major distributions except Debian have violated the GPL on KDE and forfeited their right to use KDE under GPL terms, Debian is the only distribution who can actually, in theory, legally distribute KDE, until such a time that the KDE authors regrant the rights to those distributions.
Hmmm, you mean, Troll Tech has done more than could ever be expected by being gracious enough to fix KDE's problem for them. KDE themselves, if you ever read the kde-licensing have been anything but interested in fixing their licensing problem; they consistently refuse to admit the problems.
Most of those cases are ok under the system component exception clause. If you find a violation of the GPL where the FSF is the copyright holder, do contact them.
There is no problem with XFree86 code since the MIT X license is more free than the GPL. You only get conflicts with the GPL when a license is less free than the GPL.If the license is more free you can combine and distribute the entire code under the terms of the GPL, since no term in the X license is in conflict with any term in the GPL.
Actually, no need to do the work again :). The FSF has such a list (with some comments). Just go to http://www.fsf.org/philosophy/license-list.html for the information. It lists both compatible and incompatible licenses and non-free (FSF style) licenses. The number of licenses and the ways they are and arent compatible is rather amazing...
There is no really big deal about the GPL, as long as people understand what they're doing (as you seem to be).
However, there are consequences to not being compatible with the GPL, in the form that GPL code cannot be included in NASM, nor can NASM code be included in GPL software.
But as far as I can tell, from what you say you wish to provide further freedoms beyond what the GPL allows. Constructing such a license is not impossible; the easiest way would be to simply take the GPL and add several clauses specifying exactly what added permissions are granted. Of course it would still mean that GPL code cannot be used in NASM (well, it could, but if it was tightly integrated so the GPL Software couldnt be separated then NASM would be effectively under GPL anyway), but at least GPL projects could include NASM code.
Reading the license there are just a few points where there is a problem:
In clause I, the license forbids charging for the software; the GPL does allow charging, and thus NASM would be more restrictive, and not compatible. In my opinion it is a bit redundant, since anyone could come to the NASM team instead of buying it from someone overcharging for it. The "as long as this license remains with it..." is redundant too, since you may not remove the license in any case.
In clause II, the credit of authors is redundant since this is required by copyright law either way. Requirement of notification conflicts with the GPL, as far as I can tell, and again, the 'remain under this license' is redundant.
Clause III, conflicting informing requirement, redundant license clause redundant copyright notice clause and conflicting statement about differing from the original form.
Clause IV, rather redundant. You already have (as long as you hold copyright to the entire code) the ability to give any form of license to anyone under copyright law.
Clause V. Redunant; collections and/or archives are in themselves (in some cases) copyrightable entities in which the copyright holder holds copyright to the 'collection'. I dont think the GPL affects this. License clause redundant here too.
Clause VI. Great. Necessary. Good one.
The rest, pretty good until:
XI. Invalid. You cannot decide who the original authors are if you accept any code copyright anyone else. They retain copyright to any and all code they write until such a point in time that they sign over copyright to you (a possible exception would be 'fair use', but that is up to the courts and whatever is regarded fair use currently in quoting source code, not you to decide. This also leads to IV being invalid.
Basically, there are a lot of redundant parts and just very small parts requireing information to be sent to you that conflict with the GPL. The _major_ problem you have is with granting the right for binary only vendors to use the code, but this is really not tied to the GPL.
In my knowledge there are only two ways to do that; either you go the BSD way and allow anyone, or you _must_ obtain copyright to all code in question. There is no middle way that will allow you on a case by case basis to grant specific other licenses.
The NASM license stating compatibility with the GPL may be enough to allow GPL code to be linked to NASM, from NASM's point of view. It isnt enough to allow NASM code to be linked to GPL code from the GPL point of view tho. So it's a no-go.
Nothing in the license is rendered (legally) unenforcable until a court of law renders it thus. Therefore, from a GPL point of view all of it remains until explicitly stricken by a court.
The only way to avoid the issues is to dual license NASM under the GPL or a GPL compatible license (MIT, BSD, etc) (no extra 'must include NASM license too', no extra language no nothing).
Of course, relicensing under GPL would also require a special licensing for any NASM code included into executables; see the gcc special license for crt.o for example.
Still, it doesnt work. The wording of the clause in the NASM license is imperfect; "the Software may be distributed in such a way as to be compliant with the GNU General Public License" does not equate to "the Software can be distributed under the terms of the GNU General Public License". Furthermore the clause specifies that the NASM license must be included in in such a distribution which immediately renders it non-GPL compliant through a restriction above and beyond the GPL.
And, the final problem is that while the NASM license may allow and/or claim any kind of GPL compatibility, the GPL itself has to be satisfied. NASM code might be legally linkable to GPL code, but GPL code would not be legally linkable to NASM code.
Oh, yes, I most definitely care, and so do many others.
You fail to see the problem here. Linking any GPL code to NASM is a violation of the GPL license. Freely allowing such violation undermines the very foundation of the GPL. It is not a question of what the other license says or if it is acceptable or not, it is the fact that it *IS* a violation. It makes no difference from a legal standpoint wether the NASM license requires you to stand on your head coding Win32 apps for all eternity, or to mention the copyright.
This is the same problem KDE (soon-to-be) used to have. If you link GPL code together with something not compatible with the GPL you *have* to have permission by the authors of the GPL code. Anything else is a violation of the authors license. It doesnt matter if it's a big thing or a small thing; YOU DO NOT HAVE PERMISSION. If it's a small thing, just ask and you will likely get an exception, but until you do get that permission from the authore, let me restate that: _YOU DO NOT HAVE PERMISSION_. And that is FINAL.
A good attitude, but I do wish that OSI would be a bit more careful and that you would make it _very_ _very_ clear that a Certified Open Source license does not solve any license conflicts.
The confusion and annoyance caused by the differing licenses is not (as some appear to believe) because the license for an application is not open and free, anyone is free to license however they want; it is because the code can not be mixed with other code, and even worse, the risk that some 'not-a-lawyer-a-programmer' guy will take code under, for example, the GPL and merge it into a non-GPL application, which is a serious violation of the license and the original authors purpose.
The worries expressed by the NASM programmer in question is exactly the kind of worries that OSI does not seem to address strongly enough. These problems should be pointed out to companies and individuals very early in the process; for example Mozilla would have been able to avoid a very painful license change, and Qt would have been able to avoid years of problems had they understood the implications of not being GPL compatible in the open source community.
This is not to say that you have to be GPL compatible to release perfectly acceptable open source code, but the consequences are that you will never be able to use GPL code, and no GPL project will be able to use your code. This is sometimes tragic and unnecessary, since a dual licensing scheme with the GPL will satisfy even most corporate interests (protecting the code against their competitors using it against them); sadly, they rarely bother to read the GPL carefully enough and analyze the concepts to figure this out.
If they already want to use KDE (not to mention Linux) as the foundation for their applications, how likely are they to want/care about commercial support of one library? The model only works for developers using only Qt, who could concievably have an interest in commercial support.
Very interesting article. If they've changed their opinion on what the GPL says do they agree with Debians analysis on the distributability of KDE together with QPL Qt now?
You're wrong. The gripe in the free software community has been that KDE had a serious license problem since the QPL wasnt compatible with the GPL, which KDE is licensed under, effectively preventing KDE to be distributed together with Qt.
That Qt cant be used in a proprietary fashion without paying TrollTech is another matter entirely and not in any way a problem or anything to gripe about. Of course, it likely means that KDE wont be accepted by proprietary software makers as a standard, but there is no problem from a free software point of view.
The QPL has always been 'opensource', the problem has been that it wasnt GPL compatible, rendering KDE undistributable together with Qt. Changing it to the GPL changes very little for Troll Tech, it just makes KDE entirely OK from a licensing point of view (just the two points of disclosing internal source code to Troll Tech and distributing changes to Qt as patches).
Most of gnome (as in almost all libraries) is under LGPL.
You wont likely see any flamewar between GPL and LGPL 'supporters', because there is no real rift there, they're good for different things.
Of course, GNOME with its LGPL infrastructure will be more palatable for proprietary developers, but then it always has been.
Had one. Gave it away. Not getting a new one.
Having one and just turning it off when you dont want to be reached doesnt make much sense if you have will just have it shut off 99% of the time. Then again, I unplug my phone (dont have an answering service, altho I do have number presentation (good for both sorting out calls you're not interested in, and calling back people if you feel like it)) and procmail email to somewhere around blackholing.
The fact is, I've had enough of people reaching me. I do not want to encourage it. I have enough to do with my time to last me 96 hours per day, and a cellphone just compounds that.
Dont call me. I'll call you.
In the case of EverQuest, no intellectual property is 'stolen'; virtually all IP there is resides in the client itself. The server merely tracks locations and some actions; namely the ones that, if client based, could allow cheating. It is a pretty clean reverse engineering for compatibility.
Microsoft has not really done anything of those things; the other home computers were both cheaper, more innovative, more powerful and easier to use (Apple (well, not cheaper that one), Amiga, Atari).
Microsoft managed to keep useful graphics, a useful GUI, sound, multitasking and plug'n'play out of the hands of the mainstream, and even back things up for a long while. And a whole host of other things.
Nah, he'd just show you a videotape where they 'installed' windows on the machines in question (and dont mind the hiccups and obvious doctoring of the tape).
None of it matters. Microsoft themselves have absolutely no credibility whatsoever at all. After several paid for 'market researches', the blatant lies and getting caught forging evidence in front of a judge, Microsoft automatically lies whatever they say. If they say they run NT they lie. If they say NT is useful they lie. If they say this version is good they lie.
They have completely and utterly destroyed any credibility the company has ever had. They cannot even open their mouth without lying.
Why should you ever trust a company who will commit perjury as readily as they'll sell you an email solution?