June 24, 2004

Sun seeks redemption in software licensing

Author: Jem Matzan

In my review of Sun Java Desktop System release 2, I criticized Sun Microsystems for imposing such restrictive licensing terms on its customers. A discussion on Groklaw followed, and Sun contacted me to discuss the license and how it might modify it in the future. I had several suggestions, and overall they were happy to have the feedback and eager to make their future license agreements more user friendly. But proprietary thinking dies hard. Will Sun really reduce the restrictions in its licenses?

A few days ago I spoke with a Sun Microsystems representative who wished to remain anonymous. We talked for a little more than half an hour about licensing issues. Basically, I wanted to communicate the issues I felt were negative about the Java Desktop System license and relay some of the feedback I'd received through email and in forum and blog comments on the matter, and Sun wanted to know how to improve its products to make them more customer-friendly.

Too long, too complex

The first matter I raised was the length of the license -- in all, seven pages. Even among proprietary licenses, this is a long and unusually complex document. The language of the document is convoluted and difficult to interpret, even for someone like me, who is accustomed to reading software licenses. The main problem is the inclusion of numerous special-case provisions and details that are found in few licenses for other products. My advice was to make the license easier to read and understand; only when you know what you're agreeing to can you be empowered to accept or reject it.

GPL problems

I specifically asked why the Sun license ignored the GNU General Public License (GPL) in its paper licensing materials, especially since the GPL governs the staggering majority of the software in Java Desktop System. The Linux kernel, the GNU userland and utilities, the GNOME desktop environment, the Evolution PIM and other programs essential to the functionality of the operating environment are all governed by the GPL. Other software on the system -- the Java 2 Standard Environment and StarOffice 7 -- are only held to their own licenses, not the JDS license. So that means only the handful of proprietary management tools that Sun included are truly governed by the JDS license.

"Contract law is not well-meshed with Open Source licensing practices," said the anonymous representative with whom I spoke. "Judicial and statutory law requires an act of acceptance." The spokesperson further explained that since the GNU General Public License does not require the user to perform a traditionally recognized act of acceptance -- such as clicking an "I Accept" button in a popup screen before installing the software -- that "intellectual property" companies prefer the reliability of a "click-wrap" agreement when licensing commercial code for inclusion in Sun's software. The Java Desktop System license, however, does employ such an act of acceptance on the part of the customer. The JDS license also says that the user needs to comply with the Open Source licenses that are included, including the GPL. So the enforceability of the JDS license is designed to support the enforceability of licenses covering the open source licenses in case that aspect of those open source licenses is challenged and defeated in court someday.

I pointed out that most commercial GNU/Linux distributions like Red Hat and Mandrake require an act of acceptance -- not for the GPL specifically, but for terms that guarantee the same basic freedoms as the GPL. In other words, they're restating the GNU General Public License, adding the standard warranty/remedy/liability clauses, and then requiring the user to click on "I Agree" to complete the legal agreement.

Professor Eben Moglen of Columbia University, counsel for the Free Software Foundation and defender of the GNU GPL, says that Sun's comments on the GPL's enforceability are based on a misunderstanding. When I told him via email of Sun's statements about the act of agreement and the question of future enforceability of the GPL, he replied, "That objection is unconvincing. Sun has not discussed that position with the Free Software Foundation, or with me. A brief essay on this subject, now three years old and as accurate as when first published, can be found at http://moglen.law.columbia.edu/publications/lu-12.html." It's a short essay explaining why the GPL is, has been and ever shall be enforceable, and why it doesn't need a so-called act of acceptance to achieve legal validity. Basically, Professor Moglen states that the General Public License does not require an act of acceptance to grant rights to people who acquire, use, or modify software that is licensed under the GPL. But since GPL'd software cannot be redistributed without a license, the act of redistribution requires acceptance of the GPL on the part of the distributor. So, in essence, the only restriction or requirement of the license is to continue to license the software under the GPL if you distribute it. The main difference here is that Professor Moglen does not equate software licenses with contracts, and Sun does.

Certainly there is some misunderstanding here with regard to the terms and scope of the GPL. Sun does see the advantage in using JDS's Free Software base when marketing the product. Sun says that customers want an operating environment based on GNU/Linux but views the GPL as a problem from a contractual standpoint because of agreements with code licensed from third parties.

The risk factor

When a company is evaluating or considering software in a tight, competitive market, one of the deciding factors can be the risk factor involved in buying and using the software. In other words, how can you as the customer possibly lose on the deal, and what is the likelihood that it will happen? With a Free Software GNU/Linux distribution, no one can take away the rights that the GPL guarantees, but with Java Desktop System you have several things to consider in the license.

A license should never threaten its customers, or, if that is not the intention, it should at least appear to be non-threatening. I'm specifically talking about software audits, for which the license provides. We've all heard of Microsoft's BSA software raids, where huge fines are imposed on their customers for using unlicensed copies of proprietary software. The Sun reps with whom I spoke said that they ask their JDS customers how many deployments they have on a yearly basis, and charge them a subscription fee accordingly -- no in-house audits are planned, intended, or executed. Still, the threat exists, and it increases the level of risk for the customer; the way the license is worded it looks like Microsoft-style raids are possible.

Allow noncommercial redistribution

With many programs, there is no harm in allowing noncommercial redistribution of the software. Face it: No home user is going to pay $400 for an office suite or $1,000 for a graphics package. Letting them use the software on a home system hurts no one because they're using software they never would have purchased. This is a kind of free advertising as well, because people who use a piece of software at home are likely to recommend that software to others, including their bosses. Sun could easily make Java Desktop System available for noncommercial use or take out some of their proprietary tools so that the rest of the operating environment could be redistributed.

About two weeks ago I was talking to a friend of mine who works as a sysadmin for a major university. He was telling me of his experiences setting up a GNU/Linux demonstration for his boss in order to show how easy it was to run applications over a network. He was trying to find a good method of remote administration and said that he was looking into both Free and proprietary products. I suggested that Java Desktop System 2 might be a good product to try. He asked if I had a copy he could use for testing, and I replied that I did, but the license agreement prohibited me from giving it to him because I still had it partially installed on one of my computers and needed to test it further before removing it. He replied that if the license was that bad, he didn't want to bother with it anyway. So Sun may have lost a large contract there because I couldn't give out a copy of their software to someone to evaluate. Granted, my friend could have called up Sun's sales people and they might have sent him his own evaluation copy, but that's not the point. It was easier just to recommend Fedora Core plus some of the Ximian tools instead.

The Sun people had specific questions for me on this matter, and it seemed to me at the time that they may be considering a version of JDS that is freely downloadable for noncommercial use. After all, Solaris x86 is already available under those conditions, so it wouldn't be a stretch to put up JDS2 for download as well.

Future licenses from Sun

Overall, the discussion I had with Sun was quite productive. Certainly I hope my suggestions go beyond conversation and into the next round of software licenses for their products. Licensing is something to which more and more people are paying close attention in the wake of the RIAA and SCO lawsuits. We have to be more careful to what we agree when we use nontangible goods, and we need to assess the risks as real possibilities rather than passive indemnifications.

The Sun representative told me that the future of licensing for the company would involve a single, consolidated license and contract for several products -- one agreement to rule them all. One governing agreement for services, support, software, and software maintenance across all Sun products, governed by a standard set of terms by which these things may be used and distributed. That would certainly make everything more convenient for customers, but only if the terms are both coherent and agreeable.

Jem Matzan is the author of three books, a freelance journalist and the editor-in-chief of The Jem Report.


  • Legal
Click Here!