A top Red Hat exec has attacked the open-source credentials of its sometime business partner Sun.
Red Hat exec takes Sun to task on open source
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
“Well, I can back this up if you want.”
Yes, please.
“But what I can tell you for, and which you shouldn’t beed me to find a quote for, is that virtually every Windows program in existence needs to link against user32.api as this is where the user interface funtionality comes from. And I’m sure you also don’t need me to find a quote for you that freeware and shareware authors are NOT paying royalties to Microsoft, etc.”
That’s not how copyright law works. It works through author’s grants of rights, not through looking at other people and saying ‘they all are doing it, so it must be ok’.
Let me give you a fine, real world example: A lot of people need to access Java API docs to program in Java. Out of convenience, in order not to have to wait for Sun’s web servers to deliver the HTML docs each time they look up a specific class, they put mirrors of those docs online. If you do a quick search engine search for them, you’ll find a few hundred copies of Sun’s Java documentation online.
Nevertheless, that does not make it legal. So when a web site recently tried to create an annotation service for Sun’s Java documentation, where users could add their comments to Sun’s docuemntation, Sun was quick to shut that part of the website down, citing license violations. See
http://www.theserverside.com/news/thread.tss?thread_id=28232#135200
for a statement from the site’s owner.
I cited that example to show how it is important to understand what one’s rights and obligations are from a license, and not to infer that from observed behaviour.
After all, you would not infer that sharing copyrighted content on p2p networks against the will of the copyright holders is legal, just because you can obersve that many people doing it, would you?
cheers,
dalibor topic
“If you are also staically linking with a commercial library that you do not have permission to redistribute, then you cannot use any LGPL libraries since you cannot meet the requirement that your users be able to relink your code if they wish to do so”
If you have no permission to redistribute the commercial library, then you have no permission to redistribute the combined, derived work either, whether it’s being combined with LGPLd code, or not.
cheers,
dalibor topic
“That’s not how copyright law works. It works through author’s grants of rights, not through looking at other people and saying ‘they all are doing it, so it must be ok’.”
When did I ever claim that this was how copyright law works? What I am saying is that freeware and shareware authors are not paying royalties to Microsoft because Microsoft does not require them to. If they did, we would see a lot of popular shareware authors getting sued big time by Microsoft.
“Nevertheless, that does not make it legal. So when a web site recently tried to create an annotation service for Sun’s Java documentation, where users could add their comments to Sun’s docuemntation, Sun was quick to shut that part of the website down, citing license violations.”
But it IS legal. Sun allows you to mirror the Java API documentation provided that you do not modify it. Allowing users to put comments in the documentation constitutes a modification, and thus a violation of the copyright. So it was not the fact that the Web site was mirroring the documentation that got it shut down. Rather, it was the fact that they were allowing users to modify that documentation by adding comments that got them shut down.
“After all, you would not infer that sharing copyrighted content on p2p networks against the will of the copyright holders is legal, just because you can obersve that many people doing it, would you?”
I never infered anything of the sort. But you seem to be infering that mirroring the Java API documentation is illegal, when in fact, it is not since Sun allows you to do it. You also seem to be infering that most shareware and freeware authors are violating Microsoft license agreements, when in fact they are not, because Microsoft allows you to link against the Windowss API without paying royalties, etc.
Basically, it seems you have not actually read the Java documentation copyright, or the license agreements for the Windows API.
“If you have no permission to redistribute the commercial library, then you have no permission to redistribute the combined, derived work either, whether it’s being combined with LGPLd code, or not.”
Many commercial libraries designed to be statically linked have a license that says you cannot distribute the library itself, but you can only distribute it as part of your exe file (having been statically linked into it). This prevents other users from using the library without a license since once it is combined into your code as an exe, they cannot easily extract the library and link against it themselves.
“I don’t see MS or Sun parasatizing the work of tons of volunteers to stay in business. MS definately is not. Sun is still primarily a hardware vendor, so they are not either. “
Yes, they are. They open sourced their Star Office, which produced OpenOffice – a fine gift to the open source community. But now, there are unpaid, volunteer developers working on OpenOffice code, which can and is being used in Star Office, which they sell for $$$. Also, the whole purpose for Sun to open source Solaris is to get free programming from the open source community, as well as get open source drivers (cross polination), which they can turn around and sell. Finally, the Java Community Process greatly benefits Sun, in that they again get free contributions to Java from individuals and companies, which they can turn around and sell in their own products (J2ee Applications Server).
Mind you, I’m not against Sun doing this. It’s a mutually beneficial arrangement, that companies like Red Hat and Trolltech (producers of the QT cross platform GUI library) use extensively to their own great success, and to the benefit of the open source community and customers.
But this is the type of thing that you’ve been describing as parasitic. If it is, then Sun is as guilty as anyone.
While I understand Sun’s intent, I disagree with the implementation of that intent in the licensing framework. You see, I like free software. And I also like open standards, obviously. Sun does, too, because they do both: they are a good citizen of the free software community, and they are actively working in standard bodies in different area. And that’s cool.
I hope you don’t get me wrong in this discussion, Sun has some very nice technology and people driving that technology. I’m not bashing Sun, I’m arguing solely against the notion that Sun’s license for their Java source code is more liberal than the GPL, by putting my finger on the sections where it is not the case.
Now, the difference between Sun’s Java and other standards, is that standards can usually be implemented by multiple vendors who have different goals, requirements, etc. Everyone can implement their own X server, HTTP client, C compiler, etc. according to their own needs. There is a standard that ensures that everyone gets the syntax and semantics right. There are test suites to verify implementations against. You write your implementation of the standard, according to your needs, and verify it against the test suite. Your customers can verify it against their test suites. The standard and the implmentations prosper in a helthy ecosystem.
With Java, that’s all different. There is one implementation, that you *must* derive from, as soon as you agree to the SCSL. All implementations must be SCSLd, according to the modification clause that I quoted. So there is a significant lock in: once you agree to the SCSL, you’re trapped in the SCSL world. All your code are belong to Sun
For an illustration, please consider that if the GPL vas as ‘viral’ as the SCSL, then Sun would have to open source solaris under the GPL *right now*, or stop shipping it. Solaris 10 includes, afaict from Jonathan’s blog, a Linux kernel ‘personality’, which is an implementation of the interfaces exported by the Linux kernel for Solaris, specifically to make Linux binaries run unchaged on Solaris. If the GPL made the same claims about all implementations of a specification, then Sun would be in a good deal of trouble now. But it doesn’t, because the GPL is not as ‘viral’ as the SCSL.
Sun’s fear of Microsoft forking the language led them to write a license that is very, very restrictive, and very easy to violate. Microsoft seems to have looked at the SCSL, and declined the offer to port Java2 to their platform. I guess that they didn’t want to give Sun another stick to beat them with, given that they were already being hauled to court for violating the license agreement for Java 1.1. The SCSL played a large role in killing Java2 on Windows, in my opinion. Given that Sun & Microsoft are now business partners fighting IBM and Red Hat, the ‘Microsoft might fork’ excuse is moot now, isn’t it?
‘Sun basically says “You can port the JRE to another platform without paying us royalites, etc. provided you do not modify it.”‘
That’s wrong, afaik. As soon as you charge for distribution, like for CD-ROM media, you’re using the code commercially. And then you’re in deep trouble: Commercial use is specifically regulated in the SCSL and mandates the exection of a written contract with Sun, and payment of (undisclosed in the license, yay, there just a blank line!) royalties.
” GLOSSARY, 1:”Commercial Use” means any use (excluding Internal Deployment Use) or distribution, directly or indirectly of Compliant Covered Code by You to any third party, alone or bundled with any other software or hardware, for direct or indirect commercial or strategic gain or advantage, subject to execution of Attachment D by You and Original Contributor.”
I’ll skip most of the attachment D, if you don’t mind. Section 7 contains regulations regarding royaties payments. Among other funny things, Attachment D.7 gives Sun the right to check your company’s accounts to ensure themselves of the royalties being processed:
“e) Audit Rights. Original Contributor shall have the right
to audit such accounts upon reasonable prior notice using an
independent auditor of Original Contributor’s choice (the
“Auditor”).”
And so on, and so on. I fail to see how any of this helps Java. Or compatibility. Or how it is more ‘open’ than the GPL. Please enlighten me.
cheers,
dalibor topic
“But now, there are unpaid, volunteer developers working on OpenOffice code, which can and is being used in Star Office, which they sell for $$$.”
Find me one volunteer who is working on OpenOffice and does not work for Sun. There might be one or two. But the vast majority are Sun employees.
Besides, do you honestly think that StarOffice is making any money for Sun? In fact, I’d be willing to be that is part of the reason they open sourced it. They were losing money on it. It was costing them more to develop it then they were making off of it. Considering the price they were selling it for, and considering its relatively small market share, there is no way they were making money on it.
So once again, Red Hat’s business is based almost entirely on parasitism. Sun, on the other hand, is probably not making any money at all off Star Office. I’d be willing to bet they aren’t even breaking even on it. They are probably losing money.
“Finally, the Java Community Process greatly benefits Sun, in that they again get free contributions to Java from individuals and companies, which they can turn around and sell in their own products (J2ee Applications Server).”
True. But there is still a difference here. And the difference is that with Java, sun is being a fair player. After all, sure they might make a little money off some of my contributions. But that’s hardly unfair considering that they spent millions to develop Java, and are giving it to me for free.
Red Hat is different. In this case, volunteers spent millions of dollars worth in man-hours, and now Red Hat is selling it. In the Sun case, Sun spent millions of dollars ind development, and is now giving their work away for free.
It isn’t as black and white as you want to make it out to be.
Simba, if you consider the GPL viral, why do you like Debian so much? As distros go, Debian is about as GPL’d as you can get.
The GPL is not viral. It’s up to the developer who wants to sell a proprietary product to make sure they don’t have any GPL code, statically linked libraries or otherwise. If they inadvertantly include GPL code that they did not want, it’s their own fault for not thoroughly checking what they used.
Plus, there are, of course, LGPL libraries, which can be included in closed source proprietary software products.
What is viral, potentially or otherwise, is OpenOffice. Sun says, “here open source community, have this nice gift and program it all you want. We’ll use your free labor in our Star Office, and we’ll let our new sugar daddy Microsoft sue you into oblivion for using it or programming it if they feel like it.”
What is also viral is M$ making their .Net Common Language Infrastructure, as well as their C# language, ECMA standards, while still holding patents and not guarunteeing they won’t sue users or charge licensing fees.
Sun and Microsoft are about as viral or parasitic as you can get.
“But it IS legal. Sun allows you to mirror the Java API documentation provided that you do not modify it.”
Sounds good, but I’d rather trust the license agreement. Could you back it up with the respective clause from the API documentation license?
cheers,
dalibor topic
“Basically, it seems you have not actually read the Java documentation copyright, or the license agreements for the Windows API.”
I’m still waiting for that Microsoft user32.dll EULA quote.
cheers,
dalibor topic
“Find me one volunteer who is working on OpenOffice and does not work for Sun”
Sure. http://ooo.ximian.com/ check out the news tab on the left for the new hires from Novell and Red Hat. That’s more than one, btw. Do I win something now?
cheers,
dalibor topic
Well, I think we will have to agree to disagree. But still, I will try to “enlighten you” as you say, on why I think the Sun license is a good one.
“Java source code is more liberal than the GPL, by putting my finger on the sections where it is not the case.”
Sure. But as I pointed out, these clauses only apply to someone who is actually writing a JRE or who wants to modify the Java API itself. They do not apply to me as a Java programmer. And as a Java programmer, I would not want to modify the API anyway since this breaks the portability of my code. Plus, it is far more complex then simply sublcassing something in the API and overriding its methods. So I can think of no reasons why I would ever want to modify the API as a Java programmer. It is bad for portability, and it is more complicated than subclassing. So for me as a Java programmer, the Sun license allows me more freedom then the GPL does, because I can license my Java applications under any license I want. I can’t do that with the GPL.
“With Java, that’s all different. There is one implementation, that you *must* derive from, as soon as you agree to the SCSL. All implementations must be SCSLd, according to the modification clause that I quoted. So there is a significant lock in: once you agree to the SCSL, you’re trapped in the SCSL world. All your code are belong to Sun
”
But once again, this only applies to someone who is writing a JRE. It does not apply to someone who is writing Java programs.
And also, you do not need to derive from that implementation. What you do need to do, is make sure that your implementation is 100% comaptible with the official implementation from Sun. ie, the exposed API that is available to the programmer must be the same API that the official implementation has. The underlying implementation, however, can be different. For example, not all JREs perform threading the same way, sometimes as a result of operating system differences. However, this difference in thread handling must not be apparent in the exposed API, and must not affect the ability of the byte code to run threads. It must be invisible.
And note that it does not say the code must run unchanged. Obviously, that is not possible. The low level drawing functions need to even put a window on the screen are different in X then they are in Windows. So obviously, these low level drawing routines must be rewritten when porting the JRE because they are OS specific.
What the license basically says, is that the JRE you write must be 100% compatible with the Java standard. ie, although the low level code might be different, it must perform the same functions, and to the Java programmer, it must be invoked the same way. You cannot, for example, get rid of JFrame and replace it with MyJFrame, because that breaks code portability, and also constitutes a modifcation to the API. Furthermore, you cannot change the byte code instructions that are required to cause the JRE to draw the frame, since that would break binary compatibility. The low level functions, must, by definition, be different, beause they are OS specific. But to the Java programmer, and to the Java application itself, that change must not be apparent, and must be invisible because it is masked by an API that is 100% compatible with the Java specification.
“Solaris 10 includes, afaict from Jonathan’s blog, a Linux kernel ‘personality’, which is an implementation of the interfaces exported by the Linux kernel for Solaris, specifically to make Linux binaries run unchaged on Solaris.”
FreeBSD does this as well. It’s called an ABI. It basically translates Linux API calls into native calls. But doing this does does not violate the GPL because no code is actually being linked into the Solaris or BSD kernel.
“The SCSL played a large role in killing Java2 on Windows, in my opinion.”
Microsoft wanted to undermine Java to boost the atractivness of their .NET platform. It’s that simple. And this is why they tried to break Java on Windows. When Sun wouldn’t let them break Java, they just stopped shipping Java with Windows because they figured that was the next best way to undermine Java on Windows in favor of .NET. But no, it did not kill Java2 on Windows. You just have download the Sun JRE (which many commercial PC vendors pre-load on their systems anyway, so Microsoft dropping Java2 from Windows was not really that big of a loss.)
“That’s wrong, afaik. As soon as you charge for distribution, like for CD-ROM media, you’re using the code commercially.”
Sure. But why should you able to sell the JRE when even Sun isn’t selling it? They are the ones that invented it and they spent millions of dollars to develop it and then give it away for free. If someone else is going to turn around and sell it, it is only fair that Sun should get a cut of those profits for the millions of dollars of work they put into it.
“And so on, and so on. I fail to see how any of this helps Java. Or compatibility. Or how it is more ‘open’ than the GPL.”
For a Java programmer, it is more open then the GPL because Sun does not specify to me how I have to license the programs I write in Java. The GPL does if I am using a GPL library.
And as far as how it helps compatibility, as I said, above in my elaboration on what the license means to JRE developers, it ensures that JREs remain compatible with the official standard. It ensures that my application will be truly cross platform. Sun does not make a JRE for IBM AIX for example. But IBM makes their own. The Sun license ensures the Java app I compiled on Windows will run on AIX because IBM’s AIX JRE has to be 100% compatible with the standards. It ensures the Java app I compiled on Windows will run on Mac OS X since Apple’s JRE has to be 100% compatible with the standards. It ensures that the Java app I compiled on Windows will run on FreeBSD, since the JRE being developed by FreeBSD volunteers has to be 100% comptible with the standard.
Remember that the JRE is a virtual machine. It is basically a CPU implemented as software. If not for the Sun license which gurantees stricy compliance with the standards, then small incompatibilities would inevitably creep up in different JREs. It would be as if Intel and AMD processors were no longer compatible with each other and software vendors had to start compiling multiple versions of their apps, one for AMD, and one for Intel. But given the shere number of JREs out there, the problem would be much worse for Java developers. I would have to compile one version of my app for the Sun JRE, and a different one for the AIX JRE, and a different one for the Apple JRE. But it gets worse. I might have to compile multiple versions for something like Linux, since there is more than one JRE available for Linux. For example, I might have to compile one for the Linux JRE from Sun, and another for the Linux JRE from IBM, and another for the Linux JRE from Blackdown. You can see how quickly this could become a nightmare if there was nothing in place to ensure that JRE implementations were compatible with the officlal standard.
So this is why I say the Sun licence protects me as Java programmer. It does not restrict my licensing or distribution of Java programs I write in any way. But it does ensure that the Java programs I write truly will be cross platform, even if running on a JRE that was not produced by Sun, because the license stipulates that the JREs written by third party vendors must be 100% compatible with the Sun standard, and must implement the API exactly.
Hope this englightens you on why I think the Sun license is a good licence and why I think it protects the Java programmer rather than harms them.
Also remember something else about Java. Virtually all of Java is written in Java. Even the Java compiler is written in Java. So when someone ports Java to another platform, all they port is the Java Runtime Engine. After that is ported, everything else is alreadly ported as well since it is written in Java. So basically, you would not rewrite the API, or even the compiler if you were porting Java. And if you make changes to the API and then ship it, this is where you run into problems. Sun doesn’t let you do that for good reason. Also, you cannot produce a JRE that has byte code incompatibilities with the official specification. All of this serves to protect Java programmers who want to write cross platform apps that are both source level and binary level portable.
“So I can think of no reasons why I would ever want to modify the API as a Java programmer.”
Fair enough, as one would have to indemnify Sun for legal costs just in case, I wouldn’t want to touch the Java API either
Nevertheless, I’ve met Java programmers who download the source code in order to learn from it, for example why some particular bug in not fixed, or if it is a bug at all. The Java API specifications are in several areas rather misrable. My favourite one is the GregorianCalendar one, large parts of it are simply left undocumented, to encourage compatibilty, I guess. 
So for people using those classes the only way to figure out what the classes are supposed to be doing, is to download the source and look at it. If you spend some time with commercial Java programmers, you’d be surprised how many of them have actually agreed to the SCSL, not becuase they want to modify the APIs, but because they need the inside knowledge to do their work. Sun’s ‘no commercial use without royalties’ puts these commercial software developers in an uncomfortable legal position, as you can understand. As long as Sun is a benevolent dictator in the Java space, their license violations may be tolerated, but if Sun replaced Jonathan with Darl, there would be a lot of tears, I’m sure
You see, GPL secures a long term investment in technology. Even if Sun decides to drop dead and die, or to turn into another SCO, GPL protects OpenOffice users. But there is nothing to protect Java developers, if Sun’s shareholders decide that they’ve lost enough money on it, and they’d rather be doing hardware. Now, check out what Trolltech is doing: they are a vendor of a cross-platform development toolkit, that’s offering a lot of functionality similar to Java’s, under a simple, well-understood license: GPL. If Trolltech goes out of business, their toolkit becomes BSD licensed. Everyone is safe. The same for Red Hat: if Sun suceeds in killing off Red Hat, that won’t hurt GNU/Linux, as Red Hat distributes their code under the GPL.
So if you were a government, building up an IT infrastructure that’s going to last for decades, what would you bet your money on: a proprietary single-vendor technology, or a technology that has a fall-back option if the vendor goes out of business? With Java, there is no fall-back, due to Sun’s licensing choice. I’m quite convinced that the single-vendor nature of it is going to hurt Java in the long run.
“But doing this does does not violate the GPL because no code is actually being linked into the Solaris or BSD kernel.”
Precisely. If, on the other hand, the GPL had an (paraphrased) ‘all implementations must be GPL, and if you re using any part of it, too’ clause, like the SCSL has, Sun would be in trouble. GPL helps Sun provide value for their customers here, without being obliged to pay royalties, or to agree to house visits from Red Hat’s accounting division.
“And also, you do not need to derive from that implementation. What you do need to do, is make sure that your implementation is 100% comaptible with the official implementation from Sun. ie, the exposed API that is available to the programmer must be the same API that the official implementation has.”
You missed that I said “once you agree to the SCSL”. If you don’t agree to Sun’s source code license, you’re free to do what you want anyway, except violating their patents or trademarks.
“Furthermore, you cannot change the byte code instructions that are required to cause the JRE to draw the frame, since that would break binary compatibility.”
That’s wrong. See http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.d…
for a definition of binary compatibility wrt Java ‘from the source’, i.e. the language specification.
Binary compatibility is about identifiers, not semantics. If what you are saying was true, then all releases of Java would be mutually incompatible since all of them fix a bug or two, thereby changing some bytecode instructions.
In particular let me *quote* this part:
“13.4.20 Method and Constructor Body
Changes to the body of a method or constructor do not break compatibility with pre-existing binaries.”
Your notion of binary compatibility is incompatible with Gosling’s
“Microsoft wanted to undermine Java to boost the atractivness of their .NET platform. It’s that simple.”
Interesting, but let’s check the facts first
“6/22/2000 Microsoft unveils the Microsoft® .NET platform, the vision and road map for its next generation of software and services. Microsoft .NET (pronounced “dot-net”) will provide easier, more personalized, and more productive Internet experiences by harnessing constellations of smart devices and Web sites with advanced software through Internet protocols and formats.”
from http://www.microsoft.com/msft/download/keyevents.doc
But on the other hand, Sun hauled Microsoft into court for license violations back in 1997, according to http://www.javaworld.com/javaworld/jw-11-1997/jw-11-infoworld.devs….
I marvel the skill of Microsoft execs boosting the attractiveness of a platform that didn’t apper for another three years.
“Microsoft dropping Java2 from Windows was not really that big of a loss.”
Fascinating, I seem to remember a huge marketing campaing from Sun to please, please someone force Microsoft to ship Java2 on Windows, please. Please. And then going to court to beg for it: http://news.com.com/2100-1001-937053.html?legacy=cnet&tag=pt.rss..f…
But Microsoft again didn’t fall for the SCSL, so they shipped their 1.1.4. And the MS-Sun settlement firmly ensures that MS will only have to ship 1.1.4, and nothing else, as again, MS’ lawyers did not falls for the SCSL trap.
Seriously, now that Sun and MS are friends, what is the trap good for? It’s just a legal minefield waiting to go off.
“But why should you able to sell the JRE when even Sun isn’t selling it?”
Excuse me, but Sun *is* selling it. Or did Sun drop all charges on their operatig systems suddendly without anyone noticing? JDS was 50$ last time I checked.
“They are the ones that invented it and they spent millions of dollars to develop it and then give it away for free.”
“If someone else is going to turn around and sell it, it is only fair that Sun should get a cut of those profits for the millions of dollars of work they put into it. ”
You only get as much profit in a free market, as the market values your product, independently of what your spending is. Clever companies have found ways to offload their developement work on the market, and share the cost by pooling ressources. Others, on the other hand, find themselves searching for a way to cut their losses. Java doesn’t have to be a loss-leader for Sun, it is so by their choice.
“You can see how quickly this could become a nightmare if there was nothing in place to ensure that JRE implementations were compatible with the officlal standard.”
It is a nightmare already, actually, because there are parts of the semantics that have been badly specified in Java. Does ‘Java memory model’ tell you somehthing? Check out the respective JSR. Other parts are simply badly designed, so that they cause interesting problems in practice. Serialization with inner classes is for example one such aspect.
Java is neat, but it’s not a silver bullet. Sun’s refusal to give people access to the testing kits, and the licensing conditions for those kits harm Java developers everywhere, who can not evaluate how compatible their deployment platforms really are. Instead the have to trust marketing efforts, yay.
cheers,
dalibor topic
“Also remember something else about Java. Virtually all of Java is written in Java. Even the Java compiler is written in Java. So when someone ports Java to another platform, all they port is the Java Runtime Engine.”
Doesn’t sound like a great advertisment for the portabiltiy language if I still have to port the JRE, does it?
Why isn’t that one written in Java too, like JikesRVM?
cheers,
dalibor topic
“So for people using those classes the only way to figure out what the classes are supposed to be doing, is to download the source and look at it. If you spend some time with commercial Java programmers, you’d be surprised how many of them have actually agreed to the SCSL, not becuase they want to modify the APIs, but because they need the inside knowledge to do their work.”
There is nothing anywhere that says I cannot read the API source code. The only thing I can’t do is copy source code from the API directly into my application. But why would I want to do that anyway? It just creates more work for me.
“Sun’s ‘no commercial use without royalties’ puts these commercial software developers in an uncomfortable legal position, as you can understand.”
You seem to be suggesting that a commercial developer reading the source code to the API to learn how to use a class constitutes a violation. It doesn’t.
“Even if Sun decides to drop dead and die, or to turn into another SCO, GPL protects OpenOffice users. But there is nothing to protect Java developers,”
Java is not going to go away, even if Sun were to go away. There is too much at stake in Java. Worst case scenario is Sun liquidates and another company (IBM perhaps) purchases the Java assets and it becomes the property of IBM rather than the property of Sun. But there is no way Java is just going to go away even if Sun does.
“If what you are saying was true, then all releases of Java would be mutually incompatible since all of them fix a bug or two, thereby changing some bytecode instructions.”
You don’t understand what I am saying. The JRE is basically a layer of abstraction on top of the OS API. My byte code binary implements threads using Java threads. But it does not hav any knowledge of how the operating system actually implements threads. This is what maintains cross platform portability. The JRE itself might be making calls to the POSIX thread library, or it might be using native Win32 threads. But this is below the abstraction barrier. My byte code program does not need to know how the threads are being implemented. All it needs to know is how to use Java threads. So basically, you can change the underlying threading implementation that the JRE uses, but you cannot change the threading implementation that is exposed to the byte code program. That’s what I mean by binary compatibility. The JRE might choose to implement threads differently at an OS level, or it might fix a bug in thread handling. But the threading implementation that is exposed to my Java binary (byte code) does not change, so therefore, my binary does not break. (Unless Sun specifically changes Java threads, in which case they would also change the java compiler to generate different byte code and I would have to recompile my applications).
“I marvel the skill of Microsoft execs boosting the attractiveness of a platform that didn’t apper for another three years.”
If Microsoft unveiled .NET in 2000, then it means that it had already been being talked about inside Microsoft for several years prior to that. Lets not forget that Microsoft is one of the biggest users of “vaporware marketting”.
“Fascinating, I seem to remember a huge marketing campaing from Sun to please, please someone force Microsoft to ship Java2 on Windows, please. Please.”
This was ultimatlely solved another way. Sun signed pre-load agreements with most major computer manufactuers. Dell, Compaq, HP, etc. all come with the JRE preloaded.
“Excuse me, but Sun *is* selling it. Or did Sun drop all charges on their operatig systems suddendly without anyone noticing? JDS was 50$ last time I checked.”
You are confusing the Java Desktop System with the Java Runtime Environment. Sun does not charge for the Java Runtime Environment. You can goto java.sun.com and download it for free for Solaris, Linux, and Windows. You do not need the Java Desktop System to run Java applications. All you need is a Java Runtime Environment for your oprerating system.
“You see, GPL secures a long term investment in technology.”
But GPL doesn’t work for a technology like Java that depends on compatibility. To use your Qt example, consider this problem. Because Qt is licensed under the GPL, there is nothing to stop me from downloading the Qt source, making some changes to it, and then releasing my own Qt library under the GPL. Of course, now the problem is that my Qt library is not compatible with Trolltech’s Qt library. If my Qt library becomes popular enough, this results in headaches for both users and programmers. Programmers either need to distribute two versions of their application: One for the Trolltech library, and one for my library. Or users need to have two different versions of the Qt library installed.
This problem actually occured with Gtk Win32 for awhile. Several differnt people were producing Win32 ports of Gtk, none of which were fully compatible with each other. So programs that worked fine with one Gtk DLL, would not work with another Gtk DLL. Needless to say, these kind of incompatibilities are rather detrimental to the success of a platform. Neither the programmers or the users want to deal with these kinds of incompatibilies.
Trying to suggest that Qt is a cross platform Java replacement also doesn’t make sense. Java runs on far more platforms than Qt does. Last time I checked, there was no Qt for Palm OS, and no Qt for Windows CE, etc. There is also no Qt for Nokia cell phones. But there is Java for all of these platforms.
Java has also done a very good job of maintaining backward compatibility thanks to their license requirements. A byte code program compiled for JRE 1.1 will still run under Tiger. Qt cannot make that same claim. Neither can Gtk. Hence, users often have to have more than one version of the libraries installed on their systems to support all of the applications they want to run.
“You see, GPL secures a long term investment in technology.”
By the way, I can’t say that I agree with this anyway. You only need to take a quick trek through Sourceforge to see how many GPL projects are dead in the water. Many of the projects there are inactive and have not had any new code checked in for years.
“There is nothing anywhere that says I cannot read the API source code. The only thing I can’t do is copy source code from the API directly into my application.”
“You seem to be suggesting that a commercial developer reading the source code to the API to learn how to use a class constitutes a violation. It doesn’t.”
Please be so kind to post a quote of the section of the license that says that you can read the API source code and use that knowledge commercially without paying royalites. Also, please provide some proof for your claim that copying directly is the only thing that you are not allowed to do. I’m looking forward to see it.
You’re still short of the quotes for your claims regarding the Microsoft EULA and the Java API docs, by the way. The list isn’t getting shorter, apparently.
cheers,
dalibor topic
“Please be so kind to post a quote of the section of the license that says that you can read the API source code and use that knowledge commercially without paying royalites.”
Ok… You are getting REALLY desperate here to save your sinking ship.
So what you are telling me, is that if I read the API, and I see a public method in that API that I can call from my instantiated object that is made from that class, that because I learned of that public method by reading the API source, I cannot legally use it without paying royalties to Sun? That makes absolutely 0 sense. If Sun did not want me to call that method, they would not have made it a public method! It’s a public method specifically because it is intended to be called by my instantiated object!
No offense, but your arguments are really starting to get desperate and rediculous.
Will I find anything like this in the license? No. Because it is so rediculous that Sun would not even bother to write it in there. Because no one would reasonably suggest that learning how to use a class by looking at its implementation would somehow magicacally cause someone to suddenly be violating the license by using that class (which Sun provided because they intend people to use it).
And as far as the Windows API stuff, I am still looking. Google searches aren’t turning up anything relevant yet. I suspect the reason because this is such common knowledge that it’s not real common for people to look it up. I really am still a bit surprised that you want a reference for it in the first place. Haven’t you ever done any Windows programming?
“Google searches aren’t turning up anything relevant yet.”
Well, here is one thing that will hopefully convince you.
The mingw32 compiler (GCC port to Wind32) comes with library files created from the Windows API dlls. Do you actually think that GCC is paying royalties to Microsoft to include these libraries?
“Simba, if you consider the GPL viral, why do you like Debian so much? As distros go, Debian is about as GPL’d as you can get.”
When I say viral, I simply mean it uses a virus like transmission method in the sense that if your code comes in contact with any GPL code, it automatically inherits the GPL. This is not always bad. Obviously, for a commercial application, it is bad, and can’t work. However, for some things it is very good. For Linux, it is very good. For certain applications like web servers, mail servers, etc. The GPL is also a very good license because it ensures that the products will continue to be enhanced.
I like Debian because it is a community project. Because it is entirely made up of volunteers who just want to write code, hack on an operating system, etc. I like Debian because it doesn’t have all the commercialization behind it.
Yes, I have a few gripes about the GPL. But even so, I still use it sometimes, although I am more likely to use the LGPL. The reason is that I rarely write code that does not have to do with some project I am working on that is related to work I do. Because of that, I rarely release GPL code because of the fact that I can’t release the entire project as GPL. (And the project I work on are so specialized, that it wouldn’t do any good anyway.) However, often I will have to write some component or something to do some particular action in my project that I think will be useful to other developers. And often I will release that code under the LGPL.
As I said, I benefit a lot from the open source community because I basically have compilers and libraries worth thousands of dollars that didn’t cost me a dine. So I like to give code back to the community whenever I can. But also as I said, the people I want to benefit the most from that code are the people who wrote the compilers and libraries I use.
“The mingw32 compiler (GCC port to Wind32) comes with library files created from the Windows API dlls. Do you actually think that GCC is paying royalties to Microsoft to include these libraries?”
Nice, but again, inferring your rights from the purported behaviour of others is wrong, and can lead to frustration, as I explained in the JDocs case. If your claims are true, you’ll surely be able to back them up, right?
cheers,
dalibor topic
“Will I find anything like this in the license? No. Because it is so rediculous that Sun would not even bother to write it in there.”
Fascinating, but I’d like to point you to Modifications(iii), which covers all implementations of a specification. An API specification of a method is a specification of semantics of a method call, it’s side effects, it’s parameters and its name. When you extend a class and override the method, you are implementing the contract, i.e. specification of the class you extend from.
“GLOSSARY, 13. “Modification(s)” means [snip] (iii) any new Source Code implementing any portion of the Specifications.”
“GLOSSARY, 21. “Specifications” means the specifications for the Technology and other documentation, as designated on the Technology Download Site, as may be revised by Original Contributor from time to time.”
Nevermind that the ‘Specifications’ clause is a legal backdoor for anyone who owns the site to revise speacs and then sue for failing to comply with the revised specs, and that in its current form, the license doesn’t even tell you which site that is precisely (yay, agreening to licenses where you can’t read parts of the contract sounds great!), it is briad enough to cover extending a class. If you have a problem with that, and think that’s ridiculous, please do not blame me.
If it bothers you, please tell Sun to fix their license, or at least provide a document explaining what precisely is allowed and what is not within the context of commercial use and the SCSL. For a different kind of practice wrt to licensing, I kindly refer you to the FSF’s GPL FAQ, which explains the GPL and its implications in many cases. I am surprised why Sun still hasn’t managed to create such a document to explain the concrete obligations resulting from accepting the SCSL. The document on http://wwws.sun.com/software/communitysource/faq.html is very poor for resolving the kind of debates we have right now.
Okay, I’ve quoted sections of the licenses that support my point, now it’s your turn to back up your claims. You seem to have a lot of trouble doing that, I notice. If a claim is ridiculous, it should be very easy to debunk by quoting from the license text, as I keep doing. Maybe our debate style is simply different, though
cheers,
dalibor topic
“Java is not going to go away, even if Sun were to go away. There is too much at stake in Java. Worst case scenario is Sun liquidates and another company (IBM perhaps) purchases the Java assets and it becomes the property of IBM rather than the property of Sun. But there is no way Java is just going to go away even if Sun does. ”
Nice, but I’d prefer to *know* that will be around, and that I can still use it after a hypothetical demise of Sun, rather than relying on speculation who might end up buying the remains. While you seem to have a ‘it’s too big to fail!’ perspective, let me try to give you another, slightly more pessimistic one:
What happens if Microsoft buys it, and starts charging everyone for use of their patents, the downloades and forces everyone to migrate to .net? It would make business sense for Microsoft, and it’s not like MS is cash-strapped. Poof, and Java would be just gone, like that, and all the nice talk of Java being open, and free, wouldn’t help a single bit in such a situation, that transfers the dictatorship to a non-benevolent dictator.
cheers,
dalibor topic
“If a claim is ridiculous, it should be very easy to debunk by quoting from the license text, as I keep doing. Maybe our debate style is simply different, though
”
I can’t debunk a claim that is so ridiculous that Sun didn’t even bother to address it. And I am not going to continue this debate if you are going to resort to such desperate arguments. All you are doing now is spreading FUD because you have an axe to grind with Sun, and it would also seem that you do not understand the Sun license or have much understanding of programming in general.
The license says that I can not modify the code. I don’t know how many more ways I can say that to you.
Point 2: Creating a subclass in an application and overriding its public methods is NOT modifying the code. I don’t know how many more ways I can say that to you either.
Sure you are quoting license texts. But you are compeltely misinterpreting what they mean. It doesn’t help your argument to do that. You haven’t supported your point at all. All you have done is misinterpret licenses and post FUD because you have an axe to grind with Sun. I’ve pointed out your errors in interpretation numerous times, but you aren’t willing to listen. Instead, you keep pulling bits and pieces out of context and trying to make them say something that they clearly do not say.
“What happens if Microsoft buys it, and starts charging everyone for use of their patents, the downloades and forces everyone to migrate to .net? It would make business sense for Microsoft, and it’s not like MS is cash-strapped. Poof, and Java would be just gone, like that”
And Poof, Microsoft gets hauled into court yet again for anti-competitive business practices. You really think the government would let Microsoft buy Java? This is just more FUD. But like I said, I can play that game too. Did you happen to look at Sourceforge recently and get a sample of the number of dead and unsupported projects there are lying around?
Personally, I have more faith that a product backed by a multi-billion dollar corporation will still be around 5 years from now than I do that a product created by am amatuer hacker on his free time will still be around. After all, how many OSS projects die simply because their author grows bored and moves onto something else? Java’s future is a lot more certain than the future of most of the OSS projects out there.
Humor me though Dalibor… Go post a message on the Java developer forums asking if you have to pay royalties to sun if you subclass and extend JFrame. See what kind of responses you get.
I’m starting to question whether you have ever done any object oriented programming. After all, how do you think you provide funtionality to a basic window frame? In Java, you subclass and extend JFrame. In wxWidgets, you do the same thing with wxFrame. In neither case, have you modified the library or the API.
“Microsoft wanted to undermine Java to boost the atractivness of their .NET platform.”
vs.
“If Microsoft unveiled .NET in 2000, then it means that it had already been being talked about inside Microsoft for several years prior to that. Lets not forget that Microsoft is one of the biggest users of “vaporware marketting”. ”
So you are suggesting that microsoft killed off Java on Windows in order to boost the attractiveness of an unreleased platform that they have been talking about inside Microsoft. For 3 (in words: three) years without the platform actually being released.
Please show me some proof that Microsoft announced .NET to the public in 1997, when they were sued by Sun. I fail to see what the point would have been otherwise in ‘vaporware marketing’ if they don’t announce their vaporware. Please backup your claims with research.
cheers,
dalibor topic
“You are confusing the Java Desktop System with the Java Runtime Environment. Sun does not charge for the Java Runtime Environment.”
JRE is a part of JDS, according to [1]. JDS is sold commercially. They charge for JRE in conjuction with JDS, not for the JRE alone. But in the context of SCSL, that does not matter. SCSL marks any commercial use as dependant upon having a written contract with Sun and payment of royalties, as I have shown.
cheers,
dalibor topic
[1] http://wwws.sun.com/software/javadesktopsystem/features.html#develo…
Dalibor,
Here is a link to an open source application written in Java called Huckster. It is a presentation manager written by James Gosling himself which he has released under the BSD license.
https://huckster.dev.java.net/
Go to the version control system and look at the source code for the file Presentation.java. You will notices that the class Presentation subclasses and extends Frame. Frame is part of the Java API (the AWT window frame class).
Now please explain to me… If what you are claiming about the license is true, then how can James Gosling get away with releasing this code under the BSD license if a subclass constitutes a modification (which is what you are suggesting). And don’t give me this “just cause someone is doing it does not mean it is legal” story. James Gosling is the primary author of the Java language itself. I am sure he would definately know what is legal and what isn’t. So there you have it… The author of Java itself subclassed a class in the Java API, and released the code under the BSD license. So much for your argument about modifications, etc.
“JRE is a part of JDS, according to [1]. JDS is sold commercially. They charge for JRE in conjuction with JDS, not for the JRE alone.”
JDS ships with StarOffice. And StarOffice is mostly what you are paying for with JDS.
But once again, JRE and JDS are not the same thing. And you can download the JRE for free. I already pointed you to the link where you can get it.
Now if you will excuse me, I do not feel like wasting anymore time on this since your arguments have been reduced to the point of ridiculous FUD cause you have an axe to grind with Sun. I don’t have time for this anymore.
“You don’t understand what I am saying”
I understand what you are saying, I’m just proving it wrong. And backing up what I’m saying with quotes from the relevant documents, too
You’ve made claims that modifying a method would break binary compatibility. I have shown you that your idea of binary compatibility is wrong, and proved with an excerpt from the Java Language Specification that modifyng a method body does not violate binary compatibility. Pardon me if I put more trust into Java Language Specification’s definition of binary compatibility, rather than yours.
Your have your definitions mixed up. What you are describing is not binary comaptibility in the context of the Java language as defined by the specification. I have no idea what the proper term for what you are describing is, but ‘saling under a false banner’ might be adequate if you iinsist on calling it ‘binary compatibility’
cheers,
dalibor topic
“Trying to suggest that Qt is a cross platform Java replacement also doesn’t make sense. Java runs on far more platforms than Qt does. Last time I checked, there was no Qt for Palm OS, and no Qt for Windows CE, etc. There is also no Qt for Nokia cell phones. But there is Java for all of these platforms.”
Nice claim. Are you suggesting that I can run JBoss and NetBeans4 on Nokia cell phones or PalmOS? Someone ported the full JRE on them? Got a URL, by chance?
Let’s count the platforms, though, since your ‘far more’ claim sounds wrong to me, but I hope you’ll be able to prove me wrong. I assume that in the context of the discussion we are talking about J2SE, which is the only Java specification that maintains mutual compatibility. J2ME allows vendor specific extensions, and so does J2EE, and as Qt offers neither’s features it would be pointless to compare them, agreed?
When I go to Sun’s site on http://java.sun.com/j2se/1.4.2/system-configurations.html
I can count
* sparc-solaris
* sparc64-solaris
* ix86-solaris
* ix86-win32
* ix86-win32s
* ix86-winnt
* ia64-win32
* ix86-linux
* ia64-linux
* x86_64-linux
for an amazing total of 10 platforms supported by Sun. That’s cool. When I go to http://www.trolltech.com/developer/platforms/index.html?cid=20
otoh, I see that Qt runs on all the same platforms as Sun’s Java, and then some. And it runs on more cpu architectures, afaict, from http://packages.debian.org/stable/devel/libqt-dev
Could you, for example, be so kind and point me to a certified JRE for sparc-linux, sh-linux, arm-linux, alpha-linux, hppa-linux, etc? Same for NeBSD? OpenBSD? ‘Far more’ platforms than Qt? Please back it up.
all I can find beyound the 10 platforms from Sun is http://java.sun.com/j2se/1.4.2/ports.html :
“Stay tuned please: Our Java ports page will be live soon.”
Unmodified since July 16th, according to Sun’s search engine.
cheers,
dalibor topic
“Now if you will excuse me, I do not feel like wasting anymore time on this since your arguments have been reduced to the point of ridiculous FUD cause you have an axe to grind with Sun. I don’t have time for this anymore.”
Well, Ok. I have explained before that I no axe to grind with Sun, they are a cool tech company, I like them, they are a nice member of the free software community, Java is cool, I like open standards, I honestly wish them best of luck in their business endeavours, and so on. I have attacked your assertions about copyright law, GPL, SCSL’s provisions, binary compatibility, interpetation of Sun’s Java API documentation license and so on by quoting relevant documents. Note that these assertions were all yours, afaict, not Sun’s. So accusing me of having an axe to grind with Sun is pointless: your statements are not Sun’s.
You have called me on FUD, spinning, being dishonest instead. I do not remember returning the favour, but if that’s the case I’d like to honestly apologize for hurting your feelings, if that’s the case. Have fun, and thanks for the nice debate.
cheers,
dalibor topic
Simba and Dalibor, I’m actually enjoying your discussion of Java, the JRE, and SCSL. I’m learning from it. It seems that neither one of you is 100% correct, but you are both coming from a well informed perspective.
Anyway, some points for Simba:
“But GPL doesn’t work for a technology like Java that depends on compatibility. To use your Qt example, consider this problem. Because Qt is licensed under the GPL, there is nothing to stop me from downloading the Qt source, making some changes to it, and then releasing my own Qt library under the GPL. Of course, now the problem is that my Qt library is not compatible with Trolltech’s Qt library. If my Qt library becomes popular enough, this results in headaches for both users and programmers. Programmers either need to distribute two versions of their application: One for the Trolltech library, and one for my library. Or users need to have two different versions of the Qt library installed. “
This is a point that Sun likes to make about the potential perils of open sourcing Java – the forking Java and breaking cross platform compatibility. However, real world experience of other open source languages/libraries have proven just the opposite. Perl, Python, PHP, Ruby, Tcl, etc. all have interpreters and/or run in a web server (Apache). Being open source, you would think these languages would have the huge potential to fork. But it hasn’t happed.
Both Perl and Python have been around longer than Java. And both have maintained better cross platform compatibility than Java. Perl and Python have the rep that almost no porting has to be done. The reason for this is that they are open source, which prevents, for the most part, proprietary forking, because there is no financial incentive to do so.
Java, by contrast, faces proprietary extensions – since it is not fully open source, licensers of the Java source, like IBM and BEA, can add their extensions to the J2EE specification, thus causing lock in to their own platforms. If you make a J2EE project on IBM’s WebSphere, you are going to have a major porting headache to port it to BEA’s WebLogic, or JBoss, or Sun’s J2EE app server.
QT is another example. QT has “dual-licensing”, where if you make an open source program with it, you don’t pay a license, and this is under the GPL. If you make a proprietary product with it, you pay a license. And the GPL side of it hasn’t forked.
The GPL has actually prevented forking, rather than encourage it, as Sun has argued, due to the lack of financial incentive, and having to expouse changes to the community.
“What happens if Microsoft buys it, and starts charging everyone for use of their patents, the downloades and forces everyone to migrate to .net? It would make business sense for Microsoft, and it’s not like MS is cash-strapped. Poof, and Java would be just gone, like that, and all the nice talk of Java being open, and free, wouldn’t help a single bit in such a situation, that transfers the dictatorship to a non-benevolent dictator. “
This is a very, very, very realistic scenario. This would make total sense for Microsoft. Java is their cheif competitor for developer mindshare, and they want to control/entice developers to continue market dominance. What better way to do that then killing off the competition? MS has $56 Billion in the bank, and Sun has a market cap of something like 7 or 8 billion. So MS could easily do it.
Also, according to Eric Raymond, who had interviewed a Sun insider, part of the big settlement included MS eventually licensing the Solaris kernel, to put into Windows. Not that I put too much stock in what Eric Raymond says (he can be a crackpot at times, and totally sensible at other times), but I could see the whole settlement as a precursor of what MS has up it’s sleaves.
In short, because this scenario is very realistic and quite possible, the Java license is a much bigger risk to developers than the GPL. MS can’t buy out anything that is GPL’d.
“You have called me on FUD, spinning, being dishonest instead.”
I accuse you of this beause you are trying to suggest implications that simple common sense says are not true (such as the idea that subclassing something in the API constitutes a modification).
Thanks for the applause from the sidelines
I’d also like to point out that I think Sun’s ideals, motivations and intents wrt Java are all fine, in my opinion. For example, I do not object to Sun making money from it, in fact, I think it’s great that Sun can monetize some of their investement into this nice technology. It is up to Sun how they monetize their works. I objected to specific assertions that were brought up, though, for which I felt that these would be hard to verify, or easy to refute. I have to admit that I have intentionally played an advocatus diaboli here, though, and ocassionally strained the debate away from core issues. For that I owe you an apology, too, I guess.
Of course, Sun’s intent is not to screw people over with the SCSL. I’m not saying that. I’m saying that SCSL has some provisions, where the letter of the license goes beyound the benevolent intent of the copyright holder, in my opinion, and the wording can be interpreted in such ridiculous fashion as I did. Allow me a flawed analogy: if the license were source code, I’d say that some functions may contain buffer overflows under some obscure conditions.
My critique of specific points in the SCSL is merely intended to show that the wording of come clauses could be maliciously interpreted. If you allow me to continue with the source code analogy, the buffer overflows could be exploited by an attacker to cause trouble.
I am explicitely not stating that Sun would do that, in no way. Sun has been a good steward of Java, and I have no reason to doubt that they wouldn’t continue to be a good steward, and a champion of compatibility, community-developed standards, and free software in general. Moreover, Sun is actively fighting patent claims on Java in court against Kodak, which is a great thing in my opinion.
But the UNIX court wars between AT&T and BSD, which have found their continuation in the IBM vs. SCO trials, show to me that we have to be very careful in the long run about the implications of software licenses that we use to build software which will serve us for decades. There is a long, long chain from the good, old, benevolent AT&T that gave UNIX away, gave us C and C++, and the new SCO, who are claiming a lot of ridiculous things, too numerous to mention here. Nevertheless, it shows how many problems one can have in the long run with licenses that are apparently ambiguous.
The points I have raised are small nits, rather than big, fundamental issues. They can be fixed very easily, by adding a line or two to the license, to make the intent of the copyright holder clear, or by extending the SCSL FAQ I linked to. It’s nothing earth shattering, it’s small omissions, or ambigous wording that can be easily rectified. For example, adding a simple URL for the ‘Technology Download Site’ would make that part of the license much clearer. It is the combination of the small omissions that can be interpreted in such ridiculous fashion.
As I stated above, I played an advocatus diaboli, in order to show which ‘evil’ interpretations are possible from the text of the license, i.e. in which ways an attacker could use SCSL to challenge the fundamental assumptions of the license’s provisions by a typical Java developer. Those assumptions are, in my opinion, more based on Sun’s benevolence than on the actual license text. Again, I’m all for Java compatibility, and I think Sun has managed to fullfil their ideals for Java quite well, and to prevent Microsoft from ’embrace and extend’, which is no small feat.
I definitely have no axe to grind with Sun, au contraire, I like Sun for all the good things they have done.
cheers,
dalibor topic
“The GPL has actually prevented forking, rather than encourage it, as Sun has argued, due to the lack of financial incentive, and having to expouse changes to the community.”
Actually though, I can think of two good examples of forking off the top of my head that has caused problems.
The first, as I already pointed out, where the multiple ports of Gtk to Win32, none of which were fully compatible with each other.
The second was the FGCC project, which if you recall, was a fork of GCC that was designed to be optimized for Pentium processors. FGCC both introduced subtle incompatibilities with GCC, as well as produced shakey and unstable binaries.
Linux itself, is another example in a more general sense. Every Linux vendor seems to think they have a better way of doing various things. The result is that many commercial application vendors have simply given up on trying to support anything other then Red Hat.
“In short, because this scenario is very realistic and quite possible, the Java license is a much bigger risk to developers than the GPL. MS can’t buy out anything that is GPL’d.”
Once again, I don’t think this is a reasonable scenario since the government would never approve the sale, not in light of the anti-competitive and monopolistic alligations against the company. There are too many other companies that have too big an investment in Java. And they would be filing lawsuits left and right to block Microsoft from being able to purchase Java.
“Java, by contrast, faces proprietary extensions – since it is not fully open source, licensers of the Java source, like IBM and BEA, can add their extensions to the J2EE specification, thus causing lock in to their own platforms.”
But Web application servers are also a more specialized application. I am talking about overall portability. Such as the fact that I can go down a single byte code distribution of jEdit, and it will run on Windows, Mac OS, Linux, Solaris, QNX, FreeBSD, AIX, etc.
“I accuse you of this beause you are trying to suggest implications that simple common sense says are not true (such as the idea that subclassing something in the API constitutes a modification).”
Subclassing in an object oriented language is modification in general, afaict. My argument would be that the new class effectively incorporates verbatim parts of the superclass, thereby forming a derived work. See http://www.gnu.org/licenses/gpl-faq.html#OOPLang for example for FSF’s interpretation of how the GPL applies in the context of OO languages.
Of course it’s ridiculous that Sun would interpret the license in that way, judging by their benevolent intent and behaviour. My point is that the license is ambiguous enough to allows such ridiculous interpretation without really giving you good arguments *from the license text itself* against it. Not that I didn’t say a word about common sense here
That’s why I consider the license to have small flaws in wording of the copyright holder’s intent: it allows interpretations that seemingly contradict the copyright holder’s intent. In particular, a non-benevolent copyright holder would, in my opinion, be able to cause a lot of pain to licensees.
cheers,
dalibor topic
“Once again, I don’t think this is a reasonable scenario since the government would never approve the sale, not in light of the anti-competitive and monopolistic alligations against the company. There are too many other companies that have too big an investment in Java. And they would be filing lawsuits left and right to block Microsoft from being able to purchase Java.”
Fair enough, what if they use a proxy like SCO? SCO has no monopoly on anything, afaict, except frivolous lawsuits
cheers,
dalibor topic
“The first, as I already pointed out, where the multiple ports of Gtk to Win32, none of which were fully compatible with each other. [snip]”
quoting from the Gtk 2.4 announcement message:
http://mail.gnome.org/archives/gtk-app-devel-list/2004-March/msg001…
“GTK+ is free software and part of the GNU Project. However, the
licensing terms for GTK+, the GNU LGPL, allow it to be used by all
developers, including those developing proprietary software, without
any license fees or royalties. GTK+ is the only 100% free-of-cost open
source industrial-strength GUI toolkit available today.”
Sounds like it’s under LGPL to me.:)
cheers,
dalibor topic
“Of course it’s ridiculous that Sun would interpret the license in that way, judging by their benevolent intent and behaviour. My point is that the license is ambiguous enough to allows such ridiculous interpretation without really giving you good arguments *from the license text itself* against it.”
But you seem to forget something, and that is that we have judges and courts to deal with this kind of thing. And Sun has already set a precident of how they interpret the license. Sun cannot suddenly turn around and start interpreting the license to mean that a subclass is a derived work for two reasons: #1: They have already set a precident of not interpreting it this way. #2: It is an extremely unorthodox interpretation, and would likely require clarification in the licence to be interpreted that way.
The implications of this are that even if Sun tried to interpret the license this way, they would not be able to enforce that interpretion in a court of law. So yes, fears such as the one you are trying to promote here are unfounded.
“Fair enough, what if they use a proxy like SCO? SCO has no monopoly on anything, afaict, except frivolous lawsuits
”
This would land some people in jail since it would be highly illegal.
“Sounds like it’s under LGPL to me.:)”
And this is a technicality that no affect on my point whatsoever. Because like the GPL, the LGPL allows modifications, etc. So once again.
“But Web application servers are also a more specialized application. I am talking about overall portability. Such as the fact that I can go down a single byte code distribution of jEdit, and it will run on Windows, Mac OS, Linux, Solaris, QNX, FreeBSD, AIX, etc.”
J2EE is by far the biggest success story for Java. Java has pretty much been a big flop on the desktop (due to problems with Swing/AWT). J2ME has been successful on cell phones as well. But when you talk about the majority of Java development in the real world, you are talking J2EE, using stuff like JSP, Servlets, EJBs, JNDI, JDBC, etc. And the dominant players are IBM’s WebSphere and BEA’s WebLogic, with Oracle’s app server in there, as well as Sun’s, as well as open source JBoss.
And when it comes to cross platform capability, J2EE, in reality (not theory) falls far short of it’s good intentioned goals, due to the aforementioned proprietary extensions. Unless the development team sticks strictly to the standard J2EE specifiaction (avoiding proprietary extensions, and this is rare), porting from one vendor’s J2EE application server to another vendor’s application server is a big mess.
Also, not all Java virtual machines work alike. First, as everyone well knows, MS added their own extensions (which landed them in court with Sun). Then there is IBM’s virtual machine, then there is Sun’s. So even if the developer sticks with standard J2SE (“core” Java), the behavior of his/her application is not gaurunteed across virtual machines, and testing/porting is required.
So for all intents and purposes, Java, in the form of J2EE application servers and different vendor’s virtual machines, has already experienced proprietary forking. This has not happened with Perl, Python, PHP, or any of the other cross platform scripting languages (all of which have lived under the GPL or other similar licenses). And these scripting languges, with their supporting libraries (Perl’s CPAN is a great example) can accomplish most if not all of what Java/J2EE can.
“Once again, I don’t think this is a reasonable scenario since the government would never approve the sale, not in light of the anti-competitive and monopolistic alligations against the company. There are too many other companies that have too big an investment in Java. And they would be filing lawsuits left and right to block Microsoft from being able to purchase Java.”
You make a good point there. MS would be taking a huge legal risk (something they want to avoid nowadays) if they tried to buy out Sun. And I’m thankful for that.
“This would land some people in jail since it would be highly illegal.”
I hope that this would be the case. We’ll see if this is ultimately the case with Darl McBride and his cronies at SCO. I would dearly love to see McBride (a fraudulent extortionist IMHO) spend the rest of his days in San Quentin. But I remain cautiously sceptical at this point.
“Java has pretty much been a big flop on the desktop (due to problems with Swing/AWT).”
Java on the desktop is starting to catch on, particiularly with the introduction of Tiger, which as a greatly improved cross platform LNF, and also many performance improvements.
“the behavior of his/her application is not gaurunteed across virtual machines, and testing/porting is required.”
Testing yes, but porting is very rare, especially if one uses Swing. AWT had problems and often required porting. But Swing almost never does. (Of course, you can break the cross platform portability by using JNI, but I would hope that any developer that used JNI would do so being fully aware of the consequences to portability.) Also, developers who use proprietary extensions, I would hope, are fully aware of the consequences to portability.
“So for all intents and purposes, Java, in the form of J2EE application servers and different vendor’s virtual machines, has already experienced proprietary forking. This has not happened with Perl, Python, PHP, or any of the other cross platform scripting languages (all of which have lived under the GPL or other similar licenses). And these scripting languges, with their supporting libraries (Perl’s CPAN is a great example) can accomplish most if not all of what Java/J2EE can.”
Of the languages you mention, Python is really the only one that has a chance of competing with Java. PHP is unsuited as a general scripting language. And Perl is unsuited for large projects. Python has a chance, but it still needs to undergo some major improvements before it can compete with Java (mostly in the performance department, but also in the GUI toolkit. I still say that Guido should dump Tk in future versions of Python and bunde wxPython instead. The wxWidgets toolkit is vastly supperior to Tk).
But as far as extensions, I would point out that Python has, in fact, forked, and has the same problem with extensions breaking portability that you mention with Java. Specifically, I have in mind ActiveState’s Python for Win32. This version of Python has extensions that allow me to use COM objects, and also allows me to access the Windows API. Of course, if I do this, I completely break the cross platform portability of my application. But in Python, just as in Java, I would hope that any developer would be aware of the consequences of using these extensions when it comes to portability.
“They have already set a precident of not interpreting it this way.”
That does not mean that a future copyright holder can not change that opinion later. See how AT&T vs. BSD came into being. The case was not dismissed on grounds of old AT&T setting a precedent by their inaction, afaik. I believe you’re mixing up trade mark law and copyright.
“It is an extremely unorthodox interpretation, and would likely require clarification in the licence to be interpreted that way.”
Afaik, works that incorporate others are derived works from the works they incorporate. It can be reasonably argued, in my opinion, that in an OO language a class extending another incorporates verbatim parts of the original class, thereby making it a derived work. Copyright law, afaik, defines provisions on how to deal with works incorporating others.
“The implications of this are that even if Sun tried to interpret the license this way, they would not be able to enforce that interpretion in a court of law. So yes, fears such as the one you are trying to promote here are unfounded.”
But I’m explicitely not saying that Sun would or could do such a thing. I’m talking about a future copyright holder.
Please do not misunderstand it as FUD, because I see Java as a great technology for the next decades. And as I stated above, after the legal troubles people had with UNIX, I’d very much like the next foundation to be a safer, better one. Pointing out potential ‘bugs’ in the license is necessary in order to create a strong legal foundation, just like pointing out ‘bugs’ in code is necessary in order to create better code.
cheers,
dalibor topic
The other major problem with Python right now when it comes to competing with Java, is that Python doesn’t have nearly the number of third party libraries available for it that Java does. For example, there are not the embeddable SQL databases, etc., that one can get for Java. (Yes, there is Gadfly, but I’m not sure it is still active. The CVS checkins seem to indicat the Gadfly project is pretty much stalled.)
“See how AT&T vs. BSD came into being.”
AT&T vs. BSD came into being because the UNIX license did not allow Universities and other academic organizations to make the UNIX source code publically available. And BSD and BSDi were doing just that.
This is no different than if some University were to suddenly make the Windows source code publically available. Microsoft does allow Universities access to Windows source code. But they do not have any permission to publically redistribute that source code.
Two more problems with Python.
It doesn’t ship with nearly enough libraries. For example, sure I can get PIL, but I have to download it seperately. This is not a problem for me a developer, but it does create distribution problems.
Java, on the other hand, contains most of the things I would want to do already bundled with the JRE (image handling, etc.) And if there is something I want to do that does not come with Java, I can simply ship the jar file for the third party library with my application, and add it to my jar file’s manifest as part of the classpath. Things are not nearly as simple with Python when it comes to including third party libraries with your application, so end user dependancy problems can bite you hard with Python.
And the final reason that Python cannot compete with Java at this point is that it has no good way of avoiding having to ship source code with your applications. Sure you can freeze your project and such, but this is really kind of a hack, and it is also innefficient since it bundles the Python interpretor with every app. Python need to add the ability to produce a self contained byte code file similar to the ability that Java has.
BTW, I like Python a lot. And I use it a lot for internal projects and for rapid prototyping. If Python makes some of the improvements I mention, I mean even start using instead of Java for applications I distribute. But unfortunately, right now, Python’s limitations really make it kind of unsuitable for development of applications that will be shipped to end users.
“And Perl is unsuited for large projects.”
An erroneous assumption. Here’s proof:
http://perl.oreilly.com/news/success_stories.html
This link features lots of real world examples of Perl being used successfully for very large scale projects.
I will agree with you that Perl and/or Python probably don’t do absolutely everything Java/J2EE does, but they will do most. With Apache and mod_perl (and using CPAN libraries), Perl can do 99.9999% of what J2EE can. And PHP is every bit as good as JSP (or ASP for that matter), for server-side website scripting.
“An erroneous assumption. Here’s proof:”
Oh sure you can use Perl for large projects. But have you ever had to go back and maintain a large project you wrote in Perl 2 years ago? It seems no matter how hard you try to write good code in Perl, when you go back to maintain it, it is difficult to understand. That and Perl’s object oriented addons are a gross hack at best.
I know I am not the only one who feels this way about Perl. This is one of the biggest complaints by developers about Perl is that code is very difficult to maintain, despite your best efforts to write good code.
BTW: I found a solution to my database problem in Python. It seems there is a set of bindings for Python to SQLite, which is being actively developed.
I also think Perl has lost its major advantage over Python in recent times, which is its regex engine. Recent versions of Python have a regex engine that benchmarks very favorably with Perl.
And of course, Python code just works. it really is that simple. One of my first projects in Python was a parser for extracting and reformatting data from a fairly complicated log file. It took me about 25 minutes to write this parser, and it was about 20 lines of code. And I didn’t even know Python at the time. It was really my first experience with the language. I couldn’t believe that after only 25 minutes of working with a languge I had never used before, I was able to write a program that had to open and close files, read each line of an input file, do some regex parsing and some reformatting of strings based on that parsing, and then output to a new file… In only 25 minutes with a language I had never used before!
So yes, I really hope that Python will address some of the problems I mentioned since in most ways, I like Python better than Java. It’s just certain aspects of it right now prevent me from being able to effectively use it in my large projects that need to be distributed off-site.
You mention one of Perl’s (peceived) downfalls: Maintainability/readability. I can’t speak from personal experience (other than playing around with writing small Perl scripts), but I have heard both sides of the coin on this issue. Lots of people have complained about reading/maintaining Perl code, but others have said it isn’t a problem.
The problem lies in the fact that Perl allows the programmer to code it up in any fashion he/she feels like (the Perl philosophy is “There’s more than one way to do it”), which is both a blessing (allows programmer expressivness and creativity) and a curse (can lead to unreadable code). However, it is quite possible to write undreadable, difficult to maintain code in just about any language. Many J2EE projects are known for this, due to a shortage of developers who are savvy with J2EE. Perl is not the only culprit here – it’s mostly up to the programmer.
Python, by contrast, with it’s blank spaces being counted, enforcing stricter formatting, forces the programmer to write readable code. The drawback is that Python limits programmer expressiveness and creativity (compared to Perl).
And with Python, just like Perl, I can’t speak too much from personal experience, other than playing around with small Python scripts.
I have read up quite a bit on both languages (trying to learn them and understand their strengths/weaknesses), and the impression I get from both is that they are both very powerful, easy, useful scripting languages that are good at a wide variety of application domains.
And when I look at real world usage, it seems Perl has the huge advantage. Perl is all over the internet (CGI programming and search engine spiders), as well as being ubiquitous in Unix/Linux administration. Python, while growing in popularity at an amazing rate (sometimes at the expense of Perl), has more limited actual usage in the real world, beyond hobby programming Sure, there are some high profile Python programs, like Red Hat’s Anaconda and heavy usage at Industrial Light and Magic, but professional Python usage is not yet widespread. Furthermore, if you do a search on Perl then on Python at Dice.com, Perl returns hundreds of matches, while Python returns a small fraction of that.
All that being said, Perl and Python both appear to be wonderful languages, and really are attractive alternatives, for the typical application domain, to Java and .Net. This allows the developer to avoid being at the mercy of the mega-corporations that sponsor Java (Sun) and .Net (MS). Infrastructure indepenance, through open standards, is a very desirable goal.
“The problem lies in the fact that Perl allows the programmer to code it up in any fashion he/she feels like (the Perl philosophy is “There’s more than one way to do it”),”
The real problem is that Perl uses all kinds of symbolic idioms to reduce the amount of code that must be written. But these symbolic idioms are often not even remotely human readable. For example, you might see a line of Perl code that looks something like this: $<@* (not sure if this is valid or not. But there really are Perl lines that look similar to this).
Yes, as you say, it Perl is more common right now. But also, as you say, Python is growing rapidly, often at the expense of Perl. And momemtum is often more important then actual user base because it indicates a shifting trend. The trend in this case is that although there is migration of Perl developers to Python, there is virtually no migration in the opposite direction. Also, some very high profile authors (such as ESR and Bruce Eckle) have written about how after they tried Python, Perl suddenly was no longer very attractive except for small scripting projects. So yes, although Perl is still larger then Python, the momemtum definately seems to be in favor of Python.
We’ve gone from Sun / Red Hat blog bickering, to arguing licensing validity, to which Linux distro to use, to the evils of Sun and Microsoft (or Red Hat), to Perl vs Python. Wow! I think we’ve thoroughly exhausted this thread. 😉
Time go stir the pot in other threads … C-ya!
“AT&T vs. BSD came into being because the UNIX license did not allow Universities and other academic organizations to make the UNIX source code publically available. And BSD and BSDi were doing just that.”
I’d kindly suggest reading Groklaw every now and then, since they have covered that old case in sufficient detail to show that your assumption seems wrong to me.
Let me quote from USL’s initial complaint vs. BSDi available at http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/920420.complaint.txt
”
1. This is an action for trademark infringement, false
advertising and unfair competition under the federal Lanham
Trademark Act, 15 U.S.C. Section 1051, et seq., and under the
statutory and common law of New Jersey and of each State in
which BSDI has engaged in the conduct detailed below. USL
seeks injunctive relief and damages to redress BSDI’s ongoing
unauthorized use of the UNIX(R) trademark in BSDI’s toll-free
telephone number, 1-800-ITS UNIX, and its inclusion in its
advertising and promotional materials of materially false and
misleading statements in violation of the rights of USL. ”
As you can see, it was primarily a trade mark infringement case. Faling that, later USL tried to turn it into a copyright infringement case. I guess that’s qute clear from the claims for relief, that do not explicitely mention copyright infringement.
” First Claim for Relief
Federal Trademark Infringement”
” Second Claim for Relief
False Descriptions of Origin,
Source, Sponsorship or Authorization”
” Third Claim for Relief
Dilution”
” Fourth Claim for Relief
Unfair Competition and Deceptive Trade
Practices under State Statutory and Common law”
USL originally started with a trade mark infringement lawsuit in order to keep a potential competitor from entering their market. They also made very broad claims about BSDi’s derivedness from AT&T’s works:
“14. Substantial portions of BSDI’s BSD/386 operating system
are copied from, based upon, or otherwise derived from, USL’s
proprietary software products. Plaintiff reserves the right to seek
an amendment of this Complaint to add claims for relief with respect
to violations by BSDI of USL’s proprietary rights upon the
development of additional facts. ”
USL tried to argue that any of the following activities: copying, basing upon or otherwise deriving from their works constitute a violation of their proprietary rights. Would ‘common sense’ tell you that someone can sue you for having a work ‘otherwise derived’ from someone else’s work? I mean, what does common sense suggest that ‘otherwise derived’ means? Amazing with what sort of things lawyers can come up given ambiguous proprietary licenses, isn’t it?
A nice history of the case can be found in http://www.oreilly.com/catalog/opensources/book/kirkmck.html
A wonderful read is the supportive amicus here : http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/930119.sup-amicus.txt
“In its haste to rush this Court to an erroneous judgment, USL hopes
to cover up a gaping hole in its copyright claim by virtually ignoring
it (apparently hoping the Court will do likewise), i.e., USL has ceded
to the University the copyright in all modifications. improvements
and enhancements to 32V developed by the University.Thus, even if
one assumes that USL holds a valid copyright in 32V, USL cannot
claim that Net2 is an infringing derivative work based upon 32V
because — by agreement with AT&T — the University owns the
copyright in that derivative work.”
” After spending hundreds of hours searching for textual matches,
USL’s paid expert could only find and report on two source files in
Net2 that actually contain 32V code which he considered significant.
The first, Net2’s “ufs_disksubr.c” file contained 14 lines of code (out
of 358 total lines) that also appeared in 32V. Id. at Para. 2.1.1.
The second example belatedly cited by Dr. Carson in his Reply
Affidavit, is the “cpio.c” file: this file was included in Net2 by the
University at the specific request of AT&T. See Second Joint Decl.,
at 1 6.2. But even if it were not estopped to complain about “cpio.c,”
the inclusion of that file and the 14 lines from “ufs_disk.subr.c” —
out of the total 1.5 million lines of source code in Net2 — hardly
amounts to either copyright infringement or a material breach of the
agreement not to distribute the University-owned enhancements
that “contained” 32V code.”
I’d say that University of Berkley used ‘common sense’, when after a search by CSRG they couldn’t find any more AT&T code left over in their system and released it. Despite that AT&T claimed ‘substantial portions’ in the beginning, those claims got down to 14 lines in the end. Their ‘common sense’ and AT&T’s ‘common sense’ led to a two year long legal mudfight that eventually got resolved by Novell buying USL from AT&T and putting an end to all that. Thank you, Novell. And thanks, Regents.
cheers,
dalibor topic
Well, this will be my last post to this thread since this thread has gotten way off topic.
“I’d say that University of Berkley used ‘common sense’, when after a search by CSRG they couldn’t find any more AT&T code left over in their system and released it.”
The Berkeley Net/2 tape was the main subject of this lawsuit. It is the BSD 4.2, which is what the first version of FreeBSD was also based on. This whole issue was settled out of court, and the exact terms of the settlement were never disclosed to the public.
What is known is that substantial portions of code were removed vrom BSD 4.2 and that a major rewrite was required. (BSD Lite). Novell (who had by then inherited UNIX agreed that they would not try to claim any infringing code existed in BSD Lite provided that the Net/2 tape was no longer distributed. The rest of the details were never fully disclosed to the public.
See you next time!
cheers,
dalibor topic