There are lots of reasons to "give code back" to a Free Software project. The biggest reason is that if you donate code you end up getting help maintaining it.
As an example. Quite some time ago I needed some specialized graphs for my employer. At the time I was using Perl as my tool of choice, and so I found a module on CPAN that didn't 90% of what I needed. So I spent a few days figuring out how it worked (Perl's TMTOWTDI worked against me there:), and I extended it so that it would do what I needed. When I was finished I thought momentarily about sharing my extensions (they were general purpose enough that they would have been useful), but I decided it would be too much of a hassle.
The problems started about 6 months later when I needed to upgrade the box that had been happily drawing graphs all this time. The new version of Perl that came with the distribution upgrade wasn't compatible with my modified version of the graphing module. What was worse was that the new version of the graphing module I used now included a set of extensions that was roughly equivalent to what I had written but not compatible. Just like that I had gotten myself into the business of maintaining my own version of this particular module.
From what I have read, the vast majority of folks writing software work for companies that aren't in the software business. There is plenty of opportunity for these folks to use and extend Free Software on their company's dime. Reusing Free Software allows these folks to get the benefits of custom software development at a fraction of the cost of starting from scratch. Sharing the parts that are general purpose not only makes sure that the technologies you have chosen to base your business on remains competitive, but it also guarantees that you will have help maintaining and improving these parts of the project in the future.
The primary business model for Free Software isn't about selling software (although some of that happens as well), it is about saving money on software purchases.
For consultants Free Software makes a different kind of sense. Free Software allows you the opportunity to compete with much larger organizations by leveraging the Free Software community. There is no chance that you could, on your own, write an operating system that would compete with Windows. However, by taking Linux and modifying for a customer you could deliver a custom product that rivals Microsoft's generic product at a fraction of the cost of Windows.
The fact of the matter is that software is becoming a commodity. As such it is becoming worth less and less as a product in and unto itself. The true value of software lies in the knowledge that the person has that can be used to solve specific problems. Software, in this case, is only a tool, it isn't a product. This trend is good for individual coders, but it is devastating to corporations that rely on the high profit margins that software development has traditionally delivered.
No, I got your point. In fact, my last paragraph even reiterated your point. Here it is again.
My original point, and it is still a good one, is that including GPLed code in your proprietary package is ultimately more trouble than it is worth. Eventually you probably will get caught distributing the software without a license, and at that point you have serious problems.
Of course, this also applies to including code from any software that you don't have a license to distribute. There are plenty of software packages that one might want to redistribute with their own code, many don't even come with source code.
I happen to believe that the GPL is an excellent software license, and the fact that the FSF has never had to take the GPL to court testifies to the fact that they are reasonable folks to work with when it comes to clearing up issues. I also am fully in agreement with the fact that the GPL is no worse than any copyright-based license, and is better than most. None of my posts were meant to be an attack on the GPL, GPL advocates, the FSF, or any other group of Free Software hackers.
My point is simply that there is little chance that a successful corporation like Microsoft would try and sneak GPLed code into one of their products (especially a major product). It's just too risky. Heck, Microsoft even has products that they distribute under the GPL (I believe some of the Interix stuff they bought included GNU packages), but they aren't even thinking about combining that GPLed source with their proprietary software. For political reasons it would be better to steal someone else's proprietary source than be caught with their hand in the GPL cookie jar.
Perhaps "forced" is the wrong word, but including GPLed code in your software certainly does limit your options. I don't think this is even a bad thing, just a true one.
The amount of coercion applied is also likely to depend on whose code you have borrowed. For example, I highly doubt that the FSF will let you distribute their GPLed code as part of a proprietary package in exchange for a weekly car wash. They're good guys, but they are going to push for compliance with the terms of the GPL. Other organizations like Trolltech or MySQL AB, on the other hand, actually encourage folks to buy a closed source license of their GPLed works.
My original point, and it is still a good one, is that including GPLed code in your proprietary package is ultimately more trouble than it is worth. Eventually you probably will get caught distributing the software without a license, and at that point you have serious problems. Of course, this also applies to including code from any software that you don't have a license to distribute. There are plenty of software packages that one might want to redistribute with their own code, many don't even come with source code.
Yes, good point. The owner of the misused GPL copyrights would either be due a large monetary fine as compensation for misusing the GPLed copyrights, plus the derivative work would be undistributable until it was cleaned up, or the company would have to release their source code.
Just because up until this point the companies in quesiton have always opted to release source code does not mean that this will always be the case. The fact of the matter is that the GPL is a pretty big hammer. As the folks scooped up by the RIAA are finding out copyright enforcement is an area of the law with ridiculously high penalties. Most companies, when faced with the prospect of paying ridiculously large penalties and being forced to stop distribution of their software until they can remove the GPLed code wisely choose to release source themselves. They don't have to, but they have got much alternative.
Of course, this only applies in those cases where there is a substantial amount of GPLed code that has been borrowed. Otherwise damage control is fairly easy.
Apparently lots of people listen to ESR, including big-wigs at IBM and Sun. Don't worry, he won't lead anyone to believe that he speaks for October 30th.
I highly doubt it. Just like the Business Software Alliance commercials tell us, it would only take one disgruntled employee to wreck your entire day. If Microsoft "borrowed" GPLed code and tried to hide it not only would they open themselves up to a serious lawsuit from the copyright holders (with serious monetary penalties), but they could theoretically end up having to share any source code that came in contact with the GPLed code.
When it comes to GUI desktop software Sun has already lost control of Java. Oracle has their own JVM that is required to run their Java applications. IBM has SWT that is basically doing precisely the same thing that Microsoft got in trouble over all those years ago. Free Software hackers are working on their own version of Swing that can be compiled with gcj. Not to mention the various and sundry Java-like JVMs that are available (Kaffe, sablevm, etc.).
If Sun released their JVM under the GPL people would still continue to get their JVM from Sun, the only difference is that Sun's JVM would become more acceptable to the Free Software community. In fact, it would probably take a lot of the wind from the sails of these projects that are making divergent versions of Java (SWT is the best example of this).
Yes, that's why the ASL2.0 is such a disappointment. It was supposed to be GPL compatible. There are lots of hackers that would like to be able to distribute their software with Apache, but they can't because of stupid licensing issues. If the thing separating the ASL2.0 was a big issue, then perhaps that would be something, but it's not. And so the folks working on Apache software are denied the use of GPL software just for a few niggly words.
No one is forcing anyone to use GPLed software. In fact, the reason that Open Source licenses tend towards GPL compatibility is that there are piles of GPLed software that folks writing software under the other licenses want to use. There is far more useful code licensed under the GPL than all of the variants of the ASL put together. Lots of folks working on Apache projects would probably like to "borrow" bits of GPLed code. However, if they do they can no longer distribute their product. If the difference in the two licenses was large then it might make sense for the ASL hackers to deny themselves access to the GPLed software. However, the differences are so small that many folks are inclined to ignore them completely. Generally speaking, it doesn't make sense to wall yourself off from the largest source of freely available code in the known universe.
Saying that the GPL is "all about gimme" is just ridiculous since the reason that most of the licenses that have changed to become GPL compatible have done so because they want to borrow GPLed software (and not the other way around). Python is perhaps the one exception to this rule. Python's license was changed primarily so that Python hackers could embed the Python VM into GPLed software. Even so, the license change benefitted everyone involved.
As for the FSF being a threat to our "freedom" that's just patently ridiculous. The GPL is definitely a threat to folks that want to take open source software and turn it into proprietary software, but it's not a threat to any of the rest of us.
I definitely agree. However, BSD advocates definitely do care about this sort of thing. That's why they are always talking about how the GPL is viral (so are proprietary licenses, but they never mention that). The real problem is that GPLed derivatives of BSD projects sometimes compete successfully with the original BSD project. When this happens the BSD licensed code generally falls into disuse and suffers from bit rot. After that there is one less project that is available under the less stringent BSD license. Sure, you could ressurect the old BSD code, but that's not nearly as attractive as using the fancy new GPLed code.
BSD projects don't have to compete with commercial derivatives of their project for Open Source hacker time and energy, but they *do* have to compete with GPL project derivatives. That's a big difference to some BSD purists.
It's not about the GPL being holy scripture. It is about being able to take code from GPLed projects and combine then with code from ASL licensed projects. If these two licenses aren't compatible then the resulting derivative work can't be distributed legally.
The reason that this is a problem for Apache is that there is a *lot* of GPLed code out there. In fact, last I checked there are quite a few GPLed Apache modules. Now these modules can't be distributed with Apache.
The problem with licensing issues is that they aren't minutia. In fact, licensing is ridiculously important (ask the KDE folks some time).
The problem is when you want to take some code that is already licensed under the GPL and combine it with ASL2.0 licensed code. All of a sudden you have a tool that compiles and works well, but can't be legally distributed.
The fact of the matter is that the FSF controls the copyrights to a big fat pile of source code, and if they say that derivatives of their GPLed source can't be combined with ASL2.0 source and legally distributed, then folks are going to listen to the FSF.
Since the FSF has a long history of not changind their stance on what is GPL-compatible there is an equally long history of projects changing their licenses to get the FSF blessing. Being cut off from using the millions of lines of FSF GPLed code is simply too big a deal. The Python license is a good example, as is the old QPL license (that QT used to use).
That's true, sort of. However, I can take BSD licensed code, compile it, distribute it, and if someone asks me for the source I can tell them to take a hike. I can also take BSD-licensed code, make some changes and distribute the resulting binaries under any license I wish (including the GPL).
That doesn't change the fact that you can still get the original BSD-licensed code from some other place, but it does mean that my derivative version is only available under the license I choose. The ammended BSD license is GPL compatible in that I can take BSD licensed code, combine it with a GPLed application and still be able to distribute the derivative work (under the GPL).
That's the reason that the BSD folks gets so cranky about the GPL. BSD code that gets combined with GPLed code can only be distributed under the GPL. It's a one-way street. GPL license advocates can poach from BSD licensed codebases, but the BSD folks can't do likewise (without being subject to the GPL). The real problem with this is that the GPL derivative of the BSD work often competes with the original BSD version for developer mindshare. If the GPL derivative becomes substantially more useful than the BSD original version then the GPL derivative sucks the air out of the room for the original version.
Perhaps "Free Software hackers don't support Java" was a little over the top. There are plenty of Free Software Java applications, especially in the web arena. In fact, one could even argue that the Free Software part of Java was the most vibrant part of the whole Java community. Where would Java be without Tomcat, JBoss, Ant, and the rest of the Free Software tools. If Sun's JVM were Free Software Java would almost certainly be even *more* popular.
I can guarantee you that this answer isn't good enough for the Free Software hackers working on Gnome, and it probably wouldn't be good enough for your lawyer if you happened to ask him if it was safe to embed the JVM in your GPLed application. With Python (or guile, or whatever) you are far safer from a legal perspective.
Besides which, who knows what Sun may do tomorrow. They are in a crunch for cash right now, and they might do all sorts of things to make the investors happy.
Life's too short to end up in court over a software licensing issue on a GPLed program, and so Free Software hackers don't support Java. There are plenty of other good Free Software tools. Free Software hackers don't need Sun nearly as much as Sun needs the help of the Free Software hackers.
In the end though, if Sun makes Java free, makes it run well on other systems, and turns control largely over to the community, how do they benefit in a way that their stockholders will recognize (in the form of increased prices and maybe that most mythical of beasts in the tech sector, a dividend?) This is a straight question, not a smarmy comment... I really can't see how Sun will benefit from an OS Java, defining benefit as "now we won't be bankrupt in 4 more quarters after all."
Sun wouldn't lose control over their JVM simply by GPLing it. They would still be the only folks that could license their JVM under any license but the GPL. It wouldn't really change the situation at all, except that Java would immediately become more popular with Free Software hackers. They might get a bit of free development help I suppose.
If Sun was currently making money with Java I wouldn't propose that they open it, but they aren't, and so what is the harm. Java is already a strategic initiative. And Sun is losing ground. IBM's Eclipse has gained far more support than Netbeans, and right behind it comes the demon of SWT over Swing. Java as a platform is already in jeopardy and.NET is sharpening its knives to have Java for breakfast.
Yes, but what are the licensing issues involved in embedding Sun's JVM into a GPLed application? This isn't a technical issue. This is a licensing issue after all. Not to mention the fact that it is a freedom issue. The Gnome folks wrote an entire desktop from scratch, including a widget set, because QT was the right flavor of free. There is no way that they are going to push to embed Java into Gnome.
Which is all the more reason to release Java under a dual GPL plus some commercial license. The Gnome hackers would love to be able to integrate Java more directly into the Gnome framework, but because of licensing issues this simply cannot be done (or at least it becomes much more difficult). For example, I can embed a Python interpretter in any GPLed application I choose (or any commercial application for that matter). But if I want to write an application that is extensible in Java, well I have to write the whole thing in Java.
Or take the Java-Gnome folks. They are currently primarily working towards being able to compile Java applications to native binaries with gcj and GNU classpath. They are about as excited about Java as a platform as Sun is about.NET as a platform. Sure, they support a few JVMs, but not well.
Like I said, the Free Software community would be happy to help, because Java really is pretty cool, but they can't because of the licensing issues. If Sun had a good reason for their reluctance that would be one thing, but they don't really have a good reason.
For example, one of the reasons that is sometimes forwarded for Sun keeping Java entirely in house is that they are afraid that if they free Java that it will split into divergent paths. However, Python, Perl, PHP, and the rest of the Free Software languages haven't had this problem. Heck, the closest we have come to a split in a development language was the gcc-egcs split. Java, on the other hand, is *currently* being split apart. IBM is making a big deal of SWT, and the GNU folks are making pretty good headway with their gcj compiler. gcj already compiles most software that people actually use (since there are so few GUI Java apps), and the is a GTK-Swing that is also making real headway. Not to mention the crazy Mono folks that are running Eclipse via IKVM.Net. If Sun continues on its current path Java is going to explode in several directions.
And on the other hand Java is facing increased competition from both.NET and the bevvy of competing Free Software tools.
The Free Software community doesn't need Java. They'll get along fine without it. However, Sun needs the Free Software developers to get on the Java train.
Fetchmail is the application that ESR is most well known for, but it's not the one that he has done the most work on. He simply used it as an example in CatB. Pick up any book on programming and you are likely to find examples. These examples are generally trivial, but the book wouldn't be the same without them. CatB was instrumental in explaining how Linux had become such a useful tool in so little time, fetchmail was simply a contrived example to prove the point.
As for the rest of ESR's hacker credentials. Well the initials ESR show up quite a bit in the software that I tend to use. Huge portions of Emacs were done by him (at one point he was the single largest contributor besides RMS, I don't know if that is true today), ESR also has credits in Python, the Linux kernel and piles of other projects that lots of people use everyday (like Nethack or bogofilter).
Here's a more comprehensive list of the ESR's work. Don't forget to click on the "projects" link for work that isn't classified as "software (termcap/terminfo database maintainer, for example, or the fact that he wrote the former Sunsite's Trove software). If you can honestly read that list of software and still come to the conclusion that ESR has done "nothing," then I would love to see your long list of Free Software accomplishments.
Don't get me wrong. I don't always agree with ESR, but I at least know enough about him to know better than to dismiss his credentials as a hacker.
Besides, on this ESR is right. Sun's Java desktop is indicative of the staggering amount of truly good stuff that is coming out of the Free Software community. Free Software hackers want to support Sun in its fight against Microsoft, but they aren't interested in using Sun's non-free Java language to do it. The funny part of Sun's Java Desktop is that there is essentially no Java involved. In fact, some of the same folks that wrote the Gnome desktop that comprises the bulk of Sun's Java desktop are right now working feverishly to finish off the first version of Mono, a.NET-alike for Linux. If Java was Free Software there would be a lot less incentive to do this, but Java isn't Free, and so the Mono hackers are cooking up a set of tools that can take its place for Free Software hackers.
What's worse, it's not like Sun can honestly say that they don't want to Free Java for commercial reasons. Java is currently available as a free download. Sun doesn't really make any money from Java.
The problem, as you say, appears to be personal. The folks at freedesktop.org have basically told the folks at XFree86 that they are tired of trying to work with them, and so now the XFree86 folks (David Dawes) have changed the license to make it more difficult for the freedesktop.org folks to simply use their source code.
The worst bit about this is that the XFree86 core haven't really been active developers for some time. In fact, most of their work predates Linux.
You can't pretend, however, that the licensing issue isn't important. Licensing issues generally turn out to be more important than technical issues. This change might not be *that* problematic, but who is to say that the next change won't be disastrous.
The part that you are missing is that the race is still in its very early stages. Apple has had no problems convincing folks with hundreds of dollars to spend that their iPod is worth the premium price that Apple charges for it, but once digital music players become a commodity Apple isn't likely to be able to hang with the rest of the pack.
As an example, remember when DVD players cost hundreds of dollars. You probably knew someone that had a DVD player back then. Heck, you probably even had one yourself, but the folks with DVD players were rare, and those folks that did have a DVD player probably owned a "premium" brand. Flash forward a couple of years and the $69.99 Apex special available at WalMart has more market share than any other DVD that has ever been made. In a couple of years the average digital music player will cost less than $50, and the best selling device will be the one that WalMart puts near the front of the store. Nothing Apple can do will change that fact.
Apple already knows how hard it is to compete in the cut throat world of hardware sales, and they know that consumer electronics are even worse than the computer industry. They aren't seriously aiming for that ridiculously low margin market.
Instead Apple wants to build up its iTunes.com website to the point where they can introduce their own artists and have Apple-fans purchase music from them directly. Apple's eventual goal is to cut out the music industry middle men and promote their own talent. That's where the money is, and Apple even admits it.
The only reason that the music industry is going along with Apple is that the music industry doesn't really have any choice. They can either sign up with WalMart.com or iTunes.com and sell songs for less than a buck a pop (but they get the lion's share of the profit), or they can let end users and artists set up their own distribution networks where they make nothing. The music industry knows that Apple is gunning to cut them out of the mix, but the alternatives are even worse.
WalMart's service costs $0.88 per song and it allows you to burn copies to CD. I don't know how well WalMart's service works, but I would guess in the long run that they are likely to have the lowest prices and the greatest ties to the least expensive media players.
In short, as long as digital media players is a high-end niche market Apple is likely to do well. However, when it becomes a commodity market WalMart is going to roll over them like they didn't exist.
Exactly. With Microsoft and WalMart both betting on Windows Media Player you can bet that the music distribution deal is going to end up being a price war, and Apple is going to lose.
Don't get me wrong. I agree that the eventual winner is very likely to adopt a policy similar to Apple's iTunes. Heck, WalMart's music downloading service is already pretty darn similar (and songs are $0.88). Apple has a good thing going, but there are simply too many vendors using WMP and too many computers with WMP installed for Apple to win out. Right now Apple is doing well on the strength of their iPod sales, but in the long run digital music players are going to be a commodity product.
Slashdot Mirror
There are lots of reasons to "give code back" to a Free Software project. The biggest reason is that if you donate code you end up getting help maintaining it.
As an example. Quite some time ago I needed some specialized graphs for my employer. At the time I was using Perl as my tool of choice, and so I found a module on CPAN that didn't 90% of what I needed. So I spent a few days figuring out how it worked (Perl's TMTOWTDI worked against me there :), and I extended it so that it would do what I needed. When I was finished I thought momentarily about sharing my extensions (they were general purpose enough that they would have been useful), but I decided it would be too much of a hassle.
The problems started about 6 months later when I needed to upgrade the box that had been happily drawing graphs all this time. The new version of Perl that came with the distribution upgrade wasn't compatible with my modified version of the graphing module. What was worse was that the new version of the graphing module I used now included a set of extensions that was roughly equivalent to what I had written but not compatible. Just like that I had gotten myself into the business of maintaining my own version of this particular module.
From what I have read, the vast majority of folks writing software work for companies that aren't in the software business. There is plenty of opportunity for these folks to use and extend Free Software on their company's dime. Reusing Free Software allows these folks to get the benefits of custom software development at a fraction of the cost of starting from scratch. Sharing the parts that are general purpose not only makes sure that the technologies you have chosen to base your business on remains competitive, but it also guarantees that you will have help maintaining and improving these parts of the project in the future.
The primary business model for Free Software isn't about selling software (although some of that happens as well), it is about saving money on software purchases.
For consultants Free Software makes a different kind of sense. Free Software allows you the opportunity to compete with much larger organizations by leveraging the Free Software community. There is no chance that you could, on your own, write an operating system that would compete with Windows. However, by taking Linux and modifying for a customer you could deliver a custom product that rivals Microsoft's generic product at a fraction of the cost of Windows.
The fact of the matter is that software is becoming a commodity. As such it is becoming worth less and less as a product in and unto itself. The true value of software lies in the knowledge that the person has that can be used to solve specific problems. Software, in this case, is only a tool, it isn't a product. This trend is good for individual coders, but it is devastating to corporations that rely on the high profit margins that software development has traditionally delivered.
No, I got your point. In fact, my last paragraph even reiterated your point. Here it is again.
I happen to believe that the GPL is an excellent software license, and the fact that the FSF has never had to take the GPL to court testifies to the fact that they are reasonable folks to work with when it comes to clearing up issues. I also am fully in agreement with the fact that the GPL is no worse than any copyright-based license, and is better than most. None of my posts were meant to be an attack on the GPL, GPL advocates, the FSF, or any other group of Free Software hackers.
My point is simply that there is little chance that a successful corporation like Microsoft would try and sneak GPLed code into one of their products (especially a major product). It's just too risky. Heck, Microsoft even has products that they distribute under the GPL (I believe some of the Interix stuff they bought included GNU packages), but they aren't even thinking about combining that GPLed source with their proprietary software. For political reasons it would be better to steal someone else's proprietary source than be caught with their hand in the GPL cookie jar.
Perhaps "forced" is the wrong word, but including GPLed code in your software certainly does limit your options. I don't think this is even a bad thing, just a true one.
The amount of coercion applied is also likely to depend on whose code you have borrowed. For example, I highly doubt that the FSF will let you distribute their GPLed code as part of a proprietary package in exchange for a weekly car wash. They're good guys, but they are going to push for compliance with the terms of the GPL. Other organizations like Trolltech or MySQL AB, on the other hand, actually encourage folks to buy a closed source license of their GPLed works.
My original point, and it is still a good one, is that including GPLed code in your proprietary package is ultimately more trouble than it is worth. Eventually you probably will get caught distributing the software without a license, and at that point you have serious problems. Of course, this also applies to including code from any software that you don't have a license to distribute. There are plenty of software packages that one might want to redistribute with their own code, many don't even come with source code.
Yes, good point. The owner of the misused GPL copyrights would either be due a large monetary fine as compensation for misusing the GPLed copyrights, plus the derivative work would be undistributable until it was cleaned up, or the company would have to release their source code.
Just because up until this point the companies in quesiton have always opted to release source code does not mean that this will always be the case. The fact of the matter is that the GPL is a pretty big hammer. As the folks scooped up by the RIAA are finding out copyright enforcement is an area of the law with ridiculously high penalties. Most companies, when faced with the prospect of paying ridiculously large penalties and being forced to stop distribution of their software until they can remove the GPLed code wisely choose to release source themselves. They don't have to, but they have got much alternative.
Of course, this only applies in those cases where there is a substantial amount of GPLed code that has been borrowed. Otherwise damage control is fairly easy.
Apparently lots of people listen to ESR, including big-wigs at IBM and Sun. Don't worry, he won't lead anyone to believe that he speaks for October 30th.
I highly doubt it. Just like the Business Software Alliance commercials tell us, it would only take one disgruntled employee to wreck your entire day. If Microsoft "borrowed" GPLed code and tried to hide it not only would they open themselves up to a serious lawsuit from the copyright holders (with serious monetary penalties), but they could theoretically end up having to share any source code that came in contact with the GPLed code.
In short, the risks are simply too great.
When it comes to GUI desktop software Sun has already lost control of Java. Oracle has their own JVM that is required to run their Java applications. IBM has SWT that is basically doing precisely the same thing that Microsoft got in trouble over all those years ago. Free Software hackers are working on their own version of Swing that can be compiled with gcj. Not to mention the various and sundry Java-like JVMs that are available (Kaffe, sablevm, etc.).
If Sun released their JVM under the GPL people would still continue to get their JVM from Sun, the only difference is that Sun's JVM would become more acceptable to the Free Software community. In fact, it would probably take a lot of the wind from the sails of these projects that are making divergent versions of Java (SWT is the best example of this).
Yeah, and Sun has never had problems that were specific to one particular version of their JVM.
You say that like there is something wrong with using in house support over outsourcing your support to someone else.
Yes, that's why the ASL2.0 is such a disappointment. It was supposed to be GPL compatible. There are lots of hackers that would like to be able to distribute their software with Apache, but they can't because of stupid licensing issues. If the thing separating the ASL2.0 was a big issue, then perhaps that would be something, but it's not. And so the folks working on Apache software are denied the use of GPL software just for a few niggly words.
No one is forcing anyone to use GPLed software. In fact, the reason that Open Source licenses tend towards GPL compatibility is that there are piles of GPLed software that folks writing software under the other licenses want to use. There is far more useful code licensed under the GPL than all of the variants of the ASL put together. Lots of folks working on Apache projects would probably like to "borrow" bits of GPLed code. However, if they do they can no longer distribute their product. If the difference in the two licenses was large then it might make sense for the ASL hackers to deny themselves access to the GPLed software. However, the differences are so small that many folks are inclined to ignore them completely. Generally speaking, it doesn't make sense to wall yourself off from the largest source of freely available code in the known universe.
Saying that the GPL is "all about gimme" is just ridiculous since the reason that most of the licenses that have changed to become GPL compatible have done so because they want to borrow GPLed software (and not the other way around). Python is perhaps the one exception to this rule. Python's license was changed primarily so that Python hackers could embed the Python VM into GPLed software. Even so, the license change benefitted everyone involved.
As for the FSF being a threat to our "freedom" that's just patently ridiculous. The GPL is definitely a threat to folks that want to take open source software and turn it into proprietary software, but it's not a threat to any of the rest of us.
I definitely agree. However, BSD advocates definitely do care about this sort of thing. That's why they are always talking about how the GPL is viral (so are proprietary licenses, but they never mention that). The real problem is that GPLed derivatives of BSD projects sometimes compete successfully with the original BSD project. When this happens the BSD licensed code generally falls into disuse and suffers from bit rot. After that there is one less project that is available under the less stringent BSD license. Sure, you could ressurect the old BSD code, but that's not nearly as attractive as using the fancy new GPLed code.
BSD projects don't have to compete with commercial derivatives of their project for Open Source hacker time and energy, but they *do* have to compete with GPL project derivatives. That's a big difference to some BSD purists.
It's not about the GPL being holy scripture. It is about being able to take code from GPLed projects and combine then with code from ASL licensed projects. If these two licenses aren't compatible then the resulting derivative work can't be distributed legally.
The reason that this is a problem for Apache is that there is a *lot* of GPLed code out there. In fact, last I checked there are quite a few GPLed Apache modules. Now these modules can't be distributed with Apache.
The problem with licensing issues is that they aren't minutia. In fact, licensing is ridiculously important (ask the KDE folks some time).
The problem is when you want to take some code that is already licensed under the GPL and combine it with ASL2.0 licensed code. All of a sudden you have a tool that compiles and works well, but can't be legally distributed.
The fact of the matter is that the FSF controls the copyrights to a big fat pile of source code, and if they say that derivatives of their GPLed source can't be combined with ASL2.0 source and legally distributed, then folks are going to listen to the FSF.
Since the FSF has a long history of not changind their stance on what is GPL-compatible there is an equally long history of projects changing their licenses to get the FSF blessing. Being cut off from using the millions of lines of FSF GPLed code is simply too big a deal. The Python license is a good example, as is the old QPL license (that QT used to use).
That's true, sort of. However, I can take BSD licensed code, compile it, distribute it, and if someone asks me for the source I can tell them to take a hike. I can also take BSD-licensed code, make some changes and distribute the resulting binaries under any license I wish (including the GPL).
That doesn't change the fact that you can still get the original BSD-licensed code from some other place, but it does mean that my derivative version is only available under the license I choose. The ammended BSD license is GPL compatible in that I can take BSD licensed code, combine it with a GPLed application and still be able to distribute the derivative work (under the GPL).
That's the reason that the BSD folks gets so cranky about the GPL. BSD code that gets combined with GPLed code can only be distributed under the GPL. It's a one-way street. GPL license advocates can poach from BSD licensed codebases, but the BSD folks can't do likewise (without being subject to the GPL). The real problem with this is that the GPL derivative of the BSD work often competes with the original BSD version for developer mindshare. If the GPL derivative becomes substantially more useful than the BSD original version then the GPL derivative sucks the air out of the room for the original version.
Perhaps "Free Software hackers don't support Java" was a little over the top. There are plenty of Free Software Java applications, especially in the web arena. In fact, one could even argue that the Free Software part of Java was the most vibrant part of the whole Java community. Where would Java be without Tomcat, JBoss, Ant, and the rest of the Free Software tools. If Sun's JVM were Free Software Java would almost certainly be even *more* popular.
I can guarantee you that this answer isn't good enough for the Free Software hackers working on Gnome, and it probably wouldn't be good enough for your lawyer if you happened to ask him if it was safe to embed the JVM in your GPLed application. With Python (or guile, or whatever) you are far safer from a legal perspective.
Besides which, who knows what Sun may do tomorrow. They are in a crunch for cash right now, and they might do all sorts of things to make the investors happy.
Life's too short to end up in court over a software licensing issue on a GPLed program, and so Free Software hackers don't support Java. There are plenty of other good Free Software tools. Free Software hackers don't need Sun nearly as much as Sun needs the help of the Free Software hackers.
Sun wouldn't lose control over their JVM simply by GPLing it. They would still be the only folks that could license their JVM under any license but the GPL. It wouldn't really change the situation at all, except that Java would immediately become more popular with Free Software hackers. They might get a bit of free development help I suppose.
If Sun was currently making money with Java I wouldn't propose that they open it, but they aren't, and so what is the harm. Java is already a strategic initiative. And Sun is losing ground. IBM's Eclipse has gained far more support than Netbeans, and right behind it comes the demon of SWT over Swing. Java as a platform is already in jeopardy and .NET is sharpening its knives to have Java for breakfast.
Yes, but what are the licensing issues involved in embedding Sun's JVM into a GPLed application? This isn't a technical issue. This is a licensing issue after all. Not to mention the fact that it is a freedom issue. The Gnome folks wrote an entire desktop from scratch, including a widget set, because QT was the right flavor of free. There is no way that they are going to push to embed Java into Gnome.
Which is all the more reason to release Java under a dual GPL plus some commercial license. The Gnome hackers would love to be able to integrate Java more directly into the Gnome framework, but because of licensing issues this simply cannot be done (or at least it becomes much more difficult). For example, I can embed a Python interpretter in any GPLed application I choose (or any commercial application for that matter). But if I want to write an application that is extensible in Java, well I have to write the whole thing in Java.
Or take the Java-Gnome folks. They are currently primarily working towards being able to compile Java applications to native binaries with gcj and GNU classpath. They are about as excited about Java as a platform as Sun is about .NET as a platform. Sure, they support a few JVMs, but not well.
Like I said, the Free Software community would be happy to help, because Java really is pretty cool, but they can't because of the licensing issues. If Sun had a good reason for their reluctance that would be one thing, but they don't really have a good reason.
For example, one of the reasons that is sometimes forwarded for Sun keeping Java entirely in house is that they are afraid that if they free Java that it will split into divergent paths. However, Python, Perl, PHP, and the rest of the Free Software languages haven't had this problem. Heck, the closest we have come to a split in a development language was the gcc-egcs split. Java, on the other hand, is *currently* being split apart. IBM is making a big deal of SWT, and the GNU folks are making pretty good headway with their gcj compiler. gcj already compiles most software that people actually use (since there are so few GUI Java apps), and the is a GTK-Swing that is also making real headway. Not to mention the crazy Mono folks that are running Eclipse via IKVM.Net. If Sun continues on its current path Java is going to explode in several directions.
And on the other hand Java is facing increased competition from both .NET and the bevvy of competing Free Software tools.
The Free Software community doesn't need Java. They'll get along fine without it. However, Sun needs the Free Software developers to get on the Java train.
Fetchmail is the application that ESR is most well known for, but it's not the one that he has done the most work on. He simply used it as an example in CatB. Pick up any book on programming and you are likely to find examples. These examples are generally trivial, but the book wouldn't be the same without them. CatB was instrumental in explaining how Linux had become such a useful tool in so little time, fetchmail was simply a contrived example to prove the point.
As for the rest of ESR's hacker credentials. Well the initials ESR show up quite a bit in the software that I tend to use. Huge portions of Emacs were done by him (at one point he was the single largest contributor besides RMS, I don't know if that is true today), ESR also has credits in Python, the Linux kernel and piles of other projects that lots of people use everyday (like Nethack or bogofilter).
Here's a more comprehensive list of the ESR's work. Don't forget to click on the "projects" link for work that isn't classified as "software (termcap/terminfo database maintainer, for example, or the fact that he wrote the former Sunsite's Trove software). If you can honestly read that list of software and still come to the conclusion that ESR has done "nothing," then I would love to see your long list of Free Software accomplishments.
Don't get me wrong. I don't always agree with ESR, but I at least know enough about him to know better than to dismiss his credentials as a hacker.
Besides, on this ESR is right. Sun's Java desktop is indicative of the staggering amount of truly good stuff that is coming out of the Free Software community. Free Software hackers want to support Sun in its fight against Microsoft, but they aren't interested in using Sun's non-free Java language to do it. The funny part of Sun's Java Desktop is that there is essentially no Java involved. In fact, some of the same folks that wrote the Gnome desktop that comprises the bulk of Sun's Java desktop are right now working feverishly to finish off the first version of Mono, a .NET-alike for Linux. If Java was Free Software there would be a lot less incentive to do this, but Java isn't Free, and so the Mono hackers are cooking up a set of tools that can take its place for Free Software hackers.
What's worse, it's not like Sun can honestly say that they don't want to Free Java for commercial reasons. Java is currently available as a free download. Sun doesn't really make any money from Java.
The problem, as you say, appears to be personal. The folks at freedesktop.org have basically told the folks at XFree86 that they are tired of trying to work with them, and so now the XFree86 folks (David Dawes) have changed the license to make it more difficult for the freedesktop.org folks to simply use their source code.
The worst bit about this is that the XFree86 core haven't really been active developers for some time. In fact, most of their work predates Linux.
You can't pretend, however, that the licensing issue isn't important. Licensing issues generally turn out to be more important than technical issues. This change might not be *that* problematic, but who is to say that the next change won't be disastrous.
The part that you are missing is that the race is still in its very early stages. Apple has had no problems convincing folks with hundreds of dollars to spend that their iPod is worth the premium price that Apple charges for it, but once digital music players become a commodity Apple isn't likely to be able to hang with the rest of the pack.
As an example, remember when DVD players cost hundreds of dollars. You probably knew someone that had a DVD player back then. Heck, you probably even had one yourself, but the folks with DVD players were rare, and those folks that did have a DVD player probably owned a "premium" brand. Flash forward a couple of years and the $69.99 Apex special available at WalMart has more market share than any other DVD that has ever been made. In a couple of years the average digital music player will cost less than $50, and the best selling device will be the one that WalMart puts near the front of the store. Nothing Apple can do will change that fact.
Apple already knows how hard it is to compete in the cut throat world of hardware sales, and they know that consumer electronics are even worse than the computer industry. They aren't seriously aiming for that ridiculously low margin market.
Instead Apple wants to build up its iTunes.com website to the point where they can introduce their own artists and have Apple-fans purchase music from them directly. Apple's eventual goal is to cut out the music industry middle men and promote their own talent. That's where the money is, and Apple even admits it.
The only reason that the music industry is going along with Apple is that the music industry doesn't really have any choice. They can either sign up with WalMart.com or iTunes.com and sell songs for less than a buck a pop (but they get the lion's share of the profit), or they can let end users and artists set up their own distribution networks where they make nothing. The music industry knows that Apple is gunning to cut them out of the mix, but the alternatives are even worse.
WalMart's service costs $0.88 per song and it allows you to burn copies to CD. I don't know how well WalMart's service works, but I would guess in the long run that they are likely to have the lowest prices and the greatest ties to the least expensive media players.
In short, as long as digital media players is a high-end niche market Apple is likely to do well. However, when it becomes a commodity market WalMart is going to roll over them like they didn't exist.
Exactly. With Microsoft and WalMart both betting on Windows Media Player you can bet that the music distribution deal is going to end up being a price war, and Apple is going to lose.
Don't get me wrong. I agree that the eventual winner is very likely to adopt a policy similar to Apple's iTunes. Heck, WalMart's music downloading service is already pretty darn similar (and songs are $0.88). Apple has a good thing going, but there are simply too many vendors using WMP and too many computers with WMP installed for Apple to win out. Right now Apple is doing well on the strength of their iPod sales, but in the long run digital music players are going to be a commodity product.