Arguing that gpl'ed software has no commercial value seems to tie in pretty well with the proposed antitrust settlement -- microsoft only has to show its source or its api's (sorry, i forget which) to companies with "viable business models"
importance of GPL in Linux taking the lead
on
The Roots Of BSD
·
· Score: 2
I think Leonard missed a major issue in why Linux has become "where the action is" in many ways, and that is the license. It's my impression that the ability to put one's work into software that will permanently be free is a major motivator for many people working on Linux, and they would not have the same motivation to work on BSD where their work could be incorporated into someone's closed proprietary software. And that this has helped create the great surge of development activity around Linux as opposed to BSD, which in turn is the main reason why Linux has become so popular (in spite of what may be the fact, and at least is my technically-uninformed impression, that BSD kernel still has many advantages). That is, if the best kernel won, BSD would have won, and perhaps would still win; but instead the best license has won (with the belief that the kernel will ultimately catch up). I'm an outside observer. What do those on the inside think? Is GPL vs. BSD a major (the major?) factor in the ascendency of Linux over BSD?
One more thought, that should have been in the original post: the OS division surely should be able to add open API's for new functionality, be it web browsing or voice recognition. But the software that utilizes those API's shouldn't be part of the operating system, at least if there's a prior market for such software functionality.
Seems to me there are two key issues to remedies, one well-discussed above, one hardly discussed.
First, much-discussed above, is make the OS API's open, and available in a timely way. MS of course claims the API's are already open, so I think a key issue for the open-source community is to arrive at proposals as to what would need to be done to achieve and enforce this. The suggestions of some kind of auditing by a committee of individuals formed from competitors who would have access to the internals might be one way. But anyhow, it needs discussion.
Second, and hardly discussed so far, is how to prevent the OS division -- even if it is separated from the other divisions -- from embrace and extend. Putting the web browser "in the operating system" is only the latest of a long chain of practices that kill creative software development and give MS control of standards by taking whatever cool things the software development community has created and putting them in the operating system. Voice recognition will soon be another example, if MS has its way.
So, suppose there's a separate OS division, not allowed to make 'applications', and forced to have open API's. Do all that, and you still haven't stopped embrace and extend. What can be added to the remedy to address this? I could imagine forbidding the OS division from incorpating functionality that already exists in the applications market, where 'exists' is defined somehow e.g. in terms of a some significant number of copies distributed and/or $$ in sales, and again perhaps enforcement by some outside auditing committee...
I don't know what a practical, enforcable remedy is, but I think discussing this and coming up with good proposals will be important.
A commonly mentioned remedy, or piece of a remedy, is to force MS to adequately and publicly document all their API's. MS of course claims they already do so. API's also need to be documented in a timely way, i.e. one of the MS tactics against Netscape was to deny Netscape advance access to WIN95 API's and thus stall Netscape's WIN95 release till after the holiday season.
This raises one question about this particular remedy:
(1) Is there a well-defined, enforceable mechanism by which MS can be required to give adequate and timely public documentation of their API's, without requiring constant governmental interference and decision-making as to what is adequate and timely?
For example, I could imagine auditing by some competitor-selected group with access to some well-specified set of internal MS documents; or, an audited requirement (could it be enforced?) that no info about MS OS API's can be passed privately to MS applications developers, that any such info can be passed only by public posting.
Another key issue that I haven't seen addressed in remedies is the tendency of MS to swallow all creative software into their OS and thus put the developers of such creative software out of business -- Netscape/web browsing being only one of many past examples; voice recognition being one of many very likely future examples. Even splitting MS into OS and applications pieces wouldn't prevent the OS piece from continuing this strategy.
I am wondering if this could be addressed somehow by forbidding MS to put software functionality into the OS when there is an existing market for applications with that functionality -- rather, MS would be limited to putting API's for that functionality into their OS, and then they would have to separately distribute software that hooked into those API's, and compete with other such software. One might define the presence of an existing market by some threshold -- say, $10mil/year in sales or 1/2 mil/year copies distributed?
So my second question is:
(2) Can you see any well-defined, enforceable way, that again wouldn't require constant governmental intervention, to put such a restriction on incorporating into the OS software functionality for which there is an existing market? Or any other remedies that would prevent the "takeover a software market by putting it in the monopoly OS" strategy?
Slashdot Mirror
Arguing that gpl'ed software has no commercial value seems to tie in pretty well with the proposed antitrust settlement -- microsoft only has to show its source or its api's (sorry, i forget which) to companies with "viable business models"
I think Leonard missed a major issue in why Linux has become "where the action is" in many ways, and that is the license. It's my impression that the ability to put one's work into software that will permanently be free is a major motivator for many people working on Linux, and they would not have the same motivation to work on BSD where their work could be incorporated into someone's closed proprietary software. And that this has helped create the great surge of development activity around Linux as opposed to BSD, which in turn is the main reason why Linux has become so popular (in spite of what may be the fact, and at least is my technically-uninformed impression, that BSD kernel still has many advantages). That is, if the best kernel won, BSD would have won, and perhaps would still win; but instead the best license has won (with the belief that the kernel will ultimately catch up). I'm an outside observer. What do those on the inside think? Is GPL vs. BSD a major (the major?) factor in the ascendency of Linux over BSD?
One more thought, that should have been in the original post: the OS division surely should be able to add open API's for new functionality, be it web browsing or voice recognition. But the software that utilizes those API's shouldn't be part of the operating system, at least if there's a prior market for such software functionality.
First, much-discussed above, is make the OS API's open, and available in a timely way. MS of course claims the API's are already open, so I think a key issue for the open-source community is to arrive at proposals as to what would need to be done to achieve and enforce this. The suggestions of some kind of auditing by a committee of individuals formed from competitors who would have access to the internals might be one way. But anyhow, it needs discussion.
Second, and hardly discussed so far, is how to prevent the OS division -- even if it is separated from the other divisions -- from embrace and extend. Putting the web browser "in the operating system" is only the latest of a long chain of practices that kill creative software development and give MS control of standards by taking whatever cool things the software development community has created and putting them in the operating system. Voice recognition will soon be another example, if MS has its way.
So, suppose there's a separate OS division, not allowed to make 'applications', and forced to have open API's. Do all that, and you still haven't stopped embrace and extend. What can be added to the remedy to address this? I could imagine forbidding the OS division from incorpating functionality that already exists in the applications market, where 'exists' is defined somehow e.g. in terms of a some significant number of copies distributed and/or $$ in sales, and again perhaps enforcement by some outside auditing committee ...
I don't know what a practical, enforcable remedy is, but I think discussing this and coming up with good proposals will be important.
This raises one question about this particular remedy:
(1) Is there a well-defined, enforceable mechanism by which MS can be required to give adequate and timely public documentation of their API's, without requiring constant governmental interference and decision-making as to what is adequate and timely?
For example, I could imagine auditing by some competitor-selected group with access to some well-specified set of internal MS documents; or, an audited requirement (could it be enforced?) that no info about MS OS API's can be passed privately to MS applications developers, that any such info can be passed only by public posting.
Another key issue that I haven't seen addressed in remedies is the tendency of MS to swallow all creative software into their OS and thus put the developers of such creative software out of business -- Netscape/web browsing being only one of many past examples; voice recognition being one of many very likely future examples. Even splitting MS into OS and applications pieces wouldn't prevent the OS piece from continuing this strategy.
I am wondering if this could be addressed somehow by forbidding MS to put software functionality into the OS when there is an existing market for applications with that functionality -- rather, MS would be limited to putting API's for that functionality into their OS, and then they would have to separately distribute software that hooked into those API's, and compete with other such software. One might define the presence of an existing market by some threshold -- say, $10mil/year in sales or 1/2 mil/year copies distributed?
So my second question is:
(2) Can you see any well-defined, enforceable way, that again wouldn't require constant governmental intervention, to put such a restriction on incorporating into the OS software functionality for which there is an existing market? Or any other remedies that would prevent the "takeover a software market by putting it in the monopoly OS" strategy?