Slashdot Mirror
Bill Joy, ESR, RMS and more on SCSL vs GPL
Frank Sullivan writes "Upside Today has this
excellent article on the relative value of Sun's "Community Source" license versus the GPL. Richard Brandt, an Upside columnist, wrote recently that Sun "doesn't get" Open Source. Bill Joy responded with an email saying that SCSL is less restrictive than GPL, rather than more restrictive. Brandt forwarded this to ESR and RMS, and a "frank exchange of views" ensued. Many interesting questions were raised, such as is the right to fork a bug or a feature? Well worth reading, if you're interested in the philosophy of source code licensing.
" Wow. Well worth the time of reading.
The GPL would allow you to keep an internal improvement to the Linux core proprietary and closed. You could distribute the binaries throughout the corporation and never have to provide a line of source.
Secondly, he does not make it clear what kind of "improvements" he is referring to. Again, this matters.
Anything that can be compiled and inserted as modules (INCLUDING code which modifies the kernel, as it's running) is NOT covered by the Linux GPL. Thus, such improvements CAN be shipped as closed, proprietary binaries. There's NOTHING to stop you from doing that.
Third, the "normal" method of getting return is to sell your product. The GPL explicitly permits you do do this, just so long as you don't restrict the purchaser's freedom. There's nothing in the GPL that is inherently "anti-sell".
Then, there's the matter of the choice of licence. This guy says he worked on the BSD licence. So why not use that? People are fine with it, you get to keep your binaries as closed as you like, and you don't have the complication of flooding the userspace with different, incompatiable licences.
If there's something I'm seriously missing, please enlighten me! Otherwise, could someone from Sun kindly either fill in the blanks, explain why one of the million other semi-OSS licences (such as BSD) were unused, or rectify the situation by USING one of these other licences! Nobody is pressuring Sun to go GNU!
I happen to like the GPL because it suits my needs. Sun doesn't think it suits theirs, and I respect that. But there's a million alternatives out there. We DON'T need Yet Another Licence, which conflicts with Every Other Licence. Unless there is a VERY good tactical reason for going that route, I would have to say it is mindboggingly STUPID!!!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Eric Raymond: Very different. The SCSL enforces control with the threat of lawsuit and jail. Linus controls the kernel because the community grants him authority in recognition of his authorship.
Richard Gabriel: What if Torvalds were a dictator? Would this be better or worse than Sun exerting some influence or control? Hard to say.
The kind of control Linus has over the kernel (lets just leave out Alan for simplicity) is far better than what Sun does simply because if for example Linus started to think that upcoming kernel releases should only run on "Genuine Intel" processors, everyone would just start using a kernel distribution managed by someone else. Linus just managed to keep the control by the users respect for the quality of what he is doing, not because it says in some license that he is entitled to that control.
Somehow he claims that the right to implement compatible applications (i.e. to reverse engineer an API in the case of Java) is the "right to fork" granted by the SCSL.
I refuse to believe that this seasoned programmer doesn't understand the meaning of a code fork. Rather it seems he is just determined to divert the issue. It seems clear to me that SCSL doesn't allow code forking (i.e. complete, modified versions of the source may not be redistributed under SCSL or any other license).
This is not a Good Thing (TM), from our (Free Software/Open Source community) point of view. Nevertheless we recognize Sun's right to license their code in any way they see fit, as they recognize ours. But I would at least hope they could be honest about it and not claim that their license offers something it doesn't.
In a previous post to /. attached to It's the Developers, Stupid!: The Real NT-Linux Battle I mentioned my belief that the only thing that is really important is the API's and that the most important API's today are those which allow for component based programming.
Clearly Sun and Bill Joy agrees with this statement. Firstly they have made great strides in making Java a modern component based environment through such things as Java Beans, Enterprise Java Beans and JINI. Secondly they have done everything they can to retain control of how those API's are developed in the future. Look at the licensing they employ. Look at the effort they went through to find an open standards organization willing to rubber stamp their requirements for Java itself. Look at this whole issue of code forking.
The problem is that they are in business to make money. I cannot find fault with that. If they feel a need to control the API's for Java, then more power to them. But they should not expect me, or anyone else, to want to play the game by their rules!
Nor should they expect me to believe the propaganda. Sun is trying to portray themselves as brothers with the Open Source community against a common enemy. What they are not saying is that they want to be Microsoft. That little fable about the "Lion's Share" near the end of the article was telling...
In my opinion it boils down to this: We need a fast, simple, powerful and complete Open Source solution for component based development. An API (preferably a cross platform one) that you can write code to in any of the most popular languages. And it must have a reference implementation that is open source with a GPL license. It should be highly Object Oriented and should provide base objects for every major Design Pattern. It should front-end the OS so completely that you can write a new OS which directly provided the relevant API's (making it a kind of Meta-OS). The API itself should be open and there should be a standards committee that isn't loaded with representatives from the big companies. Plus, no-one is penalized for producing a non-compatible version (other than the fact that compatible versions would probably receive a greater market share).
I have been working on my own for some time to develop the beginings of such a standard. A kind of hobby for me. And I know there are plenty of people out there who will claim such a thing already exists in (choose one) PERL, Python, Smalltalk, Gnome or some flavor of the month. I don't think any of those things meet all the criteria of the environment I want to see, but I can state one thing rather confidently...
Until we pull together a produce such a thing the Open Source movement will have a lot of difficulty competing against Sun and Microsoft in the Business Systems space.
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
Ok, since everyone is talking about all the
d e/bugs/4156278.html
things that could happen with the SCSL, I
thought it might be a good time to tell you
all a real problem with the current Java API
and how Sun interacts with developers.
I have been trying to get Sun to fix the
Runtime.exec() API for more than a year.
If you are a Java developer, you probally
already know what I am talking about. The
exec() method does not provide a useful
way to set env vars or to exec() a process
with a current directory other than the one
the JVM was started in.
If you are a JDC member you can read all
about it at this URL. (Sorry, if you
can not view this URL, but Sun will not
let people look at Java bug reports without
joining the JDC and agreeing to a license).
http://developer.java.sun.com/developer/bugPara
I submitted this bug report on July 10, 1998
and it was not "reviewed" until June 28, 1999.
It was then shelved for another 3 months when
they decided to "fix" the problem. Now comes
the tricky part. There is no real information
about how they intend to "fix" this bug, and
the reviewer mentions that they are not even
going to fix "all" of the problems with this
API, just the current directory problem. So
I still have no real feedback and I will have
to wait until the new release of the JDK to
see how they decided to "fix" this bug. There
is something really wrong here. This
kind of crap would never happen on a real
Open Source project.
Mo DeJong