That's a decent argument, though why you don't just use KOffice or StarOffice to look at the attachements confuses me - I hear how wonderfully compatible they are all the time on Slashdot.
My only point was the "saving money" argument was bogus. What you're really doing is paying Codeweavers instead of Microsoft.
That's not an OEM license. That's part of their volume licensing plan and it's a conscious decision that the business must make - get a cheaper per-year license or a more expensive perpeptual one.
Both VMWare and Win4Lin run actual Windows code (and you need a Windows license to run them). They will be no more stable than a standard PC running Windows. Sure - if Windows crashes you just get dumped back to Linux but it still means you lose all your work and possibly get your filesystem trashed.
If I was a large company converting to Linux, the initial step wouldn't be forking out an extra $50 or so for each machine to get the Codeweavers plugin. Your first step would be to shift office environments to one that is cross platform and moving all your file formats to that product.
Oh, and FYI, the price of Windows drops as well with large orders. In essence you save no money at all even if you can manage to get PCs without Windows licenses.
Touting "security" and "stability" and then running MS Office on top of a hacked up Wine implementation really smacks of hypocrasy to me. I'd be willing to bet that MS Office + Windows is a lot more stable than MS Office + Codeweavers + Linux.
In the end, I can see the need for maybe one copy of the Codeweavers Office product to be put on a box somewhere that people can run X Servers from and convert any incoming Office documents to whatever native format they are using. The "buy it for each desktop" argument just makes no sense.
I'm interested in this OEM EULA that requires the end user to upgrade in a few years, or even gives MS the power to demand the end user do anything. Can you drop me a URL with that clause please?
You save around $50 for not having your OEM license on Windows (assuming you don't have the Windows license already if you are supposed to be running Office), pay $55 extra for the Crossover Office thingy and you are somehow saving money?
[i]It was in open and navigable waters, minus the reef.[/i]
I'm sorry but I found that statement quite amusing. The east coast of Australia is full of open and navigable waters minus reefs and ships run aground all the time on the reefs there. Nevada would be open and navigable waters, minus the desert.
Exactly why is this "Stuff that matters" again, or do we just need one more Timothy article that takes any random misconfiguration as a good reason to bash Microsoft?
You'd think with subscriptions Slashdot might turn into a newsworthy site once again, but it looks more like an exclusive MS bashing club when Timothy takes the editor's seat.
I'm interested in where this obvious "intent" is. Everything I see in the license reads very much of the intent to allow source to get out there among entities that are in complaince with the license.
You seem to forget that the discussion isn't about entities that are CURRENTLY in violation of the license. There is a clear penalty for breaking the GPL still - you cannot distribute the code you produce until you are in compliance with the license. The whole need for "forgiveness" from the copyright holder is a rather weak interpretation which comes from people who see a need to perpeptually punish individuals or organisations that step over the line rather than the clear reading of section 6 which gives the intent to allow any company that is in compliance with the GPL's statutes to distribute further.
You also forget that even under some wild interpretation of the GPL which bars an entity forever from using a certain piece of software that it is a trivial exercise to create a separate entity which gains all the IP of the previous entity and yet is not encumbered by the "need for forgiveness" that you are clutching at.
In the end the "intent" of the GPL is to make software free (as professed ad infitium by the FSF). Chaining down companies for past mistakes is NOT making software free - it is a pursuit of vendettas. The FSF has also stated many times that their goal is to bring companies into compliance with the GPL rather than force them out of business. I'm sorry, but there is no intent (clear or obscure) to hold back companies which are currently in compliance with the license's terms.
It isn't invalidated by section 4 for the simple reason that it is a new license. They were in breach of the old contract but section 6 is quite clear in that you get a new grant of the license every time you receive the code, hence you get a fresh chance to do the right thing.
Like it or not, if you violate the GPL (IMHO) it's quite clear that you regain your rights to distribute once you fall within compliance again.
The new license is a new contract and hence is indepenant of the original (broken) contract. It's evident from Section 6 that a new license can be gained to distribute the software so longs as that new distribution is under the terms of the GPL (as you so graciously highlighted).
A new license does indeed shrive the sins comitted - in fact it's the only way to shrive them.
They immediately gain permission to redistribute as soon as they download a new copy. Section 6 clearly states:
"Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (my emphasis added).
In other words, they are automatically relicensed by the terms of the GPL as soon as they got a new version from MySQL-AB.
"Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (my emphasis added).
All NuSphere has to do is prove that MySQL AB distributed the program again and their licence was reinstated. The concept that they've lost their licence to redistribute because of past transgressions is baloney.
My point exactly. The FSF's idea that you need to be "reblessed" once you've sinned is (IMHO) very shaky. I don't see how they can possibly argue anything different when Section 6 clearly states:
"Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (my emphasis added)
While Section 4 states quite clearly that if you break the GPL (which, let's assume they did for now) then all rights to distribute under the contract you entered into with the license are revoked.
That's not the end of the story as most people seem to be professing. The real issue comes when someone from NuSphere downloads ANOTHER copy of MySQL including the source, especially if this is a newer or later version or if they obtained it from a different party. Does this new download constitute a new contract between the parties, and if so then all a GPL violater has to do is download a new version and/or download from a different source and wham - new license, new contract, all sins are forgiven.
Failing that argument, the (rather simple) alternative is to create a new and independant legal entity, assign all your IP rights to the new entity (including the trading name) and the new entity downloads a new copy of the source and is immediately in compliance with the GPL.
The real danger here is that the GPL may and probably does have a "built in automatic forgiveness" clause. If you break the GPL then it seems likely that bringing yourself into compliance and relicensing is a trivial exercise.
Note: IANAL... I did see one on TV once though... In Australia... It was a British show... Ahh whatever.
We have talked about that page and the best I can understand it, you dislike it because it disagrees with the point you are trying to make (whatever that is). If you could tell me why you think it is technically incorrect and post some other link to a definition of what an "ActiveX Control" is that disputes the definition on this page then please do.
You would also do well to actually read what I am saying because I think you are missing the point. Nowhere have I said that only ActiveX uses IUnknown. All I am saying is that if a piece of code supports IUnknown then it is an ActiveX object (possibly among other things). None of the pages you have linked to have disputed that definition. Just because something is technically an "ActiveX Control" doesn't mean it isn't an OLE Control, a MTS component or anything else.
I read the entire page several times. I've also read dozens of books on the subject which concur with the statements on that page. Apparently you simply aren't understanding what I'm saying, or are just trolling because I am in complete agreement that an "ActiveX Control" is a COM Object (it's virtually synonymous). In fact, here's some quotes for you:
"It just barely passes as an ActiveX Control because it implements the IUnknown interface" Professional VC++5 ActiveX/COM Control Programming, p73 "...an ActiveX Control is any specialized COM object that supports the IUnknown interface and self-registration." The Active Template Library: A Developer's Guide, p291 "OC96 changed the definition of a COM-based control from one of those gargantuan COM classes implementing a ton of interfaces to a COM class implementing only IUnknown." MSJ, The Visual Programmer, April 1999
(there's plenty more - that's just what I found on my desk at the moment)
The link you posted does not address "ActiveX" at all - it was written before the time that Microsoft renamed COM objects to be ActiveX controls in a fit of marketing hysteria. The only place ActiveX is mentioned inside that topic is to link back to the page which we were originally discussing.
If you are so adamant that I am mistaken, please educate me and let me know what more an object needs to be an "ActiveX Control" besides IUnknown and the ability to self-register? Please provide a link and a quote from the page that you got the definition from.
In the end, I think you'll find I'm correct in that any object that supports IUnknown and is self registering is an "ActiveX Control".
Nothing on that page suggests anything different to what I've been saying. Perhaps you can help out my obviously limited comprehension skills by pointing out exactly what I'm supposed to be looking at that proves something other than an ActiveX control being anything that implements the IUnknown interface?
If you go back to the definition of an ActiveX control from the MSDN library rather than trying to find gems among the marketing slides on Microsoft's site you always come back to the core definition: "An ActiveX control is essentially a simple OLE object that supports the IUnknown interface."
If you could point me to some site that says there are any more requirements that the implementation if IUnknown and the ability to self-register then perhaps you may have a case.
It describes IUnknown as a defining characteristic of ActiveX controls -- then adds the fact that all other COM objects implement them too!
Actually, it doesn't say that at all. There is no place on the page (or any other page that I've found) that suggests that there is any type of COM object that is not an ActiveX control. There is no such thing as "all other COM objects" because there are no "other" COM objects.
What it does say frequently is that all COM objects are ActiveX controls because they implement IUnknown. There is no confusing of the issue because it's very simple - if a piece of code supports IUnknown then it is an ActiveX control.
I believe you are confusing yourself by thinking that "OLE Control" and "ActiveX Control" are the same thing. They aren't. An OLE Control is an ActiveX Control (because it supports IUnknown), but an ActiveX Control isn't necessarily an OLE Control because there is no requirement for an ActiveX Control to support the dozen or so interfaces required to be an OLE Control.
First paragraph of "ActiveX Controls" in the MSDN library states:
An ActiveX control is essentially a simple OLE object that supports the IUnknown interface. It usually supports many more interfaces in order to offer functionality, but all additional interfaces can be viewed as optional and, as such, a container should not rely on any additional interfaces being supported.
OLE Controls are not the same thing as ActiveX controls. Fundamentally ActiveX is a simplification of the original OLE to the essential IUnknown interface with everything else optional.
I am indeed saying that all COM objects are ActiveX objects. That is the fundamental point of my argument. In fact I screwed up in what I wrote. That proper subset thing was the wrong way around. Teach me for being Erudite...
Read the books again. ActiveX objects are a proper subset of COM objects. Anything that has the first 3 virtual methods as AddRef(), Release() and QueryInterface() is (by definition) an ActiveX object.
COM Automation (usually called OLE Automation) is based on ActiveX objects which implement specific interfaces. In other words, I do not have ActiveX confused with COM. It seems you do.
I can say that they [ActiveX Components] simply don't seem to get used enough in the Windows world
Umm... ActiveX components are impossible to escape in the Windows world. Almost everything you use is an ActiveX component. VB programs are made exclusively of ActiveX components. Windows itself is a massive library of ActiveX components. IE is just a collection of ActiveX components. Office is a collection of ActiveX components.
I also develop software for a living and it sounds like you don't know your way around the Windows development systems yet.
You don't run strace in VC++. Strace is independant of your dev environment even on Unix. You just run your app under APImon under Windows and you get similar functionality.
Want to write a core dump in any function you like? Simple - look at dbghelp.dll. You can load it up and debug it later.
For someone who seems to think they know how to develop in Windows, especially high performance applications, you really know very little about the features of the system that are available to you. Try using windbg sometime - it's your friend.
Sorry, but slamming Visual C because it CAN produce GUI apps easily just doesn't cut the mustard. You can write non-GUI apps in it just as easily and the built in and 3rd party profiling options make it quite easy to figure out where your bottlenecks are.
Lastly, if you've never seen VTune in action then you really don't know what you are talking about in terms of optimizing a Windows app. Beats the hell out of almost any other app I've seen for analysing code performance.
Slashdot Mirror
That's a decent argument, though why you don't just use KOffice or StarOffice to look at the attachements confuses me - I hear how wonderfully compatible they are all the time on Slashdot.
My only point was the "saving money" argument was bogus. What you're really doing is paying Codeweavers instead of Microsoft.
That's not an OEM license. That's part of their volume licensing plan and it's a conscious decision that the business must make - get a cheaper per-year license or a more expensive perpeptual one.
Both VMWare and Win4Lin run actual Windows code (and you need a Windows license to run them). They will be no more stable than a standard PC running Windows. Sure - if Windows crashes you just get dumped back to Linux but it still means you lose all your work and possibly get your filesystem trashed.
If I was a large company converting to Linux, the initial step wouldn't be forking out an extra $50 or so for each machine to get the Codeweavers plugin. Your first step would be to shift office environments to one that is cross platform and moving all your file formats to that product.
Oh, and FYI, the price of Windows drops as well with large orders. In essence you save no money at all even if you can manage to get PCs without Windows licenses.
Touting "security" and "stability" and then running MS Office on top of a hacked up Wine implementation really smacks of hypocrasy to me. I'd be willing to bet that MS Office + Windows is a lot more stable than MS Office + Codeweavers + Linux.
In the end, I can see the need for maybe one copy of the Codeweavers Office product to be put on a box somewhere that people can run X Servers from and convert any incoming Office documents to whatever native format they are using. The "buy it for each desktop" argument just makes no sense.
I'm interested in this OEM EULA that requires the end user to upgrade in a few years, or even gives MS the power to demand the end user do anything. Can you drop me a URL with that clause please?
You save around $50 for not having your OEM license on Windows (assuming you don't have the Windows license already if you are supposed to be running Office), pay $55 extra for the Crossover Office thingy and you are somehow saving money?
Yeah - that's gonna fly just great with my boss.
[i]It was in open and navigable waters, minus the reef.[/i]
I'm sorry but I found that statement quite amusing. The east coast of Australia is full of open and navigable waters minus reefs and ships run aground all the time on the reefs there. Nevada would be open and navigable waters, minus the desert.
:-)
Atomic weight? Wouldn't this give you duplicates or did you actually name all the isotopes?
What about the difference between Tritium and Helium-3 (both weight 3).
Hmm...
Exactly why is this "Stuff that matters" again, or do we just need one more Timothy article that takes any random misconfiguration as a good reason to bash Microsoft?
You'd think with subscriptions Slashdot might turn into a newsworthy site once again, but it looks more like an exclusive MS bashing club when Timothy takes the editor's seat.
Didn't Murdoch become a US Citizen?
I'm interested in where this obvious "intent" is. Everything I see in the license reads very much of the intent to allow source to get out there among entities that are in complaince with the license.
You seem to forget that the discussion isn't about entities that are CURRENTLY in violation of the license. There is a clear penalty for breaking the GPL still - you cannot distribute the code you produce until you are in compliance with the license. The whole need for "forgiveness" from the copyright holder is a rather weak interpretation which comes from people who see a need to perpeptually punish individuals or organisations that step over the line rather than the clear reading of section 6 which gives the intent to allow any company that is in compliance with the GPL's statutes to distribute further.
You also forget that even under some wild interpretation of the GPL which bars an entity forever from using a certain piece of software that it is a trivial exercise to create a separate entity which gains all the IP of the previous entity and yet is not encumbered by the "need for forgiveness" that you are clutching at.
In the end the "intent" of the GPL is to make software free (as professed ad infitium by the FSF). Chaining down companies for past mistakes is NOT making software free - it is a pursuit of vendettas. The FSF has also stated many times that their goal is to bring companies into compliance with the GPL rather than force them out of business. I'm sorry, but there is no intent (clear or obscure) to hold back companies which are currently in compliance with the license's terms.
It isn't invalidated by section 4 for the simple reason that it is a new license. They were in breach of the old contract but section 6 is quite clear in that you get a new grant of the license every time you receive the code, hence you get a fresh chance to do the right thing.
Like it or not, if you violate the GPL (IMHO) it's quite clear that you regain your rights to distribute once you fall within compliance again.
The new license is a new contract and hence is indepenant of the original (broken) contract. It's evident from Section 6 that a new license can be gained to distribute the software so longs as that new distribution is under the terms of the GPL (as you so graciously highlighted).
A new license does indeed shrive the sins comitted - in fact it's the only way to shrive them.
They immediately gain permission to redistribute as soon as they download a new copy. Section 6 clearly states:
"Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (my emphasis added).
In other words, they are automatically relicensed by the terms of the GPL as soon as they got a new version from MySQL-AB.
Read Section 6:
"Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (my emphasis added).
All NuSphere has to do is prove that MySQL AB distributed the program again and their licence was reinstated. The concept that they've lost their licence to redistribute because of past transgressions is baloney.
My point exactly. The FSF's idea that you need to be "reblessed" once you've sinned is (IMHO) very shaky. I don't see how they can possibly argue anything different when Section 6 clearly states:
"Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (my emphasis added)
While Section 4 states quite clearly that if you break the GPL (which, let's assume they did for now) then all rights to distribute under the contract you entered into with the license are revoked.
That's not the end of the story as most people seem to be professing. The real issue comes when someone from NuSphere downloads ANOTHER copy of MySQL including the source, especially if this is a newer or later version or if they obtained it from a different party. Does this new download constitute a new contract between the parties, and if so then all a GPL violater has to do is download a new version and/or download from a different source and wham - new license, new contract, all sins are forgiven.
Failing that argument, the (rather simple) alternative is to create a new and independant legal entity, assign all your IP rights to the new entity (including the trading name) and the new entity downloads a new copy of the source and is immediately in compliance with the GPL.
The real danger here is that the GPL may and probably does have a "built in automatic forgiveness" clause. If you break the GPL then it seems likely that bringing yourself into compliance and relicensing is a trivial exercise.
Note: IANAL... I did see one on TV once though... In Australia... It was a British show... Ahh whatever.
We have talked about that page and the best I can understand it, you dislike it because it disagrees with the point you are trying to make (whatever that is). If you could tell me why you think it is technically incorrect and post some other link to a definition of what an "ActiveX Control" is that disputes the definition on this page then please do.
You would also do well to actually read what I am saying because I think you are missing the point. Nowhere have I said that only ActiveX uses IUnknown. All I am saying is that if a piece of code supports IUnknown then it is an ActiveX object (possibly among other things). None of the pages you have linked to have disputed that definition. Just because something is technically an "ActiveX Control" doesn't mean it isn't an OLE Control, a MTS component or anything else.
I read the entire page several times. I've also read dozens of books on the subject which concur with the statements on that page. Apparently you simply aren't understanding what I'm saying, or are just trolling because I am in complete agreement that an "ActiveX Control" is a COM Object (it's virtually synonymous). In fact, here's some quotes for you:
"It just barely passes as an ActiveX Control because it implements the IUnknown interface" Professional VC++5 ActiveX/COM Control Programming, p73
"...an ActiveX Control is any specialized COM object that supports the IUnknown interface and self-registration." The Active Template Library: A Developer's Guide, p291
"OC96 changed the definition of a COM-based control from one of those gargantuan COM classes implementing a ton of interfaces to a COM class implementing only IUnknown." MSJ, The Visual Programmer, April 1999
(there's plenty more - that's just what I found on my desk at the moment)
The link you posted does not address "ActiveX" at all - it was written before the time that Microsoft renamed COM objects to be ActiveX controls in a fit of marketing hysteria. The only place ActiveX is mentioned inside that topic is to link back to the page which we were originally discussing.
If you are so adamant that I am mistaken, please educate me and let me know what more an object needs to be an "ActiveX Control" besides IUnknown and the ability to self-register? Please provide a link and a quote from the page that you got the definition from.
In the end, I think you'll find I'm correct in that any object that supports IUnknown and is self registering is an "ActiveX Control".
Huh?
Nothing on that page suggests anything different to what I've been saying. Perhaps you can help out my obviously limited comprehension skills by pointing out exactly what I'm supposed to be looking at that proves something other than an ActiveX control being anything that implements the IUnknown interface?
If you go back to the definition of an ActiveX control from the MSDN library rather than trying to find gems among the marketing slides on Microsoft's site you always come back to the core definition:
"An ActiveX control is essentially a simple OLE object that supports the IUnknown interface."
If you could point me to some site that says there are any more requirements that the implementation if IUnknown and the ability to self-register then perhaps you may have a case.
It describes IUnknown as a defining characteristic of ActiveX controls -- then adds the fact that all other COM objects implement them too!
Actually, it doesn't say that at all. There is no place on the page (or any other page that I've found) that suggests that there is any type of COM object that is not an ActiveX control. There is no such thing as "all other COM objects" because there are no "other" COM objects.
What it does say frequently is that all COM objects are ActiveX controls because they implement IUnknown. There is no confusing of the issue because it's very simple - if a piece of code supports IUnknown then it is an ActiveX control.
I believe you are confusing yourself by thinking that "OLE Control" and "ActiveX Control" are the same thing. They aren't. An OLE Control is an ActiveX Control (because it supports IUnknown), but an ActiveX Control isn't necessarily an OLE Control because there is no requirement for an ActiveX Control to support the dozen or so interfaces required to be an OLE Control.
First paragraph of "ActiveX Controls" in the MSDN library states:
An ActiveX control is essentially a simple OLE object that supports the IUnknown interface. It usually supports many more interfaces in order to offer functionality, but all additional interfaces can be viewed as optional and, as such, a container should not rely on any additional interfaces being supported.
OLE Controls are not the same thing as ActiveX controls. Fundamentally ActiveX is a simplification of the original OLE to the essential IUnknown interface with everything else optional.
I am indeed saying that all COM objects are ActiveX objects. That is the fundamental point of my argument. In fact I screwed up in what I wrote. That proper subset thing was the wrong way around. Teach me for being Erudite...
Read the books again. ActiveX objects are a proper subset of COM objects. Anything that has the first 3 virtual methods as AddRef(), Release() and QueryInterface() is (by definition) an ActiveX object.
COM Automation (usually called OLE Automation) is based on ActiveX objects which implement specific interfaces. In other words, I do not have ActiveX confused with COM. It seems you do.
I can say that they [ActiveX Components] simply don't seem to get used enough in the Windows world
Umm... ActiveX components are impossible to escape in the Windows world. Almost everything you use is an ActiveX component. VB programs are made exclusively of ActiveX components. Windows itself is a massive library of ActiveX components. IE is just a collection of ActiveX components. Office is a collection of ActiveX components.
Are you sure of what you are saying here?
And all of those things are so incredibly critical to a university cluster.
Possibly #4 is important, but I can do that on XP anyway.
I also develop software for a living and it sounds like you don't know your way around the Windows development systems yet.
You don't run strace in VC++. Strace is independant of your dev environment even on Unix. You just run your app under APImon under Windows and you get similar functionality.
Want to write a core dump in any function you like? Simple - look at dbghelp.dll. You can load it up and debug it later.
For someone who seems to think they know how to develop in Windows, especially high performance applications, you really know very little about the features of the system that are available to you. Try using windbg sometime - it's your friend.
Sorry, but slamming Visual C because it CAN produce GUI apps easily just doesn't cut the mustard. You can write non-GUI apps in it just as easily and the built in and 3rd party profiling options make it quite easy to figure out where your bottlenecks are.
Lastly, if you've never seen VTune in action then you really don't know what you are talking about in terms of optimizing a Windows app. Beats the hell out of almost any other app I've seen for analysing code performance.