For leading the world's most pervasive and successful open source project ever. Sidestepping political issues, he's focused on producing good code and has achieved >50% market share -- a number unequalled by any other open source project.
Unlike many open source advocates who are "more talk than action," Tim O'Reilly has promoted open source in a way that others have not: by making it accessible. By publishing books documenting key open source programs such as Perl, Python, Apache, etc., O'Reilly has demystified these often poorly documented programs. His actions have had more to do with the success of open source than the demagoguery of, say, ESR or RMS. He gets my vote.
The FSF does not meet the legal qualifications to be a 501(c)(3) public charity. In fact, it does not qualify for any of the categories of non-profit entities recognized under the Internal Revenue Code.
The reason for this is that a 501(c)(3), legally, is not allowed to engage in activities which are the same as those normally carried out by for-profit businesses or to compete with them. The explicit purpose of the FSF is to compete with -- in fact, to damage -- for-profit businesses by giving away for free what those businesses sell. This is not a permitted activity.
The reason why autoconf exists is that compiler libraries do a poor job of retaining portability between platforms.
Ironically, Python and Perl are both far more portable than C and C++, for which autoconf was primarily designed, because the libraries do a better job of hiding platform dependencies.
Perhaps the competition is barking up the wrong tree in this particular case. Don't get me wrong here; I'm all for liberating autoconf from the GPL. But it would be better still to get rid of it altogether. How about a contest whose goal is to create a standard set of library functions, APIs, and macros for Python, Perl, C, C++, Pascal, etc., that eliminate the need for autoconf?
Open source licensed under the BSD or MIT X licence cannot be "made proprietary." If someone creates a closed source or more restrictively licensed program using the code, it is only the new product which is restrictively licensed. And since the original code is still available to anyone for free, no one will buy the improved version unless the improvements are valuable. In short, any money that person makes from the resulting product will be the fruits of his or her own labor. That's fair.
If someone who uses information gained at the public library to make money, we don't try to deprive that enterprising person of that money because he or she wisely used a public resource. The same is true of open source. Let's not fall into the GPL's mean-spirited trap of spite. If you're going to share software, share it for real, with no strings attached -- not halfheartedly or grudgingly.
It's funny that with all of the libel that RMS takes for his stands,
I have not seen RMS libeled. I have, however, seen legitimate criticism of his mean-spirited agenda, which is anti-commercial and anti-programmer.
you never see RMS suggest that others who don't support the GPL should stop using GPL'd products.
Of course not! This is because the use of his products helps to spread the "viral" GPL license. In fact, it is only because Linus, without fully understanding RMS's agenda, stamped the GPL onto Linux that Richard is now a public figure.
Gcc comes to mind as something that has benefitted many in the Open Source "Community" who snipe at RMS, the FSF and the GPL.
This shows the destructiveness of the GPL. While these people would very much prefer to use another tool, the predatory nature of the GPL has eliminated alternatives.
Now we can see the philosophy of some of those who support other "free" licenses. They are factionalists.
Not so. They differ with RMS, and with good reason. Stallman's agenda is one of spite and malice.
The FSF and the GPL support Freedom in software.
By tying it up with a multi-page license that's rife with legalese and places massive restrictions on its use. Yeah, right.
The software is permitted to be used by anyone, even those who work against FSF goals.
Not so. While many users (in particular, "end users") can use the software in the way that best suits their needs, programmers cannot. This is the purpose of the GPL: to transform open source from a public good into a weapon directed against those who engage in activities of which Richard Stallman does not approve.
We have filed suit in federal court to stop internet hackers from distributing the software designed to circumvent the encryption technology that prevents the unlawful copying of DVDs."
The flaw in this argument -- and also in the complaint in the lawsuit -- is that the CSS (Content Scrambling System) does not prevent copying -- lawful or otherwise. It prevents you from playing the DVD -- the original or the copy -- on a player which the industry group that controls the system has not licensed.
In short, it's designed to extract royalties from the makers of the players. It also has another purpose: to enforce "region locking."
"Region locking" allows the vendor to sell copies of the same work for different prices in different markets. The disks are unplayable by players sold outside the region in which the disks are intended to be sold. Region locking prevents "parallel imports" -- a form of arbitrage in which an enterprising dealer imports product from a region or country where it's sold for less money.
Region locking is, technically, a violation of the Robinson-Patman Act, an antitrust law which prohibits the manipulation of markets by charging different prices for the same product. But this doesn't keep the vendors from trying.
In any event, the key point is that CSS does not, in any way, prevent copying. If you make a bit-for-bit copy of a DVD, it will be playable on any machine that could play the original.
In an earlier posting, I discussed potential problems with the export of GPLed code. But regardless of what one thinks about licensing issues, there's another more serious problem with the regulations as I read them. The provision that allows the export of source code says:
Also in 740.13, to, in part, take into account the "open source" approach to software development,
unrestricted encryption source code not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code can, without review, be released from "EI" controls and exported and reexported under License Exception TSU.
Note the use of the qualifier "unrestricted" in the paragraph above. So, what's "unrestricted?" The text gives what appears to be an answer:
In 740.13, Technology and Software
Unrestricted, changes are made to reflect amendments to the Wassenaar Arrangement. Specifically, encryption software is no longer eligible for mass market treatment under the General Software Note. Encryption commodities and software are now eligible for mass market treatment under the new Cryptography Note in Category 5 - Part 2 of the CCL. This Note multilaterally decontrols mass market encryption commodities and software up to and including 64-bits.
So, if I read the draft correctly, no open source crypto software that's strong enough to protect anyone's privacy against a marginally competent code cracker can be exported, even under the new rules.
To recognize the implications requires a careful reading of the regulation as well as an understanding of the GPL.
It is true that the GPL doesn't require you to pay a licensing fee or royalty... so long as you give your own work away. However, if you wish to use the GPLed code to make a COMMERCIAL product, you must pay royalties or licensing fees.
The language of the regulation says that if a royalty is required to use the code in ANY commercial product (even one!), it is not freely exportable.
Maybe this was not an anticipated consequence, but this is what the current language of the regulation says.
This may be a very, very good thing. If encryption code is published under a license that allows commercial reuse, such as the MIT X license or BSD license, it will be incorporated into commercial products as well as free ones, and closed source products as well as open source ones. This will promote standardization, as did UC Berkeley's release of the BSD TCP/IP stack. (The fact that the BSD TCP/IP stack was released for commercial as well as non-commercial use is often said to be responsible for the ubiquity of the Internet today.) If we want to see encryption become ubiquitous as well, this is a highly desirable way to go.
The GPL, by contrast, promotes fragmentation and incompatibility by preventing commercial developers from using the same code base as those who are publishing open source.
So, export rules which require exported open source code to be usable in ANY commercial product, without royalties, may be the absolute best thing we can do to promote the widespread use of strong cryptography.
Even advocates of the GPL will agree, I think, that the GPL's restrictions are very counterproductive in this particular case.
I am not sure whether those who drafted the regulations understood, or cared about, the political agenda of the GPL in particular. But clearly, what they had in mind was to insist that exported open source crypto code be usable by all developers -- whether or not they publish their own source or gave away their code for free. This is the right approach.
Also in 740.13, to, in part, take into account the "open source" approach to software development, unrestricted encryption source code not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code can, without review, be released from "EI" controls and exported and reexported under License Exception TSU.
Under this rule, code released under the BSD or MIT X license would clearly be OK. But what if the code is licensed under the GPL? Because the GPL sets forth a specific quid pro quo for developers who wish to use the code (to wit: the developer must reveal his own source code and give away his work), it would not be exportable under this rule. This would actually be a good thing, since it would discourage the use of the GPL -- a license whose express purpose is to hurt commercial developers. But some of the GPL "faithful" would doubtless not like it.
I'll never forget my first encounter with the Apple ][ computer. In 1979, as a college sophomore working at a summer job for NASA, I adapted a $4,000 Apple ][ to control a Varian Auger spectrometer, creating the very first scanning Auger spectrometer. My idea of grafting an inexpensive personal computer into a $500,000 piece of equipment that took up half of a room was greeted with some trepidation by the scientists, but I convinced them that we could switch my interface off and return the equipment to normal if it didn't work. Fortunately, the contraption did work (though all of the software wasn't finished by the end of the summer), and we had a true technological advance which is still a useful analytical tool today.
Anyway, in the course of my labors, I ran into a technical glitch and called Apple for help. Dan Kottke answered the phone, and I told him that I thought I'd found a bug in the ROM. (Note: The Apple ][, for those who never saw the manuals, came with complete, commented source code for the internal ROMs. The code wasn't free for anyone to use, and justifiably so; they were the product of a brilliant mind and who knows how many hours of work. However, the source made a great reference for me and many others.)
"Yes, Woz was just talking about that," Dan replied.
"What was?" I asked innocently.
"Woz was," said Dan.
"Oh," I replied. (After mentally trying several different parsings of this last statement I finally realized that "Woz" must be someone's name.... The modest Mr. Wozniak had only put his name in a few places in the assembly language code, so I didn't spot it there until later.)
We went on to discuss how to work around the bug. I was very impressed by this.... Today, the notion of being able to get someone who's technically knowledgeable about a product -- especially at the assembly language level -- on the phone is almost unbelievable.
But those were the days of what I consider to be "true hacking" -- sweating for hours to implement one's ideas in the smallest possible number of logic gates or opcodes. I was very impressed by the small number of gates in the disk drive's group encoder and the subtle software that made it work.
Which brings me to my question. Nowadays, few people -- even those who call themselves "hackers" -- are capable of hacking on that level. "Hello world" programs take up hundreds of thousands of bytes... and if a project requires analog circuit design -- as a blue box did -- forget it!
Do you think there's still a place in the world for the old school hacker who can make a silk purse out of a sow's ear? For the assembly language programmer who can do in 100 bytes what others do in 100,000? Or are those days of true craftsmanship gone forever?
that helped me along to this conclusion. Because of him, I used my influence at a major manufacturing company (considering requiring all mission critical systems be open source) to convince them that the *BSDs were NOT open source - and they bought the argument.
In short, you admit outright that you told a destructive lie to your employer or client. I hope you're proud of yourself. No, on second thought, it's quite obvious that you are not, since you've posted as "Anonymous Coward."
It's obvious that you yourself believed that you would have had a more difficult time selling your employer on Linux vs. BSD if you'd been ethical enough to be truthful.
Software patents would not be as prevalent nor as necessary as they are today were it not for two factors: (1) The increased use of giveaways to undermine competitive products (e.g. Sun's giveaway of StarOffice to undermine Microsoft Office) and (2) The spread of the GPL.
Suppose that you're a promising young programmer who really stands to make a contribution to the state of the art. You're good at developing new ways of doing things, and you deserve a reasonable reward for your honest, hard work.
Unfortunately, you face two threats. First, large corporations -- Microsoft comes to mind but is by far not the only relevant example -- may copy your work. Via bundling, giveaways (e.g. Microsoft's "cut off their air supply" strategy which so effectively destroyed Netscape), and/or sheer mass, they use your own ideas to destroy your livelihood.
The second threat comes from the GPL. If your products become pervasive, the ideologues who have bought into the notion that all software should be freely copyable and available at no charge will release GPLed software that provides the same function. As with Netscape, you cannot compete with free -- not even enough to maintain a workplace in which you and others can labor over future innovations.
Worse still, a competitor may well sponsor the development of a GPLed product that competes with yours. This strategy has two advantages for the competitor. First, your funding for the development of competing products is sapped, so you're unlikely to be a threat in the future. Second, the competitor can skirt claims of predatory pricing and unfair competition by pointing to the nebulous and transient band of developers who wrote portions of the GPLed product. "It's not us," they'll say; "We only provided a little help. It's that ragtag bunch of programmers that did the deed."
The only defense against all of these potential calamities is a strong software patent. I once opposed software patents, and I still believe that they last too long. However, I now recognize that, especially, they are necessary to prevent the GPL -- which was created specifically to destroy commercial developers -- from achieving its malicious and spiteful goals. (Yes, I know that not everyone who uses the GPL does so out of spite and malice, but its use furthers the same agenda nonetheless.) While we should fight overly broad and erroneously issued patents, we should be on the side of developers who have legitimately created something new. Otherwise, we will be steering rewards to the copycats, the marketers, and the already rich and powerful -- and away from those who deserve our thanks for advancing the state of the art.
Actually, it's making $30K on a Linux IPO that's leeching. You're leeching on the poor stock market suckers who don't recognize that Red Hat does not even own the software of which it is selling copies, and therefore cannot be considered to have any significant intrinsic value at all.
That is leeching. Earning an honest wage by doing creative work and licensing it is not.
The GPL does not meet the requirements set forth here, because it discriminates against the authors and pubishers of commerical software. Therefore, GPLed software would be excluded by this text.
Which is a good thing, IMHO. The GPL attempts to turn open source into a weapon against business, and this is not a good thing.
Ah, but to the GPL fanatic, commercial software is immoral and must be destroyed at all costs. The end justifies the means -- and the means, alas, include forced denial of choice. (That's what the GPL is about, too: coercing authors to forfeit any reward they might otherwise reap from their hard work.)
If you point out -- rightly -- that the proposed law mentioned above denies freedom, they'll do the old "pivot word" trick and say, "No, you don't get it! It's not free speech, it's free beer! Or is it the other way around? Doesn't matter.... Whichever meaning of free you're talking about, we mean some different one, so your argument's irrelevant."
And your problem, Brett, is that you are willing to prosper, to raise yourself higher, by standing on the backs of your fellow man.
We should all stand on one another's shoulders. As Brian Reid once put it, scientists stand on one another's shoulders, but programmers seem intent upon standing on one another's feet!
Civilization can never advance so long as we take personal profit from the good works of others.
Not true at all. When we make a contribution to the state of the art by building on what has been done before, we should be rewarded for having done so. And the more one contributes, the more one should be rewarded.
--Brett Glass
P.S. -- Since I'm not posting as "Anonymous Coward," I hope you'll own up to your own ideas and do likewise.
Sorry, but -- bzzzt! -- I think that folks are learning your true motivations at last. The fact is that it's the GPL which hurts others, by turning open source software -- which was originally free for all to use for any purpose -- into a weapon against business. For the sole purpose of fulfilling your spiteful grudge kindled some 15 years ago.
Mandating that anyone -- and the government in particular, since it is a large customer -- not buy commercial software means killing the software industry in that country, which in turn means destroying jobs. It's not rocket science; it's common sense.
It is also not in the citizens' best interest. The people will be best served if government procures the best software for the job. And to insist that government boycott native businesses in favor of almost entirely foreign products is an idea that only Richard Stallman -- who spitefully wishes to see all commercial software companies destroyed at any cost -- could love.
This is the most anti-business, anti-programmer move I could possibly imagine. Government should not embrace agendas, like the GPL, which are explicitly designed to put people out of work.
Such a measure would be a terrible blow to Brazil's software industry and to programmers everywhere.
Good article -- and I enjoyed the references, too. (I hadn't known that Tog had posted so much of his ergonomics stuff online.)
I disagree with you on one point, however. In the article, you state that the vi command set is superior to that of EMACS because it allows the use of unadorned keys rather than chords.
Personally, as a keyboardist, I have no trouble with chords; in fact, I love 'em. They add great power to muscle memory: there's more that you can call forth, without thinking, with one gesture.
vi, on the other hand, is modal, and for me this is much more painful. Realizing that the command one wants is not available in the current mode, exiting the current mode, and entering the correct one breaks one's stride and concentration. There's always that extra brain cell or two that has to be devoted to remembering what mode you're in instead of holding other valuable information in short-term memory. And trying to do something when you are in the wrong mode -- a common error that the best of us make -- is a real Zen zapper. Especially as you back out, with much annoyance, the damage you did to your work.
I would fault not EMACS (or WordStar) for using chords, but rather the keyboard for making them hard to grab and adding so many gratuitous, single purpose keys.
What a platform finds it hard to weather is a dearth of useful applications. Why do so many people still use Windows, like it or not? Because they can't get the apps for other platforms.
Likewise, BSD users will be forced to other platforms unless there is native application support. Emulation is a stopgap measure, but does not cut it for mission-critical work. Software vendors will refuse to support applications when they run under emulation.
It's nice for FreeBSD users that Quake, VMWare, StarOffice, and other products published as native binaries for Linux can run on the Linux ABI, but it may be bad for the platform in the long term. Vendors will simply say, "We don't need to support FreeBSD; just run the Linux version!" Such an approach would consign FreeBSD to being Linux's ugly stepsister -- potentially forever. This has happened to other platforms. The Windows emulation in OS/2 virtually eliminated development of native OS/2 applications. Another example: FreeBSD has a larger installed base than Solaris, and yet there are more native ports to Solaris than to FreeBSD. FreeBSD users should be concerned that this is a sign that the phenomenon mentioned above is starting to happen. My take: FreeBSD users will have to bombard manufacturers with requests for native ports to overcome the negative effects of emulation. --Brett Glass
Slashdot Mirror
For leading the world's most pervasive and successful open source project ever. Sidestepping political issues, he's focused on producing good code and has achieved >50% market share -- a number unequalled by any other open source project.
--Brett Glass
The reason for this is that a 501(c)(3), legally, is not allowed to engage in activities which are the same as those normally carried out by for-profit businesses or to compete with them. The explicit purpose of the FSF is to compete with -- in fact, to damage -- for-profit businesses by giving away for free what those businesses sell. This is not a permitted activity.
--Brett Glas
Ironically, Python and Perl are both far more portable than C and C++, for which autoconf was primarily designed, because the libraries do a better job of hiding platform dependencies.
Perhaps the competition is barking up the wrong tree in this particular case. Don't get me wrong here; I'm all for liberating autoconf from the GPL. But it would be better still to get rid of it altogether. How about a contest whose goal is to create a standard set of library functions, APIs, and macros for Python, Perl, C, C++, Pascal, etc., that eliminate the need for autoconf?
--Brett Glass
If someone who uses information gained at the public library to make money, we don't try to deprive that enterprising person of that money because he or she wisely used a public resource. The same is true of open source. Let's not fall into the GPL's mean-spirited trap of spite. If you're going to share software, share it for real, with no strings attached -- not halfheartedly or grudgingly.
--Brett
I have not seen RMS libeled. I have, however, seen legitimate criticism of his mean-spirited agenda, which is anti-commercial and anti-programmer.
you never see RMS suggest that others who don't support the GPL should stop using GPL'd products.
Of course not! This is because the use of his products helps to spread the "viral" GPL license. In fact, it is only because Linus, without fully understanding RMS's agenda, stamped the GPL onto Linux that Richard is now a public figure.
Gcc comes to mind as something that has benefitted many in the Open Source "Community" who snipe at RMS, the FSF and the GPL.
This shows the destructiveness of the GPL. While these people would very much prefer to use another tool, the predatory nature of the GPL has eliminated alternatives.
Now we can see the philosophy of some of those who support other "free" licenses. They are factionalists.
Not so. They differ with RMS, and with good reason. Stallman's agenda is one of spite and malice.
The FSF and the GPL support Freedom in software.
By tying it up with a multi-page license that's rife with legalese and places massive restrictions on its use. Yeah, right.
The software is permitted to be used by anyone, even those who work against FSF goals.
Not so. While many users (in particular, "end users") can use the software in the way that best suits their needs, programmers cannot. This is the purpose of the GPL: to transform open source from a public good into a weapon directed against those who engage in activities of which Richard Stallman does not approve.
--Brett Glass
We have filed suit in federal court to stop internet hackers from distributing the software designed to circumvent the encryption technology that prevents the unlawful copying of DVDs."
The flaw in this argument -- and also in the complaint in the lawsuit -- is that the CSS (Content Scrambling System) does not prevent copying -- lawful or otherwise. It prevents you from playing the DVD -- the original or the copy -- on a player which the industry group that controls the system has not licensed.
In short, it's designed to extract royalties from the makers of the players. It also has another purpose: to enforce "region locking."
"Region locking" allows the vendor to sell copies of the same work for different prices in different markets. The disks are unplayable by players sold outside the region in which the disks are intended to be sold. Region locking prevents "parallel imports" -- a form of arbitrage in which an enterprising dealer imports product from a region or country where it's sold for less money.
Region locking is, technically, a violation of the Robinson-Patman Act, an antitrust law which prohibits the manipulation of markets by charging different prices for the same product. But this doesn't keep the vendors from trying.
In any event, the key point is that CSS does not , in any way, prevent copying. If you make a bit-for-bit copy of a DVD, it will be playable on any machine that could play the original.
--Brett Glass
--Brett Glass
Note the use of the qualifier "unrestricted" in the paragraph above. So, what's "unrestricted?" The text gives what appears to be an answer:
So, if I read the draft correctly, no open source crypto software that's strong enough to protect anyone's privacy against a marginally competent code cracker can be exported, even under the new rules.
--Brett Glass
It is true that the GPL doesn't require you to pay a licensing fee or royalty... so long as you give your own work away. However, if you wish to use the GPLed code to make a COMMERCIAL product, you must pay royalties or licensing fees.
The language of the regulation says that if a royalty is required to use the code in ANY commercial product (even one!), it is not freely exportable.
Maybe this was not an anticipated consequence, but this is what the current language of the regulation says.
This may be a very, very good thing. If encryption code is published under a license that allows commercial reuse, such as the MIT X license or BSD license, it will be incorporated into commercial products as well as free ones, and closed source products as well as open source ones. This will promote standardization, as did UC Berkeley's release of the BSD TCP/IP stack. (The fact that the BSD TCP/IP stack was released for commercial as well as non-commercial use is often said to be responsible for the ubiquity of the Internet today.) If we want to see encryption become ubiquitous as well, this is a highly desirable way to go.
The GPL, by contrast, promotes fragmentation and incompatibility by preventing commercial developers from using the same code base as those who are publishing open source.
So, export rules which require exported open source code to be usable in ANY commercial product, without royalties, may be the absolute best thing we can do to promote the widespread use of strong cryptography.
Even advocates of the GPL will agree, I think, that the GPL's restrictions are very counterproductive in this particular case.
I am not sure whether those who drafted the regulations understood, or cared about, the political agenda of the GPL in particular. But clearly, what they had in mind was to insist that exported open source crypto code be usable by all developers -- whether or not they publish their own source or gave away their code for free. This is the right approach.
--Brett Glass
Under this rule, code released under the BSD or MIT X license would clearly be OK. But what if the code is licensed under the GPL? Because the GPL sets forth a specific quid pro quo for developers who wish to use the code (to wit: the developer must reveal his own source code and give away his work), it would not be exportable under this rule. This would actually be a good thing, since it would discourage the use of the GPL -- a license whose express purpose is to hurt commercial developers. But some of the GPL "faithful" would doubtless not like it.
--Brett Glass
I'll never forget my first encounter with the Apple ][ computer. In 1979, as a college sophomore working at a summer job for NASA, I adapted a $4,000 Apple ][ to control a Varian Auger spectrometer, creating the very first scanning Auger spectrometer. My idea of grafting an inexpensive personal computer into a $500,000 piece of equipment that took up half of a room was greeted with some trepidation by the scientists, but I convinced them that we could switch my interface off and return the equipment to normal if it didn't work. Fortunately, the contraption did work (though all of the software wasn't finished by the end of the summer), and we had a true technological advance which is still a useful analytical tool today.
Anyway, in the course of my labors, I ran into a technical glitch and called Apple for help. Dan Kottke answered the phone, and I told him that I thought I'd found a bug in the ROM. (Note: The Apple ][, for those who never saw the manuals, came with complete, commented source code for the internal ROMs. The code wasn't free for anyone to use, and justifiably so; they were the product of a brilliant mind and who knows how many hours of work. However, the source made a great reference for me and many others.)
"Yes, Woz was just talking about that," Dan replied.
"What was?" I asked innocently.
"Woz was," said Dan.
"Oh," I replied. (After mentally trying several different parsings of this last statement I finally realized that "Woz" must be someone's name.... The modest Mr. Wozniak had only put his name in a few places in the assembly language code, so I didn't spot it there until later.)
We went on to discuss how to work around the bug. I was very impressed by this.... Today, the notion of being able to get someone who's technically knowledgeable about a product -- especially at the assembly language level -- on the phone is almost unbelievable.
But those were the days of what I consider to be "true hacking" -- sweating for hours to implement one's ideas in the smallest possible number of logic gates or opcodes. I was very impressed by the small number of gates in the disk drive's group encoder and the subtle software that made it work.
Which brings me to my question. Nowadays, few people -- even those who call themselves "hackers" -- are capable of hacking on that level. "Hello world" programs take up hundreds of thousands of bytes... and if a project requires analog circuit design -- as a blue box did -- forget it!
Do you think there's still a place in the world for the old school hacker who can make a silk purse out of a sow's ear? For the assembly language programmer who can do in 100 bytes what others do in 100,000? Or are those days of true craftsmanship gone forever?
--Brett Glass
The name's Brett Glass, thank you very much.
that helped me along to this conclusion. Because of him, I used my influence at a major manufacturing company (considering requiring all mission critical systems be open source) to convince them that the *BSDs were NOT open source - and they bought the argument.
In short, you admit outright that you told a destructive lie to your employer or client. I hope you're proud of yourself. No, on second thought, it's quite obvious that you are not, since you've posted as "Anonymous Coward."
It's obvious that you yourself believed that you would have had a more difficult time selling your employer on Linux vs. BSD if you'd been ethical enough to be truthful.
--Brett Glass
Suppose that you're a promising young programmer who really stands to make a contribution to the state of the art. You're good at developing new ways of doing things, and you deserve a reasonable reward for your honest, hard work.
Unfortunately, you face two threats. First, large corporations -- Microsoft comes to mind but is by far not the only relevant example -- may copy your work. Via bundling, giveaways (e.g. Microsoft's "cut off their air supply" strategy which so effectively destroyed Netscape), and/or sheer mass, they use your own ideas to destroy your livelihood.
The second threat comes from the GPL. If your products become pervasive, the ideologues who have bought into the notion that all software should be freely copyable and available at no charge will release GPLed software that provides the same function. As with Netscape, you cannot compete with free -- not even enough to maintain a workplace in which you and others can labor over future innovations.
Worse still, a competitor may well sponsor the development of a GPLed product that competes with yours. This strategy has two advantages for the competitor. First, your funding for the development of competing products is sapped, so you're unlikely to be a threat in the future. Second, the competitor can skirt claims of predatory pricing and unfair competition by pointing to the nebulous and transient band of developers who wrote portions of the GPLed product. "It's not us," they'll say; "We only provided a little help. It's that ragtag bunch of programmers that did the deed."
The only defense against all of these potential calamities is a strong software patent. I once opposed software patents, and I still believe that they last too long. However, I now recognize that, especially, they are necessary to prevent the GPL -- which was created specifically to destroy commercial developers -- from achieving its malicious and spiteful goals. (Yes, I know that not everyone who uses the GPL does so out of spite and malice, but its use furthers the same agenda nonetheless.) While we should fight overly broad and erroneously issued patents, we should be on the side of developers who have legitimately created something new. Otherwise, we will be steering rewards to the copycats, the marketers, and the already rich and powerful -- and away from those who deserve our thanks for advancing the state of the art.
--Brett Glass
That is leeching. Earning an honest wage by doing creative work and licensing it is not.
--Brett Glass
Which is a good thing, IMHO. The GPL attempts to turn open source into a weapon against business, and this is not a good thing.
--Brett Glass
If you point out -- rightly -- that the proposed law mentioned above denies freedom, they'll do the old "pivot word" trick and say, "No, you don't get it! It's not free speech, it's free beer! Or is it the other way around? Doesn't matter.... Whichever meaning of free you're talking about, we mean some different one, so your argument's irrelevant."
--Brett Glass
We should all stand on one another's shoulders. As Brian Reid once put it, scientists stand on one another's shoulders, but programmers seem intent upon standing on one another's feet!
Civilization can never advance so long as we take personal profit from the good works of others.
Not true at all. When we make a contribution to the state of the art by building on what has been done before, we should be rewarded for having done so. And the more one contributes, the more one should be rewarded.
--Brett Glass
P.S. -- Since I'm not posting as "Anonymous Coward," I hope you'll own up to your own ideas and do likewise.
Sorry, but -- bzzzt! -- I think that folks are learning your true motivations at last. The fact is that it's the GPL which hurts others, by turning open source software -- which was originally free for all to use for any purpose -- into a weapon against business. For the sole purpose of fulfilling your spiteful grudge kindled some 15 years ago.
--Brett Glass
It is also not in the citizens' best interest. The people will be best served if government procures the best software for the job. And to insist that government boycott native businesses in favor of almost entirely foreign products is an idea that only Richard Stallman -- who spitefully wishes to see all commercial software companies destroyed at any cost -- could love.
--Brett Glass
Such a measure would be a terrible blow to Brazil's software industry and to programmers everywhere.
--Brett Glass
I disagree with you on one point, however. In the article, you state that the vi command set is superior to that of EMACS because it allows the use of unadorned keys rather than chords.
Personally, as a keyboardist, I have no trouble with chords; in fact, I love 'em. They add great power to muscle memory: there's more that you can call forth, without thinking, with one gesture.
vi, on the other hand, is modal, and for me this is much more painful. Realizing that the command one wants is not available in the current mode, exiting the current mode, and entering the correct one breaks one's stride and concentration. There's always that extra brain cell or two that has to be devoted to remembering what mode you're in instead of holding other valuable information in short-term memory. And trying to do something when you are in the wrong mode -- a common error that the best of us make -- is a real Zen zapper. Especially as you back out, with much annoyance, the damage you did to your work.
I would fault not EMACS (or WordStar) for using chords, but rather the keyboard for making them hard to grab and adding so many gratuitous, single purpose keys.
--Brett Glass
Likewise, BSD users will be forced to other platforms unless there is native application support. Emulation is a stopgap measure, but does not cut it for mission-critical work. Software vendors will refuse to support applications when they run under emulation.
--Brett
Moderators: Please moderate the above down to -2, or remove it altogether.
It's nice for FreeBSD users that Quake, VMWare, StarOffice, and other products published as native binaries for Linux can run on the Linux ABI, but it may be bad for the platform in the long term. Vendors will simply say, "We don't need to support FreeBSD; just run the Linux version!" Such an approach would consign FreeBSD to being Linux's ugly stepsister -- potentially forever. This has happened to other platforms. The Windows emulation in OS/2 virtually eliminated development of native OS/2 applications. Another example: FreeBSD has a larger installed base than Solaris, and yet there are more native ports to Solaris than to FreeBSD. FreeBSD users should be concerned that this is a sign that the phenomenon mentioned above is starting to happen. My take: FreeBSD users will have to bombard manufacturers with requests for native ports to overcome the negative effects of emulation. --Brett Glass