The original poster I'm debating with seems to think somehow that Word has problems doing mail merge, or produces substandard results.
Whatever. I'm responding to what you said, which was: "I don't even want to think about what kind of weird-ass javascipt or other hackery is needed to make web browsers print correctly on envelopes." That is a statement made from ignorance of which you have since been disabused. You have my permission to admit as much without retracting everything else you've said.
Can you point me to a site that does that?
I made no claims about any particular sites doing this. I only said that it would be easy. Do your own googling or read the CSS specification and implement it yourself. I'm not familiar with the Infoprint 1120 but if it's reasonably sane you could probably get a CSS application to print in the correct dimensions without much trouble.
I find that most CSS sites print very goofy, as if the browser was stripping the CSS before sending it to the printer.
That's because the browser is stripping the CSS before sending it to the printer. Style sheets are normally linked with media="screen" and I believe this is the default if no media attribute is specified. Using media="print" will make the rules in the specified style sheet apply only to printers and using media="screen, print" will make the rules apply to both the screen and printers. Try it. It's easy and if you're using a compliant browser it works.
Are you saying that a webapp will somehow print envelopes for USPS mailing? I don't even want to think about what kind of weird-ass javascipt or other hackery is needed to make web browsers print correctly on envelopes.
Dude, I'm not sure how things work on your planet but here on earth most mail merges get printed on sticky labels of the sort they sell in 8.5 x 11 inch sheets at a place like Staples. These are then affixed to envelopes. Printing in the right dimensions from a decent web browser is easy to do using Cascading Style Sheets.
The posts just keep getting longer... and yet, the conversation never seems to progress. I wonder why?
Perhaps because you continue to contradict yourself, refuse to admit obvious mistakes, stray from points in a lame attempt to confuse issues on which you are clearly losing ground, respond with apples to oranges comparisons or simply ramble on about Viagra. When you learn to focus, support your arguments with evidence and respond to the point your opponent has made rather than the one you wish had been made this problem will disappear.
However, the first quote defines an example of differentiating software, and the second proposes a way of dealing more efficiently with differentiating software. When you add the GPL to this equation, his proposed method DOES NOT WORK with his example UNLESS the differentiating software is in a different project.
Instead of supporting your original statement you are changing the subject. This line of argument began when you claimed that "the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects." I asked you to support this and in direct response you furnished those two quotes, which don't relate to the issue at all. Now you pretend that the subject was actually some "method" Mr Perens has proposed without being specific about what you mean. The paper in question is an explanation of the economic mechanism that support open source software in general and only occationally mentions the differences between the GPL and BSD licenses. No particular method is proposed. Clearly you did nothing more than skim the paper looking for quotes to pluck out of context. This is not impressive.
Meanwhile, now that you've changed the subject you're still wrong because you have narrowly defined business as retail proprietary software business. That is a small fraction of the business world -- even the information technology business world. Certainly most retail proprietary software companies cannot link differentiating software with GPL licensed code. Neither I nor Mr Perens has ever disputed that. I challenge you to find an example of either. Of course, companies offering proprietary software can and often do aggregate GPL licensed software. As an example, Sun Microsystems and Microsoft supply GNU tools with some of their products without violating the terms of the GPL or sacrificing their differentiating code. Of course, the overwhelming majority of companies that simply do not sell proprietary software have no practical limitations when it comes to GPL licensed code with any code -- differentiating or otherwise -- for internal use.
GPL software purports to be free-as-in-speech software usable by anyone, and then defines "anyone" as "people like us".
Wrong. GPL licensed software can be used, studied, modified and redistributed by anyone. Anyone includes companies which sell proprietary software such as Microsoft and Sun Microsystems, who in fact do all of these even though they are entirely unlike, say, the Free Software Foundation. Such companies are not free to link GPL licensed software into proprietary applications any more than they are able to ship BSD licensed code without copyright notices. Only in the most crabbed and intellectually dishonest sense could the GPL fail to qualify as free-as-in-speech.
I'm saying it's wrong to call that software "free", because if ANY useful permission is withheld, the software is no longer free.
This is sophistry. Suppose you encountered a company that would find it useful to ship BSD code without copyright notices. Would this move you to abandon support for the BSD license in favor of the public domain? No? Then either you must accept my reasons for finding permission to link with proprietary software less than useful or you must admit that you are a hypocrite.
The meaning of "non-differentiating" is well-known and has been discussed in
The "recommendation" software in question is not a discrete project. It is a feature of a larger project.
I asked you to provide evidence for the following claim: "Incidentally, the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects." What you have quoted is an example intended to illustrate what constitutes differentiating technology. The point Mr Perens is making is that the recommendation feature gives Amazon an advantage over competitors. This does not show that he assumes the recommendation feature is implemented by a discrete project or even a discrete program. Neither does the subsequent quote you provided, which merely emphasizes the importance of differentiating software relateive to the rest.
Apply the GPL to this. You have a differentiating feature for your software. If your software is GPL, your differentiating feature must also be GPL... unless you jump through a number of unnecessary hoops to make it a different product. This inevitably impacts stability, maintainability, and performance.
Boo hoo hoo. Stability, maintainability and performance might also be improved by reusing copyrighted code from a proprietary product sold by some other company, but that isn't an option either. Are you saying it's wrong to withhold permission to link a piece of software with proprietary applications? In that case it must be wrong to release proprietary applications since doing so means linking in other proprietary applications is forbidden. Someone worked hard to design, implement and debug that piece of software that you want to include in your proprietary software product and that author chose not to give you permission to do that unless you share your code too. Why can't you respect that choice, especially since you feel no guilt about denying that permission and then some with regard to your own code?
How about Mr. Perens himself?
You are confused. You claimed, in your own words: "In reality, over 90% of the average project is non-differentiating, while 10% of it *is* differentiating." Mr Perens wrote: "Perhaps 90% of the software in any business is non-differentiating." He is referring to software that a company runs internally which is also available to competitors, not the proportion of code within a proprietary product that differentiates it from its own competitors. You are comparing apples to oranges.
The differentiating software in a business is not localised to purely-differentiating projects; it represents a tiny minority share of projects that are largely non-differentiating.
What you seem to be trying to say is that when a company creates a proprietary software product some portion of the code will implement unique features that set it apart from alternatives while the rest will address generic problems and could be replaced by commodity code. This is true almost by definition. Still unless you have a reputable source you should not claim ninety percent or any other statistic for this proprortion. You simply don't know.
When a proprietary company pays people to modify an open-source codebase, it is also paying them to learn that codebase, which makes them valuable support resources to the community. Furthermore, it encourages the company to expose its developers to the rest of the open source community, where we can demonstrate how great open source development is. This helps give us the advocates and evangelists we need in these proprietary companies, and also arms them with the potent weapon of guilt: "We have taken from this community, and yet we do not contribute - this is a part of our social responsibility."
How very warm and fuzzy. When companies bill shareholders for grandiose executive perks, use courts to suppress details about product security problems and otherwise smash ethical norms they usually don't have much patience for talk of social responsibility. But I'l
Incidentally, the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects.
I find no support for this claim in the paper itself. As far as I can tell Mr Perens makes no assumptions about the relative proportion of differentiating and non-differentiating code in any particular project. Perhaps you would be so kind as to actually quote the relevant text that demonstrates such an error.
In reality, over 90% of the average project is non-differentiating, while 10% of it *is* differentiating.
Again, kindly cite a reputable source. Otherwise I am tempted to suppose you imagined this statistic.
The GPL operates largely under the assumption that given this scenario, the developer would naturally make the Right Decision to contribute the 10% he has to write in return for the 90% he doesn't.
Wrong. The GPL operates on the assumption that providing a free ride to proprietary software companies is not advantageous to the free software movement. There have been cases where companies have contributed code to a free software project because the alternative of releasing an improved proprietary product was not available, but this is just gravy. The real point is to eliminate the need for a project to compete with proprietary alternatives derived from the same codebase. Read the GNU philosophy pages if you don't believe me.
And there is the *specific* economic impact of the GPL, distinct from the economic impact of other licenses: the fact that it has compelled a great many businesses to do business *less* efficiently, and to write code that they would not have to write at all without the license that restrains them.
Exactly why should this be regarded as a problem for the free software community? Only businesses that create proprietary products are affected -- that is to say, the competition. This makes the alternative of choosing a business model compatible with free software that much more attractive.
Yes, I said exactly what you quoted. You have taken it out of context because you don't understand it.
Denying the plain meaning of your words does not help your case. First you claimed what happens when people can't make money from software -- oops, have a harder time making money (even though you say you're not wiggling out of anything you've quietly changed your tune here) -- because they have released their code under the GPL is that people stop writing software so they can do something that makes money. Then when I summarized your position as being that the development teams of GPL licensed projects would dry up you admitted that there is no horrible fate awaiting those projects after all. The second statement is a contradiction of the first, not a clarification or restatement. Exactly which part of this would you like to pretend I don't understand?
Partially, but I think that's really a minor loss, and rather myopic.
Good thing you devoted half of your previous message to this point then. There's no sense dwelling on the important part of your argument, is there?
I think the larger damage is that the developers employed by those organisations are forced to reinvent the wheel over and over again, which wastes our most precious commodity: developer brain-time.
This waste of brain time is exactly what occurs when a developer writes a software component for a proprietary system. He or she might or might not have an easier time getting paid, but the resulting code will be forever unavailable to every programmer outside that organization. While you seem to have no complaint about this you hold that the developer who releases code under the much less restricive GPL is commiting some sort of sin.
When I write software that I release under the GPL everyone is welcome to run it for any purpose, study and learn from it, improve it and share it with others. Is that not enough? Do you want to use it in your proprietary project so that you can advance the state of the art, be happy and get paid? What a coincidence! I'd like all of those things too. You'll have to pay me to grant you a license that permits proprietary use, just as you would if my program were proprietary software. Either releasing proprietary software is wrong, in which case the limitations imposed by the GPL are harmless, or it isn't, in which case the the less severe limitations of the GPL are at least equally reasonable.
I'm *ultimately* interested in people writing and using the code, not people making money off it. The money is just the carrot on a stick that gets people to write code. Code is good. Things that get people to write code are good. So when people are making money from writing code, that's good. And when people *aren't* writing code because they *can't* make money off it, that's bad.
Everyone would like to see the world full of useful and readily available code. Where people differ is on how to get there. Those of us in the free software movement would like to change the industry so that people are routinely paid to write and release free software. This is already underway and making good progress. On the other hand you seem to prefer to cling to the proprietary system while pretending that the large and growing group of people who are being paid to write GPL licensed code are just weird. Maybe that's just because you're not yet one of them.
No, but every GPL project out there says I can't get paid for anything using it through proprietary license revenues. So I'd call those a bunch of specific instances where that particular business model has been ruled out, which is a business decision made for anyone using the code.
Wrong. In each of those cases a group of people have made their work available under certain terms and conditions. Don't like the rules? Don't use the code. No one has interfered with your business decisions. Does your client interfere with the business decisions of people who wou
That [the development teams of GPL licensed projects will dry up and blow away] is not and has never been my position. There is no horrible fate awaiting GPL projects.
Then I guess you never said this: "What actually happens is people stop writing software so they can do something that makes money."
Except that you did.
I look forward with amusement to your next attempt to wiggle out from under your own words. Of course, you could admit that you have learned something and have changed your position. But what fun would that be?
I am simply saying that the GPL is crap and should be killed at our earliest convenience, because it is actively preventing people from contributing to the community.
Nonsense. Only the small minority of companies that want to incorporate free software into proprietary products are prevented from
doing anything at all by the GPL. As you pointed out, in those cases replacing the license with BSD would not result in any contribution to the free
software community. Clearly no one is directly prevented from contributing in either case. Your argument seems to be that the GPL license is indirectly preventing contributions because it cannot be adopted by some organizations that might otherwise have had an incentive to offer improvements to the community.
But that argument is simply wrong. Read The Emerging Economics
of Open Source by Bruce Perens. Companies who contribute to free software projects generally do so because the project represents non-differentiating technology for them. In such cases the disadvantage of allowing competitors to have internally developed improvements is small compared to the benefits of shared maintenence.
This does not usually apply to companies that wish to incorporate free software into proprietary products because in those cases the software
is differentiating technology. Such companies have an incentive to keep improvements to themselves because the advantage of denying them to competitors is worth more than the cost of maintianing an internal fork.
This means the GPL does not foreclose on any signficant source of contributions. One has only to look around to see the evidence. GPL and LGPL licensed projects such as Linux, GCC, GNOME, Samba and others are swimming in corporate cash and have many full time developers employed by a wide variety of companies. BSD licensed projects, while sometimes successful like FreeBSD and PostgreSQL, usually have more meager resources. This would be difficult to explain if the GPL actually discouraged contributions.
This is not about money. It's about code.
Then I guess you never said this: "Code under the BSD license can still be commercially exploited. That means you can still make money off
it." Except that you did.
Proprietary license revenues may not be the best way to get paid, but that's not my decision to make for my clients, and it's not *your* decision to make for them either.
Can you name a specific instance in which I have even attempted to make business decisions on behalf of your clients? Can you name an instance in which I have encouraged you to make business decisions on behalf your clients? No. You can't because there aren't any. In particular, I have never questioned the right of your clients or anyone else to release software for which they own the copyright under any license they choose. Your statement is a clumsy rhetorical trick intended to distract from your inability to articulate a sound argument against the GPL.
The GPL puts us in the business of telling people their business models are wrong. That's a monum
While there are some few thousand programmers who get paid to write GPL code, they are WEIRD, and their employers are WEIRD, and the reasons they are in that position are WEIRD.
No, there's nothing weird about any of this. You simply don't understand the economic forces at work. Still, I notice you have retreated from your original position, which was that the development teams of GPL projects will simply dry up and blow away from a lack of proprietary license fees. That's a good start. No matter how baffled you are by this, smart people can and do make money writing and using GPL software.
The logistics don't scale. You may as well tell your careers advisor that you plan to be a rock star, or join the NBA, or become the President of Burundi: it's simply not a viable plan for your future.
No, sorry, you're wrong. Not everyone can be Linus Torvalds, but not everyone has to be. Around 90% of people employed as programmers are working on in-house project or in other ways not producing software for proprietary sale. Most of those people could, and many demonstrably do, incorporate GPL licensed software into the systems they develop rather than writing things from scratch. They and their employers then have a natural interest in contributing to the project, because doing so is more efficient than rewriting or maintaining an internal fork. These people are not rock stars, but they are being paid to contribute to GPL licensed software. This is one of the reasons there is such a staggering quantity of software available under this license.
Again, proprietary license revenues are neither the only nor the best way to collect money for writing software. Read the Bruce Perens paper linked above if you would like to understand.
That's why I believe in the BSD license. Code under the BSD license can still be commercially exploited. That means you can still make money off it. And that means smart people will continue to write and use it.
So I guess all of these people are fictional. There's no way they could be getting paid to develop the GPL licensed Linux kernel. Except that most of them are. And that's just one project. Proprietary license fees are neither the only nor the best way for poeple to pay for effective software.
Exactly what is wrong with the X Window System that can't be fixed and is worth starting with ZERO debugged drivers for video cards and no working applications? Meanwhile Keith Packard and friends are quietly reworking the guts of the xorg server to use native OpenGL. They report impressive peformance and eye candy possibilities without breaking the interface. The same sound argument you just made against scrapping Linux in favor of some hypothetical successor applies to X.
What rock did you crawl out from under? Public domain has no restrictions whatsoever, while BSD does impose some. That makes BSD less free than public domain by the same logic that makes the GPL less so than BSD. License violations have nothing to do with this.
Exactly. No one would ever play political games over the meaning of terms like "open standard" or "open format" for instance. Nobody would dream of releasing a patent encumbered operating system with a name like "OpenSolaris" or anything like that. And certainly no one has ever been confused enough to think that something like Java is open source just because it comes with source code. No confusion or petty politics here.
Pah. BSD isn't free. You have to retain copyright notices and avoid claiming an endorsement from the author. What a burden! Only software in the public domain offers true freedom.
That is interesting information, thank you. Could you also tell us why ATI will not release a specification that would allow free software developers to create fully functional drivers? Is the issue cost? Fear of patents? Something else?
I appologize if I've got you wrong, but remember you started this by trivializing the concerns of those who won't use Java and went on to claim that platforms other than a handful of your favorites are unimportant. These are bad habits. There are things to like about Sun and Java, but using unsound arguments to defend them from reasonable criticism is not much different from attacking them with the same.
FreeBSD, OpenBSD and NetBSD are not hypothetical or new operating systems. A substantial number of real people are using them to solve real problems today for which many plausibly claim that there is no better technical solution available. For these people Java 5 is not a practical option. C, C++, Python, Perl, Tcl, Ruby, Scheme, Common Lips and many other languages (including the subset of Java implemented by GCJ and GNU Classpath) are. The same can be said of people who use Linux on PPC or other unconventional combinations. Hypothetical operating systems for which hypothetical guardians raise hypothetical religious objections to porting a C compiler are irrelevant.
But since you brought it up, I'll point out why your argument is wrong too. What you're missing -- well, one of the things you're missing -- is that portability is more than a marketing buzzword. Since you like playing hypothetical games, suppose you create a brand new programming language and write a compiler for it on your favorite platform. Can you now claim that programs written in this language are portable because someone could potentially port your compiler to every other platform? Do you take seriously Microsoft's claims that code written to the Win32 API is portable because it can run on Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP and more?
Portability is about working code. Given two applications with similar features, one written in a language completely implemented by free software and the other in Java 5, which can be run on more actual machines today? Clearly the former. Any platform that can run Java 5 can also run any of the free languages. Given a new operating system, will it be easier to port one of the languages completely implemented by free software or Java 5? Clearly the former. Porting a C compiler and a few libraries will provide the rest almost for free (including the subset of Java implemented by GCJ and GNU Classpath). Someday when a free software implementation has caught up with the latest Java specification this distinction will melt away. Until then Java is less portable.
This is not an accident and it has nothing to do with "religion" of any kind. Free software is simply more practial. And here I think we find the true bee in your bonnet. You just don't want to accept that people who point out the importance of software freedom might actually be on to something. Well, go ahead. Ingore the evidence and pretend we're all on some bizarre religious crusade with no connection to problems in the real world. We'll still be right and you'll still be wrong.
"Java specification" was a simple shorthand for the specification of the virtual machine, language and libraries. No doubt the first two are rather adequately implemented by GCJ and other free software Java projects, but the last is a vast sprawling mess so GNU Classpath has not managed to completely implement it yet.
Yes the API is actually specified. Look over here.
I was not trying to make the point that Java programs cannot be run on any particular pair of platforms. I was pointing out that there are interesting platforms that cannot run practical Java programs because the free replacements are not yet complete. (I admit I could have made this more clear in the original post by omitting platforms where Java is well supported.)
I don't think there's anything unfair about this. Sun claims "write once, run anywhere" and the post I replied to implied that Java did solve the problem of running code on any platform. The exercise shows that these claims are untrue.
Wow. Just wow. You have missed the point on an epic scale. And the funny part is you're actually proud enough of your dumb little argument to decorate it with rhetorical immitations of mine. Allow me spell out what should have been obvious to you (in smaller words you'll be more likely to understand): there is no *complete* free software implementation of the current Java specification.
This is why the post I replied to said, "The linux crowd by and large won't use it because it's not quite their flavour of 'free'." This is also why I included Java with the subset of the library supported by GNU Classpath in the second paragraph.
The point is that languages completely implemented by free software can usually be used on any platform without compatibility problems while those that are not are constrained to the platforms the vendor chooses to support. (Unless one sticks to a subset supported by free software which, strictly speaking, makes it a different language.)
Come on now, try a little harder. This is not rocket science.
Amusing. You responded to a post which said in part, "Wasn't Java supposed to solve this problem? I was under the impression that you could run Java apps on any platform" with "Java DOES solve that problem." Now you implicitly admit that Java DOES NOT solve that problem (or at least that you can't comment on whether it does because of your limited experience), but you call *my* post bullshit?
Even if the platforms you've tried are 99% of the computing world I'm still right and you're still wrong. But you're wrong about that too. For example, those platforms might be 99% or more of the desktop computing world, but they are close to 0% of the embedded computing world (counting Linux as x86 or x86-64, which are the only places the Sun JVM runs). While I won't join you in making up bogus statistics, FreeBSD and OpenBSD are each a considerable chunk of the server computing world (clearly more than 1%).
There's more to the world than what you happen to see in front of your nose. So I call your post more uninformed nonsense.
Please try the following exercise. Write a program to solve a practical problem using 100% Pure Java. Now without using GNU Classpath, attempt to run this program on Windows, GNU/Linux, FreeBSD, OpenBSD, NetBSD, AIX and Solaris, each on x86, x86-64, PPC, SPARC and StrongARM hardware if supported by the operating system. Let's see if you still think Java applications will run on any platform when you're finished. (Hint: you won't.)
Extra credit: write the same program using Python, Perl, Tcl, Ruby, Scheme, Common Lisp or any other language completely implemented by free software. (Using Java with the subset of libraries supported by GNU Classpath is permitted.) Try to run the program on the same machines used above. Explain the reason this was so easy. Contrast your experience with Sun's claims that without their iron fist Java would fragment and no longer be portable.
Another solution: Allow the patents, but make it absolutely clear that no patent can be infringed on by writing, publishing, downloading or using software on a normal computer.
I would tweak this: everything novel and nonobvious should be patentable with the sole exception that one cannot infringe on any patent with any software of any kind. Once you have a computer that is not affected by any patent or has been sold to you under proper license for all patents involved you are demonstrably in the clear. This would make things like RSA encryption and one-click shopping unpatentable while permitting patents on automobile brake systems and cutting edge graphics cards.
I believe that solves the problem neatly and reduces the burden on courts. All you need to do is prove that you don't have any fancy hardware to gain summary judgement against infringment claims. That's how it should be, no?
I think you underestimate the importance of having working code in the short run. No one is suggesting that GCJ and Classpath should slow down or stop. While it will be nice to have complete Java 5 support there is simply no way these projects are going to reach perfection in the next six months. This could take a year or more even by conservative reckoning. Meanwhile the impending OpenOffice 2.0 release is not going to wait. What should people who prefer free platforms or who have unusual hardware do in the meantime? Stick with the less efficient and feature rich older releases? Use a piece of software full of features that won't work and won't fail gracefully? Compromise on their principles or shell out money for machines based on an architecture and operating system blessed by Sun?
Why should they do any of these when the community could maintain a fork? What you call impatience others call practical necessity.
Also, a fork would not be nearly as inefficient as you pretend. One or two people who are familiar with the internals of OpenOffice could cleanly slice off features that rely on things Classpath doesn't implement. Such people might not have enough skill or desire to participate in Classpath development directly, but they could submit bug reports which could help to prioritize ongoing work. A better accounting would consider the possibility that experience will make them more productive later, too.
Of course, it looks like even the threat of this was enough to make the OpenOffice developers do the right thing. Should they keep their promises we will have the best outcome possible. This might not have happened had no one declared the intention to fork the project. More than anything else, this convinces me that the initial reactions were perfectly appropriate. I hope the FSF has the good sense to use exactly the same approach if issues like this arise in the future.
First of all, the leaders of the community *are* trying to work together efficiently as the original article clearly demonstrates. Stallman has been in contact with the OpenOffice developers who seem to have listened to his objections and promised to take steps to address them. You are calling the FSF irrational for not doing something they have in fact already done.
Had the OpenOffice developers refused to budge, which they had the right to do, creating a fork would most emphatically *not* be a waste of resources -- at least not from the perspective of the free software community. Doing so would have been necessary and quite important for many users who want a working OpenOffice on a completely free platform (or merely on one that isn't supported by the Sun JRE).
The ability to fork a project in response to important disagreements is a vital check on the power of developers and is at the core of why free software is more efficient in the first place: a lack of central control means the community can more easily vote with its feet. Consider the Xorg fork of XFree86 or the EGCS fork of GCC. Forking a project is not always irrational. Should the OpenOffice developers not make good on their promises this will be yet another example where forking is the right thing to do.
Declaring the FSF irrational is easy to do when you don't consider the facts on the ground. The problem is not programming ethics or bugs in the copyleft Java implementation. The problem is that the copyleft Java implementation is not yet finished. People have been working on completing GCJ for quite some time. While the progress they have made so far is impressive this is not an easy task. Everyone would like to see it done sooner but people are working as quickly as they can.
Limiting OpenOffice to the large set of features GCJ already has available is a practical short term solution and would considerably widen the potential userbase. The OpenOffice developers understand this and have indicated that they are willing to move in this direction, which is not how one would expect them to respond to an irrational complaint.
Slashdot Mirror
Whatever. I'm responding to what you said, which was: "I don't even want to think about what kind of weird-ass javascipt or other hackery is needed to make web browsers print correctly on envelopes." That is a statement made from ignorance of which you have since been disabused. You have my permission to admit as much without retracting everything else you've said.
I made no claims about any particular sites doing this. I only said that it would be easy. Do your own googling or read the CSS specification and implement it yourself. I'm not familiar with the Infoprint 1120 but if it's reasonably sane you could probably get a CSS application to print in the correct dimensions without much trouble.
That's because the browser is stripping the CSS before sending it to the printer. Style sheets are normally linked with media="screen" and I believe this is the default if no media attribute is specified. Using media="print" will make the rules in the specified style sheet apply only to printers and using media="screen, print" will make the rules apply to both the screen and printers. Try it. It's easy and if you're using a compliant browser it works.
Dude, I'm not sure how things work on your planet but here on earth most mail merges get printed on sticky labels of the sort they sell in 8.5 x 11 inch sheets at a place like Staples. These are then affixed to envelopes. Printing in the right dimensions from a decent web browser is easy to do using Cascading Style Sheets.
The posts just keep getting longer... and yet, the conversation never seems to progress. I wonder why?
Perhaps because you continue to contradict yourself, refuse to admit obvious mistakes, stray from points in a lame attempt to confuse issues on which you are clearly losing ground, respond with apples to oranges comparisons or simply ramble on about Viagra. When you learn to focus, support your arguments with evidence and respond to the point your opponent has made rather than the one you wish had been made this problem will disappear.
However, the first quote defines an example of differentiating software, and the second proposes a way of dealing more efficiently with differentiating software. When you add the GPL to this equation, his proposed method DOES NOT WORK with his example UNLESS the differentiating software is in a different project.
Instead of supporting your original statement you are changing the subject. This line of argument began when you claimed that "the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects." I asked you to support this and in direct response you furnished those two quotes, which don't relate to the issue at all. Now you pretend that the subject was actually some "method" Mr Perens has proposed without being specific about what you mean. The paper in question is an explanation of the economic mechanism that support open source software in general and only occationally mentions the differences between the GPL and BSD licenses. No particular method is proposed. Clearly you did nothing more than skim the paper looking for quotes to pluck out of context. This is not impressive.
Meanwhile, now that you've changed the subject you're still wrong because you have narrowly defined business as retail proprietary software business. That is a small fraction of the business world -- even the information technology business world. Certainly most retail proprietary software companies cannot link differentiating software with GPL licensed code. Neither I nor Mr Perens has ever disputed that. I challenge you to find an example of either. Of course, companies offering proprietary software can and often do aggregate GPL licensed software. As an example, Sun Microsystems and Microsoft supply GNU tools with some of their products without violating the terms of the GPL or sacrificing their differentiating code. Of course, the overwhelming majority of companies that simply do not sell proprietary software have no practical limitations when it comes to GPL licensed code with any code -- differentiating or otherwise -- for internal use.
GPL software purports to be free-as-in-speech software usable by anyone, and then defines "anyone" as "people like us".
Wrong. GPL licensed software can be used, studied, modified and redistributed by anyone. Anyone includes companies which sell proprietary software such as Microsoft and Sun Microsystems, who in fact do all of these even though they are entirely unlike, say, the Free Software Foundation. Such companies are not free to link GPL licensed software into proprietary applications any more than they are able to ship BSD licensed code without copyright notices. Only in the most crabbed and intellectually dishonest sense could the GPL fail to qualify as free-as-in-speech.
I'm saying it's wrong to call that software "free", because if ANY useful permission is withheld, the software is no longer free.
This is sophistry. Suppose you encountered a company that would find it useful to ship BSD code without copyright notices. Would this move you to abandon support for the BSD license in favor of the public domain? No? Then either you must accept my reasons for finding permission to link with proprietary software less than useful or you must admit that you are a hypocrite.
The meaning of "non-differentiating" is well-known and has been discussed in
The "recommendation" software in question is not a discrete project. It is a feature of a larger project.
I asked you to provide evidence for the following claim: "Incidentally, the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects." What you have quoted is an example intended to illustrate what constitutes differentiating technology. The point Mr Perens is making is that the recommendation feature gives Amazon an advantage over competitors. This does not show that he assumes the recommendation feature is implemented by a discrete project or even a discrete program. Neither does the subsequent quote you provided, which merely emphasizes the importance of differentiating software relateive to the rest.
Apply the GPL to this. You have a differentiating feature for your software. If your software is GPL, your differentiating feature must also be GPL... unless you jump through a number of unnecessary hoops to make it a different product. This inevitably impacts stability, maintainability, and performance.
Boo hoo hoo. Stability, maintainability and performance might also be improved by reusing copyrighted code from a proprietary product sold by some other company, but that isn't an option either. Are you saying it's wrong to withhold permission to link a piece of software with proprietary applications? In that case it must be wrong to release proprietary applications since doing so means linking in other proprietary applications is forbidden. Someone worked hard to design, implement and debug that piece of software that you want to include in your proprietary software product and that author chose not to give you permission to do that unless you share your code too. Why can't you respect that choice, especially since you feel no guilt about denying that permission and then some with regard to your own code?
How about Mr. Perens himself?
You are confused. You claimed, in your own words: "In reality, over 90% of the average project is non-differentiating, while 10% of it *is* differentiating." Mr Perens wrote: "Perhaps 90% of the software in any business is non-differentiating." He is referring to software that a company runs internally which is also available to competitors, not the proportion of code within a proprietary product that differentiates it from its own competitors. You are comparing apples to oranges.
The differentiating software in a business is not localised to purely-differentiating projects; it represents a tiny minority share of projects that are largely non-differentiating.
What you seem to be trying to say is that when a company creates a proprietary software product some portion of the code will implement unique features that set it apart from alternatives while the rest will address generic problems and could be replaced by commodity code. This is true almost by definition. Still unless you have a reputable source you should not claim ninety percent or any other statistic for this proprortion. You simply don't know.
When a proprietary company pays people to modify an open-source codebase, it is also paying them to learn that codebase, which makes them valuable support resources to the community. Furthermore, it encourages the company to expose its developers to the rest of the open source community, where we can demonstrate how great open source development is. This helps give us the advocates and evangelists we need in these proprietary companies, and also arms them with the potent weapon of guilt: "We have taken from this community, and yet we do not contribute - this is a part of our social responsibility."
How very warm and fuzzy. When companies bill shareholders for grandiose executive perks, use courts to suppress details about product security problems and otherwise smash ethical norms they usually don't have much patience for talk of social responsibility. But I'l
Incidentally, the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects.
I find no support for this claim in the paper itself. As far as I can tell Mr Perens makes no assumptions about the relative proportion of differentiating and non-differentiating code in any particular project. Perhaps you would be so kind as to actually quote the relevant text that demonstrates such an error.
In reality, over 90% of the average project is non-differentiating, while 10% of it *is* differentiating.
Again, kindly cite a reputable source. Otherwise I am tempted to suppose you imagined this statistic.
The GPL operates largely under the assumption that given this scenario, the developer would naturally make the Right Decision to contribute the 10% he has to write in return for the 90% he doesn't.
Wrong. The GPL operates on the assumption that providing a free ride to proprietary software companies is not advantageous to the free software movement. There have been cases where companies have contributed code to a free software project because the alternative of releasing an improved proprietary product was not available, but this is just gravy. The real point is to eliminate the need for a project to compete with proprietary alternatives derived from the same codebase. Read the GNU philosophy pages if you don't believe me.
And there is the *specific* economic impact of the GPL, distinct from the economic impact of other licenses: the fact that it has compelled a great many businesses to do business *less* efficiently, and to write code that they would not have to write at all without the license that restrains them.
Exactly why should this be regarded as a problem for the free software community? Only businesses that create proprietary products are affected -- that is to say, the competition. This makes the alternative of choosing a business model compatible with free software that much more attractive.
Yes, I said exactly what you quoted. You have taken it out of context because you don't understand it.
Denying the plain meaning of your words does not help your case. First you claimed what happens when people can't make money from software -- oops, have a harder time making money (even though you say you're not wiggling out of anything you've quietly changed your tune here) -- because they have released their code under the GPL is that people stop writing software so they can do something that makes money. Then when I summarized your position as being that the development teams of GPL licensed projects would dry up you admitted that there is no horrible fate awaiting those projects after all. The second statement is a contradiction of the first, not a clarification or restatement. Exactly which part of this would you like to pretend I don't understand?
Partially, but I think that's really a minor loss, and rather myopic.
Good thing you devoted half of your previous message to this point then. There's no sense dwelling on the important part of your argument, is there?
I think the larger damage is that the developers employed by those organisations are forced to reinvent the wheel over and over again, which wastes our most precious commodity: developer brain-time.
This waste of brain time is exactly what occurs when a developer writes a software component for a proprietary system. He or she might or might not have an easier time getting paid, but the resulting code will be forever unavailable to every programmer outside that organization. While you seem to have no complaint about this you hold that the developer who releases code under the much less restricive GPL is commiting some sort of sin.
When I write software that I release under the GPL everyone is welcome to run it for any purpose, study and learn from it, improve it and share it with others. Is that not enough? Do you want to use it in your proprietary project so that you can advance the state of the art, be happy and get paid? What a coincidence! I'd like all of those things too. You'll have to pay me to grant you a license that permits proprietary use, just as you would if my program were proprietary software. Either releasing proprietary software is wrong, in which case the limitations imposed by the GPL are harmless, or it isn't, in which case the the less severe limitations of the GPL are at least equally reasonable.
I'm *ultimately* interested in people writing and using the code, not people making money off it. The money is just the carrot on a stick that gets people to write code. Code is good. Things that get people to write code are good. So when people are making money from writing code, that's good. And when people *aren't* writing code because they *can't* make money off it, that's bad.
Everyone would like to see the world full of useful and readily available code. Where people differ is on how to get there. Those of us in the free software movement would like to change the industry so that people are routinely paid to write and release free software. This is already underway and making good progress. On the other hand you seem to prefer to cling to the proprietary system while pretending that the large and growing group of people who are being paid to write GPL licensed code are just weird. Maybe that's just because you're not yet one of them.
No, but every GPL project out there says I can't get paid for anything using it through proprietary license revenues. So I'd call those a bunch of specific instances where that particular business model has been ruled out, which is a business decision made for anyone using the code.
Wrong. In each of those cases a group of people have made their work available under certain terms and conditions. Don't like the rules? Don't use the code. No one has interfered with your business decisions. Does your client interfere with the business decisions of people who wou
That [the development teams of GPL licensed projects will dry up and blow away] is not and has never been my position. There is no horrible fate awaiting GPL projects.
Then I guess you never said this: "What actually happens is people stop writing software so they can do something that makes money." Except that you did.
I look forward with amusement to your next attempt to wiggle out from under your own words. Of course, you could admit that you have learned something and have changed your position. But what fun would that be?
I am simply saying that the GPL is crap and should be killed at our earliest convenience, because it is actively preventing people from contributing to the community.
Nonsense. Only the small minority of companies that want to incorporate free software into proprietary products are prevented from doing anything at all by the GPL. As you pointed out, in those cases replacing the license with BSD would not result in any contribution to the free software community. Clearly no one is directly prevented from contributing in either case. Your argument seems to be that the GPL license is indirectly preventing contributions because it cannot be adopted by some organizations that might otherwise have had an incentive to offer improvements to the community.
But that argument is simply wrong. Read The Emerging Economics of Open Source by Bruce Perens. Companies who contribute to free software projects generally do so because the project represents non-differentiating technology for them. In such cases the disadvantage of allowing competitors to have internally developed improvements is small compared to the benefits of shared maintenence. This does not usually apply to companies that wish to incorporate free software into proprietary products because in those cases the software is differentiating technology. Such companies have an incentive to keep improvements to themselves because the advantage of denying them to competitors is worth more than the cost of maintianing an internal fork.
This means the GPL does not foreclose on any signficant source of contributions. One has only to look around to see the evidence. GPL and LGPL licensed projects such as Linux, GCC, GNOME, Samba and others are swimming in corporate cash and have many full time developers employed by a wide variety of companies. BSD licensed projects, while sometimes successful like FreeBSD and PostgreSQL, usually have more meager resources. This would be difficult to explain if the GPL actually discouraged contributions.
This is not about money. It's about code.
Then I guess you never said this: "Code under the BSD license can still be commercially exploited. That means you can still make money off it." Except that you did.
Proprietary license revenues may not be the best way to get paid, but that's not my decision to make for my clients, and it's not *your* decision to make for them either.
Can you name a specific instance in which I have even attempted to make business decisions on behalf of your clients? Can you name an instance in which I have encouraged you to make business decisions on behalf your clients? No. You can't because there aren't any. In particular, I have never questioned the right of your clients or anyone else to release software for which they own the copyright under any license they choose. Your statement is a clumsy rhetorical trick intended to distract from your inability to articulate a sound argument against the GPL.
The GPL puts us in the business of telling people their business models are wrong. That's a monum
While there are some few thousand programmers who get paid to write GPL code, they are WEIRD, and their employers are WEIRD, and the reasons they are in that position are WEIRD.
No, there's nothing weird about any of this. You simply don't understand the economic forces at work. Still, I notice you have retreated from your original position, which was that the development teams of GPL projects will simply dry up and blow away from a lack of proprietary license fees. That's a good start. No matter how baffled you are by this, smart people can and do make money writing and using GPL software.
The logistics don't scale. You may as well tell your careers advisor that you plan to be a rock star, or join the NBA, or become the President of Burundi: it's simply not a viable plan for your future.
No, sorry, you're wrong. Not everyone can be Linus Torvalds, but not everyone has to be. Around 90% of people employed as programmers are working on in-house project or in other ways not producing software for proprietary sale. Most of those people could, and many demonstrably do, incorporate GPL licensed software into the systems they develop rather than writing things from scratch. They and their employers then have a natural interest in contributing to the project, because doing so is more efficient than rewriting or maintaining an internal fork. These people are not rock stars, but they are being paid to contribute to GPL licensed software. This is one of the reasons there is such a staggering quantity of software available under this license.
Again, proprietary license revenues are neither the only nor the best way to collect money for writing software. Read the Bruce Perens paper linked above if you would like to understand.
That's why I believe in the BSD license. Code under the BSD license can still be commercially exploited. That means you can still make money off it. And that means smart people will continue to write and use it.
So I guess all of these people are fictional. There's no way they could be getting paid to develop the GPL licensed Linux kernel. Except that most of them are. And that's just one project. Proprietary license fees are neither the only nor the best way for poeple to pay for effective software.
I reject your reality, and substitute my own.
Apparently so.
Exactly what is wrong with the X Window System that can't be fixed and is worth starting with ZERO debugged drivers for video cards and no working applications? Meanwhile Keith Packard and friends are quietly reworking the guts of the xorg server to use native OpenGL. They report impressive peformance and eye candy possibilities without breaking the interface. The same sound argument you just made against scrapping Linux in favor of some hypothetical successor applies to X.
What rock did you crawl out from under? Public domain has no restrictions whatsoever, while BSD does impose some. That makes BSD less free than public domain by the same logic that makes the GPL less so than BSD. License violations have nothing to do with this.
Exactly. No one would ever play political games over the meaning of terms like "open standard" or "open format" for instance. Nobody would dream of releasing a patent encumbered operating system with a name like "OpenSolaris" or anything like that. And certainly no one has ever been confused enough to think that something like Java is open source just because it comes with source code. No confusion or petty politics here.
Oh, wait...
Pah. BSD isn't free. You have to retain copyright notices and avoid claiming an endorsement from the author. What a burden! Only software in the public domain offers true freedom.
That is interesting information, thank you. Could you also tell us why ATI will not release a specification that would allow free software developers to create fully functional drivers? Is the issue cost? Fear of patents? Something else?
I appologize if I've got you wrong, but remember you started this by trivializing the concerns of those who won't use Java and went on to claim that platforms other than a handful of your favorites are unimportant. These are bad habits. There are things to like about Sun and Java, but using unsound arguments to defend them from reasonable criticism is not much different from attacking them with the same.
FreeBSD, OpenBSD and NetBSD are not hypothetical or new operating systems. A substantial number of real people are using them to solve real problems today for which many plausibly claim that there is no better technical solution available. For these people Java 5 is not a practical option. C, C++, Python, Perl, Tcl, Ruby, Scheme, Common Lips and many other languages (including the subset of Java implemented by GCJ and GNU Classpath) are. The same can be said of people who use Linux on PPC or other unconventional combinations. Hypothetical operating systems for which hypothetical guardians raise hypothetical religious objections to porting a C compiler are irrelevant.
But since you brought it up, I'll point out why your argument is wrong too. What you're missing -- well, one of the things you're missing -- is that portability is more than a marketing buzzword. Since you like playing hypothetical games, suppose you create a brand new programming language and write a compiler for it on your favorite platform. Can you now claim that programs written in this language are portable because someone could potentially port your compiler to every other platform? Do you take seriously Microsoft's claims that code written to the Win32 API is portable because it can run on Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP and more?
Portability is about working code. Given two applications with similar features, one written in a language completely implemented by free software and the other in Java 5, which can be run on more actual machines today? Clearly the former. Any platform that can run Java 5 can also run any of the free languages. Given a new operating system, will it be easier to port one of the languages completely implemented by free software or Java 5? Clearly the former. Porting a C compiler and a few libraries will provide the rest almost for free (including the subset of Java implemented by GCJ and GNU Classpath). Someday when a free software implementation has caught up with the latest Java specification this distinction will melt away. Until then Java is less portable.
This is not an accident and it has nothing to do with "religion" of any kind. Free software is simply more practial. And here I think we find the true bee in your bonnet. You just don't want to accept that people who point out the importance of software freedom might actually be on to something. Well, go ahead. Ingore the evidence and pretend we're all on some bizarre religious crusade with no connection to problems in the real world. We'll still be right and you'll still be wrong.
"Java specification" was a simple shorthand for the specification of the virtual machine, language and libraries. No doubt the first two are rather adequately implemented by GCJ and other free software Java projects, but the last is a vast sprawling mess so GNU Classpath has not managed to completely implement it yet.
Yes the API is actually specified. Look over here.
I was not trying to make the point that Java programs cannot be run on any particular pair of platforms. I was pointing out that there are interesting platforms that cannot run practical Java programs because the free replacements are not yet complete. (I admit I could have made this more clear in the original post by omitting platforms where Java is well supported.)
I don't think there's anything unfair about this. Sun claims "write once, run anywhere" and the post I replied to implied that Java did solve the problem of running code on any platform. The exercise shows that these claims are untrue.
Wow. Just wow. You have missed the point on an epic scale. And the funny part is you're actually proud enough of your dumb little argument to decorate it with rhetorical immitations of mine. Allow me spell out what should have been obvious to you (in smaller words you'll be more likely to understand): there is no *complete* free software implementation of the current Java specification.
This is why the post I replied to said, "The linux crowd by and large won't use it because it's not quite their flavour of 'free'." This is also why I included Java with the subset of the library supported by GNU Classpath in the second paragraph.
The point is that languages completely implemented by free software can usually be used on any platform without compatibility problems while those that are not are constrained to the platforms the vendor chooses to support. (Unless one sticks to a subset supported by free software which, strictly speaking, makes it a different language.)
Come on now, try a little harder. This is not rocket science.
Amusing. You responded to a post which said in part, "Wasn't Java supposed to solve this problem? I was under the impression that you could run Java apps on any platform" with "Java DOES solve that problem." Now you implicitly admit that Java DOES NOT solve that problem (or at least that you can't comment on whether it does because of your limited experience), but you call *my* post bullshit?
Even if the platforms you've tried are 99% of the computing world I'm still right and you're still wrong. But you're wrong about that too. For example, those platforms might be 99% or more of the desktop computing world, but they are close to 0% of the embedded computing world (counting Linux as x86 or x86-64, which are the only places the Sun JVM runs). While I won't join you in making up bogus statistics, FreeBSD and OpenBSD are each a considerable chunk of the server computing world (clearly more than 1%).
There's more to the world than what you happen to see in front of your nose. So I call your post more uninformed nonsense.
Please try the following exercise. Write a program to solve a practical problem using 100% Pure Java. Now without using GNU Classpath, attempt to run this program on Windows, GNU/Linux, FreeBSD, OpenBSD, NetBSD, AIX and Solaris, each on x86, x86-64, PPC, SPARC and StrongARM hardware if supported by the operating system. Let's see if you still think Java applications will run on any platform when you're finished. (Hint: you won't.)
Extra credit: write the same program using Python, Perl, Tcl, Ruby, Scheme, Common Lisp or any other language completely implemented by free software. (Using Java with the subset of libraries supported by GNU Classpath is permitted.) Try to run the program on the same machines used above. Explain the reason this was so easy. Contrast your experience with Sun's claims that without their iron fist Java would fragment and no longer be portable.
Another solution: Allow the patents, but make it absolutely clear that no patent can be infringed on by writing, publishing, downloading or using software on a normal computer.
I would tweak this: everything novel and nonobvious should be patentable with the sole exception that one cannot infringe on any patent with any software of any kind. Once you have a computer that is not affected by any patent or has been sold to you under proper license for all patents involved you are demonstrably in the clear. This would make things like RSA encryption and one-click shopping unpatentable while permitting patents on automobile brake systems and cutting edge graphics cards.
I believe that solves the problem neatly and reduces the burden on courts. All you need to do is prove that you don't have any fancy hardware to gain summary judgement against infringment claims. That's how it should be, no?
I think you underestimate the importance of having working code in the short run. No one is suggesting that GCJ and Classpath should slow down or stop. While it will be nice to have complete Java 5 support there is simply no way these projects are going to reach perfection in the next six months. This could take a year or more even by conservative reckoning. Meanwhile the impending OpenOffice 2.0 release is not going to wait. What should people who prefer free platforms or who have unusual hardware do in the meantime? Stick with the less efficient and feature rich older releases? Use a piece of software full of features that won't work and won't fail gracefully? Compromise on their principles or shell out money for machines based on an architecture and operating system blessed by Sun?
Why should they do any of these when the community could maintain a fork? What you call impatience others call practical necessity.
Also, a fork would not be nearly as inefficient as you pretend. One or two people who are familiar with the internals of OpenOffice could cleanly slice off features that rely on things Classpath doesn't implement. Such people might not have enough skill or desire to participate in Classpath development directly, but they could submit bug reports which could help to prioritize ongoing work. A better accounting would consider the possibility that experience will make them more productive later, too.
Of course, it looks like even the threat of this was enough to make the OpenOffice developers do the right thing. Should they keep their promises we will have the best outcome possible. This might not have happened had no one declared the intention to fork the project. More than anything else, this convinces me that the initial reactions were perfectly appropriate. I hope the FSF has the good sense to use exactly the same approach if issues like this arise in the future.
First of all, the leaders of the community *are* trying to work together efficiently as the original article clearly demonstrates. Stallman has been in contact with the OpenOffice developers who seem to have listened to his objections and promised to take steps to address them. You are calling the FSF irrational for not doing something they have in fact already done.
Had the OpenOffice developers refused to budge, which they had the right to do, creating a fork would most emphatically *not* be a waste of resources -- at least not from the perspective of the free software community. Doing so would have been necessary and quite important for many users who want a working OpenOffice on a completely free platform (or merely on one that isn't supported by the Sun JRE).
The ability to fork a project in response to important disagreements is a vital check on the power of developers and is at the core of why free software is more efficient in the first place: a lack of central control means the community can more easily vote with its feet. Consider the Xorg fork of XFree86 or the EGCS fork of GCC. Forking a project is not always irrational. Should the OpenOffice developers not make good on their promises this will be yet another example where forking is the right thing to do.
Declaring the FSF irrational is easy to do when you don't consider the facts on the ground. The problem is not programming ethics or bugs in the copyleft Java implementation. The problem is that the copyleft Java implementation is not yet finished. People have been working on completing GCJ for quite some time. While the progress they have made so far is impressive this is not an easy task. Everyone would like to see it done sooner but people are working as quickly as they can.
Limiting OpenOffice to the large set of features GCJ already has available is a practical short term solution and would considerably widen the potential userbase. The OpenOffice developers understand this and have indicated that they are willing to move in this direction, which is not how one would expect them to respond to an irrational complaint.