But Microsoft is Communist
on
BSD vs GPL
·
· Score: 1
>...That is called an infective license.
Indeed, you cannot include NT in your product without accepting the Microsoft license. You certainly couldn't use NT source code in your product without distributing it under the NT licence ( pay MS apart from anything else). Even then it would be kinda difficult to get the NT source code.
Nobody has accused M$ of being communist before. Though perhaps they should seeing as M$ cannot go a day without stating the need to eliminate the inefficiencies of competition, or the need for strong central control. Could have come straight out of a RED(mond)s handbook...
>No, the BSD licence is more like a capatalist >organization than like a communist regime. >It gives you the info, and doesn't restrict how >you use or distribute it.
I don't know that the idea of giving stuff away with out more restrictions is more capatalist(sic) than giving away with conditions. The first would not seem to have any place in a capitalism, where as the second could be easily explained by promoting ones standards as mainstream.
Not that this is important seeing as there are better ways of judging the value of a system than comparing it to c&c.
>What if>What if every brand of VCR required a different >tape format?
The multiple brands of VCR _ARE_ produced by different companies. That does not mean that they are incompatible.
MS could licensce the API's to other corps so they could produce %100 compatible systems. I believe most other industries work this way ( e.g. VCR ).
MS wants to bundle apps such as IE and MSOffice with '98. This would form a complete system of which the Operating system would only be part. Each vendor could bundle different applications on top of the same OS. MS could bundle it with IE and Office, but corel could have one with Netscape & Office say.
Anyone who wanted could buy the version with IE _and_ _Office_ bundled, making it even easier for MS's loyal customers. Netscape could also complete on a level playing field, if they wished.
The only 'problem' I can see with this sort of breakup is that this makes it harder for MS to use their OS monoploy to discourage competition in other fields, such as Browsers. OTOH under US law this is considered the ideal situation, not a 'problem'.
Linux can run on a number high powered RISC machines. Another common solution for Linux is clustering. These may be a better solution for high powered Linux requirements.
They claim that reinstalling the Linux Kernel requires all software to be reinstalled. Assuming that the tests were entirely above board, with this level of understanding they would still be unable to do any real fiddling with Linux, however they seemed to know a lot about NT.
They seemed to do a bit of whinging themselves. It is ridulous that a couple of questions posted to a Linux newsgroup should be expected to compete with technicians who live & breath NT.
It would be good to see this expirement verified. Possibly it is valid, but Linux or *BSD would be likely to win if it were done on the basis of $ for speed comparison, or if it were done on more Linux friendly Linux platform.
Other reports seemed to show a significant lead for Linux, even excluding Licences. It would be nice to know what the difference was.
There are reasons to want source code. The standard argument in the press for source code is so that an emergency fix for a 'y2k' bug be put together if the original developer is bust or just recalcitrant. Cliched this argument may be, but I have had similar experiences.
Our company used Quark to format our paper. However, Quark would crash if our paper became too large. Fortunately our core applications were custom designed, so we had the source code, and so we could make a work-around. Scaling down our business so the paper could fit really wasn't an option. Custom software may be more expensive, but some times it is needed. If we were just going for the 'cheap' system we would use pen and paper.
I am not involved in the finance industry, but it seems that they would need the security of source code even more. Having a problem that could they couldn't immediately fix would seem even worse do to there larger turnover.
You noted that custom build in-house software can be problematic (don't I know ;) . Although some of your arguments are confused (i.e. custom software will be standards based if you design it to be that way, proprietary software may or may not be standards based), I agree that custom software can be expensive to maintain.
With open source, there is no need to modify the source if you don't want to. You can use the shrink wrapped version, and still have the confidence that you can customize the software if the need arises. You may even be able to convince the developers to include your modifications into the next shrink-wrap release. This is one things that makes me interested in open source, we need custom software, but I am not ignorant of the advantages of shrink-wrap ware. Open source can be both.
You seemed to suggest that you could not trust your technicians to decide whether it was worthwhile to customize a package, or even to follow your orders. IMHO you need technicians who fix problems rather than 'muck' around with your mission critical systems without good reason.
If I couldn't even trust a techie with my source code, I certainly wouldn't trust them with my money.
A techie is there to make sure the system keeps working, not to muck with your system. If you have techies who cause more problems than they fix, the only permanent solution is to fire 'em. It is not as though you need the source code to mess up important data.
Some problems require the source to fix. Sometimes the solution is worse than the problem - this is nothing new - to constrain a techie to the extent that they cannot cause problems also means that they cannot fix them. A employable techie should be able to choose what response is most suitable. A quasi employable one would at least follow orders. The more options that are available the better chance they have of coming up with a good solution.
As for users screws the system up, all I can say is that you should never give your average user admin rights. There are much more common ways for unskilled users to mess a sysem up without source code. Deleting the 'wrong directory' is a common one.
-- What will the think of you when they find that there is no way to make the software meet there companies changing requirements, because they do not have the source code? Just because they are showing teeth does not mean they are smiling.
Slashdot Mirror
>...That is called an infective license.
Indeed, you cannot include NT in your product without accepting the Microsoft license. You certainly couldn't use NT source
code in your product without distributing it under the NT licence ( pay MS apart from anything else). Even then it would be
kinda difficult to get the NT source code.
Nobody has accused M$ of being communist before. Though perhaps they should seeing as M$ cannot go a day without stating
the need to eliminate the inefficiencies of competition, or the need for strong central control. Could have come straight out of a
RED(mond)s handbook...
>No, the BSD licence is more like a capatalist >organization than like a communist regime.
>It gives you the info, and doesn't restrict how >you use or distribute it.
I don't know that the idea of giving stuff away with out more restrictions is more capatalist(sic) than giving away with conditions. The first would not seem to have any place in a capitalism, where as the second could be easily explained by promoting ones standards as mainstream.
Not that this is important seeing as there are better ways of judging the value of a system than comparing it to c&c.
>What if>What if every brand of VCR required a different >tape format?
The multiple brands of VCR _ARE_ produced by different companies. That does not mean that they are incompatible.
MS could licensce the API's to other corps so they could produce %100 compatible systems. I believe most other industries
work this way ( e.g. VCR ).
MS wants to bundle apps such as IE and MSOffice with '98. This would form a complete system of which the Operating
system would only be part.
Each vendor could bundle different applications on top of the same OS. MS could bundle it with IE and Office, but corel
could have one with Netscape & Office say.
Anyone who wanted could buy the version with IE _and_ _Office_ bundled, making it even easier for MS's loyal customers.
Netscape could also complete on a level playing field, if they wished.
The only 'problem' I can see with this sort of breakup is that this makes it harder for MS to use their OS monoploy to
discourage competition in other fields, such as Browsers. OTOH under US law this is considered the ideal situation, not a
'problem'.
Linux can run on a number high powered RISC machines. Another common solution for Linux is clustering. These may be a better solution for high powered Linux requirements.
They claim that reinstalling the Linux Kernel requires all software to be reinstalled. Assuming that the tests were entirely above board, with this level of understanding they would still be unable to do any real fiddling with Linux, however they seemed to know a lot about NT.
They seemed to do a bit of whinging themselves. It is ridulous that a couple of questions posted to a Linux newsgroup should be expected to compete with technicians who live & breath NT.
It would be good to see this expirement verified. Possibly it is valid, but Linux or *BSD would be likely to win if it were done on the basis of $ for speed comparison, or if it were done on more Linux friendly Linux platform.
Other reports seemed to show a significant lead for Linux, even excluding Licences. It would be nice to know what the difference was.
There are reasons to want source code. The standard argument in the press for
source code is so that an emergency fix for a 'y2k' bug be put together if the
original developer is bust or just recalcitrant. Cliched this argument may be, but I
have had similar experiences.
Our company used Quark to format our paper. However, Quark would crash if
our paper became too large. Fortunately our core applications were custom
designed, so we had the source code, and so we could make a work-around.
Scaling down our business so the paper could fit really wasn't an option. Custom
software may be more expensive, but some times it is needed. If we were just
going for the 'cheap' system we would use pen and paper.
I am not involved in the finance industry, but it seems that they would need the
security of source code even more. Having a problem that could they couldn't
immediately fix would seem even worse do to there larger turnover.
You noted that custom build in-house software can be problematic (don't I know
;) . Although some of your arguments are confused (i.e. custom software will be
standards based if you design it to be that way, proprietary software may or may
not be standards based), I agree that custom software can be expensive to
maintain.
With open source, there is no need to modify the source if you don't want to. You
can use the shrink wrapped version, and still have the confidence that you can
customize the software if the need arises. You may even be able to convince the
developers to include your modifications into the next shrink-wrap release. This
is one things that makes me interested in open source, we need custom software,
but I am not ignorant of the advantages of shrink-wrap ware. Open source can
be both.
You seemed to suggest that you could not trust your technicians to decide
whether it was worthwhile to customize a package, or even to follow your
orders. IMHO you need technicians who fix problems rather than 'muck' around
with your mission critical systems without good reason.
If I couldn't even trust a techie with my source code, I certainly wouldn't trust
them with my money.
A techie is there to make sure the system keeps working, not to muck with your
system. If you have techies who cause more problems than they fix, the only
permanent solution is to fire 'em. It is not as though you need the source code to
mess up important data.
Some problems require the source to fix. Sometimes the solution is worse than
the problem - this is nothing new - to constrain a techie to the extent that they
cannot cause problems also means that they cannot fix them. A employable
techie should be able to choose what response is most suitable. A quasi
employable one would at least follow orders. The more options that are available
the better chance they have of coming up with a good solution.
As for users screws the system up, all I can say is that you should never give
your average user admin rights. There are much more common ways for
unskilled users to mess a sysem up without source code. Deleting the 'wrong
directory' is a common one.
-- What will the think of you when they find that there is no way to make the
software meet there companies changing requirements, because they do not
have the source code? Just because they are showing teeth does not mean they
are smiling.
end users can mount/unmount drives if the root user gives them permission, i.e. makes the drive `user mountable'.
:)
I've done it myself.