Slashdot Mirror
Upside Editorial Piece on Sun and Open Source
netkatze writes " Upside did a recent article in the op-ed section. " It's an interesting piece, taking on the notion of Sun being a partner with the open source movement, with the conclusion that Sun doesn't "get it." It's been an ongoing debate within the community - is Sun an enemy? Or is the enemy of my enemy my friend?
There are two serious dangers of using "semi-open" source code that are not often discussed here.
... that happened to run much more efficiently then the bloated, "traditionally-designed" MVS/TSO combination.
... which is a shame, because there are lots of things in VM, Rexx and CMS pipelines, for instance, that provide functionality that simply does not exist in the Unix environment.
1) There is the very real possibility that the owner of the source code may yank the source code out from under you. This has happened. Specifically, in the IBM VM community.
VM started back in the mid 1960s as a small internal IBM project, with a few extremely talented programmers, who were trying to scratch an itch. Sound familiar? The specific itch was: "How can we run multiple operating systems on the same computer", so that we can do our testing during the day instead of having to schedule downtime for the entire system to make our tests?"
The result was a program called CP, that runs on IBM 370 iron, where each and every task is a "virtual 370". Just like VMWARE, but for mainframes. You've seen how VMWARE lets you bring up Windows 95 in a Unix window. Well, VM allowed you to bring up MVS, or any other 370 operating system, including VM itself on a terminal. Just for fun, I once set up a second level VM, then went into that second level VM, and built a third and fourth level VM, and it worked.
CP found its sweet spot when it was combined with a different single-user operating system called CMS. VM is really the marriage of CP and CMS. CMS was originally designed as a single-user, high performance operating system to run on bare iron. CMS is single-tasking, and provides the filesystem, compilers, I/O, interrupt structure, etc.
The system provided performance that was simply unheard of on unix systems of similar power. At our peak, we easily ran over a thousand CMS sessions on our 3090 -- each of which was emulating an entire 370 for a single user.
VM was a tight, lean operating system with great performance. Of course, it didn't hurt that the people who wrote it were some of IBM's best hackers, and they had an additional incentive to produce excellent code: all of their work was visible to the customers.
IBM also tried more then once to kill off this "upstart" operating system
Since the first days of the VM mainframe operating system, the entire operating system was distributed with full, buildable source code to the entire operating system. The result was that sites could and did experiment with the CP and CMS kernels, adding functionality, finding bugs, and creating what was, to many, the finest mainframe operating system ever designed.
VM system programmers freely traded their mods around, in source code form, and some of the best of these mods became part of the VM core distribution. In other words, the Open Source process was ALIVE AND WORKING in practice, only it was restricted to paying customers of IBM. The IBM users group is called SHARE, and VM systems programming community had its' share of brilliant programmers who share their work in exactly the same spirit of the current open source community.
Of course, this never harmed IBM, because almost all of this work was being written in IBM 370 assembler language (for maximum efficiency, of course), and with the exception of a few Amdahl sites, must sites were running IBM mainframe hardware anyway.
This was all fine until the mid 80s, when IBM made a management decision to withdraw source code to all of their products. Dispite the outcry from sites around the world, IBM started selectively removing parts of the source code from their distributions, and introducing new functionality without source. Along with the new functionality came huge, bloated object code modules, and conceptually defective interfaces. IBM also threw hundreds of programmers at VM, and the efficiency and elegance of the operating system started to deteriorate.
The result was a disaster that virtually killed the VM community. Whereas in an open source environment, system administrators such as myself could trace crash dumps, find bugs, and report them to IBM, we were all left in the situation where we would crash a crash dump, only to have the trace lead into an "object-code-only" module. This made it much more difficult to maintain a reliable system.
The other disaster was to sites (such as ours) that had made large numbers of local modifications to the IBM-supplied source code. More then once, I had the experience of sitting down to port our local mods to the next release of VM, only to find that one of the modules that I needed to modify had had the source code removed. The result was that people such as myself were forced to disassemble the IBM object decks, work out binary patches, and apply them blindly. I still have a couple of these binary-only patches, based on five year old source code, on our VM system.
We are currently in the process of phasing out our VM systems, and not surprisingly, so are many other VM sites.
So here's the question. Say you are a company that builds a mission-critical system by joining the Sun Community Source License program. You download the source code, and make a large number of changes to the source code to build your mission-critical production server. Now, a year or two down the line, Sun announces the end of the Community Source License program. The next month, Sun releases a new object-code-only version of Solaris that incorporates new features or bug fixes that you need.
Now you are absolutely screwed. Don't think that this couldn't happen. THIS IS EXACTLY WHAT HAPPENED TO IBM'S VM CUSTOMERS.
For the curious, an excellent history of the VM operating system may be found on Melinda Varian's home page:
http://pucc.princeton.edu/~melinda
2) The second danger that is not often discussed here is the danger of accidently incorporating propriatary code, or code that is "close enough to sue", in an open source project.
The WINE project has been able to proceed on safe legal ground, because reverse engineering is a legal activity. Microsoft can hardly claim that parts of Wine were derived illegally from Microsoft propriatary source code, because Microsoft closely guards access to the source code. If Microsoft were to release the windows source code, and someone were to read the windows source code and use that information to fix a bug or add a feature to WINE, or someone just happened to write their own code that happened to resemble part of Windows' source code, Microsoft could file a lawsuit against the WINE developers, and probably obtain a injunction banning distribution of Wine. The fact that Windows is Object Code Only is the ONLY defense against legal harassment, and I predict that this will become a serious problem as more propriatary source code is made available under non-free licensing terms.
Could the same thing happen with Sun and Linux? How farfetched would it be to imagine that sometime down the road, Sun were to file a lawsuit against the major Linux distributors, claiming that some newly-written feature of Linux was so much like a Solaris feature that it must have been illegally copied from Solaris, even if the feature was independantly written, and just happened to look like Sun's solution because both authors solved the problem essentially the same way.
I see Sun's "Community Licensing" as a serious, dangerous threat to the open source community, and I think that we would be much better off if they were to simply not release their source code, rather then release it under their unacceptable terms.
Obviously, free software developers cannot afford to fight lawsuits, and Sun is giving us NOTHING that we can use, while putting themselves in a position to use lawsuits to try and put free software competitors out of business. Whether or not this an "Accidental" feature of their policy, it is still a danger that has not been addressed.
- John Schulien
jms@uic.edu
First of all, I believe that any company that produces only proprietary software is an enemy of Free Software, and freedom in general. I know this sounds Stallman-esqe, but that's because it is. Remember Free Software? It's what we believed in before open source turned us into proponents of a business model instead of an ideal.
But now, Sun has progressed beyond simply producing proprietary software. They have taken the same software and given you the source without giving you the right to use it as you see fit. Fine, that's their disgusting prerogative. Here's the worst part. They're calling it a community license. They can blabber all they want about how they never presented it as "open source." They know exactly what the word "community" implies, and they're spitting in the face of this concept.
This ladies and germs, is what makes them the enemy. I kept hoping that Sun would either rename or redesign the SCSL before they released more software under it, but I have given up hope after the Solaris announcement. As a Free Software proponent, I find Sun's actions disgusting, subversive, misrepresenting and manipulative.
I hope that other Free Software advocates see this as the gross ruse that it is, and spread the word about the SCSL and it's danger to the very community that it claims to represent.
-zack
- is Sun an enemy? Or is the enemy of my enemy my friend?
I'd say that talk of "enemies" is dangerous. Forget "enemies". Forget talk of "Beating Company X".
Remember, the goal isn't for Linux to rule, or for FreeBSD to rule, are whatever. The goal is "Software that doesn't suck". Personally, I don't care who writes it, or what it is. It could be Windows. It could be Solaris. It could be Linux. Who cares? I just want it to work well, without being a hassle. And quite frankly, no OS I've used is there yet. In fifteen years, many of these religious wars will sound as stupid as the "C-64 vs. Apple ][+" debates that raged on the BBSes in 1984.
Hell, if the long term of destiny Linux was nothing more than to force Microsoft to start competing by producing better software instead of using shady business practices, I'd call it a victory for all of us.
If you want good software, well I'd say that the key is to stop worrying about "enemies" and instead:
1) Write good software.
2) Calmly and rationally explain the good points and bad points of any software you encounter.
3) Promote development methods that promote good software.
The only way Sun could be "The enemy", in my mind, is if they break the law. (By, for example, stealing GPL'd software.) Otherwise, they are just a company that may or may not have a product worth having. No need to worry unless you are buying.
These stories remind me a lot of the alarmism about communism a couple decades back. The theory was that the free market was more efficient than communism. If you truly believed that, than there was no need to "fight" communism, as the free market, being more efficient, was bound to emerge victorious. Same goes here. If "Open Source" really does produce better software than the alternatives, then there is no need to fight for it. It will "win" on its own, and the companies that support it will survive. Those that don't, won't. All that is important is that we ensure that everyone fights fair.
The cake is a pie