The "really bad legal advice" was unfortunately the original application for a trademark on "open source" that you yourself filed before I became involved in OSI, and that the PTO rejected before I became OSI's attorney. Let's not relive that past, Bruce, and please don't try to blame me for the situation I encountered when I was first asked to repair your application.
This type of patent claim is another reason why OSI is proposing a Mutual Defense provision in its licenses (see the Academic Free License and the Open Software License):
Mutual Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License if You file a lawsuit in any court alleging that any OSI Certified open source software that is licensed under any license containing this "Mutual Termination for Patent Action" clause infringes any patent claims that are essential to use that software.
If such a provision were in the licenses for major open source software, then companies like SBC would have to forego open source software if they wanted to assert such ridiculous patents against us.
This potential threat by SCO is another reason to encourage licensing of Linux under a license containing the Patent Mutual Defense provision that OSI has proposed in the Academic Free License and the Open Software License:
"Mutual Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License if You file a lawsuit in any court alleging that any OSI Certified open source software that is licensed under any license containing this 'Mutual Termination for Patent Action' clause infringes any patent claims that are essential to use that software."
If this provision were in the Linux license, then Caldera would be unable to sue for patent infringement unless it was willing to forego its license to use and distribute Linux.:-)
This addresses the potential problem of patent infringement, but it wouldn't help if someone infringed a copyright. That's still a bad.
There are some forms of reverse engineering that are possibly still allowed under the fair use provisions of the Copyright Act. But in light of the DMCA, I no longer understand how to do reverse engineering. The laws appear to be contradictory.
The DMCA and similar laws in other countries are terrible laws for those who want to reverse engineer. There are so many ambiguities and uncertainties about enforceability -- even the constitutionality -- of that law. I personally wouldn't take a risk of reverse engineering unless I talked to my lawyer.
That applies to proprietary software. The problem doesn't exist for open source software.
Don't waste your time reverse engineering open source software, just read the source code.
I don't mean to sound too simplistic about this point. I just happen to think its one of the major selling points for open source software.
Q: I'm particularly curious as to the distinction between provisions that the states will enforce vs. those that the DoJ will enforce.
A: Neither the states nor the DoJ will do any enforcing. Ultimately the federal district court will enforce this judgment. The parties (e.g., the states and Microsoft) will probably argue about many things in the next 5 years. I don't expect the current DoJ to give much of a damn about controlling Microsoft's behavior.
I think the result would have been very different if the plaintiffs had been able to convince the court to adopt its definitions of such terms as "middleware" rather than Microsoft's much narrower definitions. Now whether that decision was because the plaintiffs didn't argue their case strongly enough, or because the judge was disinclined to accept such arguments, I honestly don't know.
I've won (and lost) cases based on my eloquence (or lack of it) in court. There have even been situations where the judge hearing my arguments was dumber than the bench he was sitting on.
I don't think the attorneys in such a high-profile case as this lacked in eloquence, and I certainly don't think this judge was dumb!
Your notion of "blame" assumes that I think this is an all-bad-news decision. I think my interview comments made the point that there's some things here that we should be able to use to our advantage.
Not that it makes any difference to the analysis of the case, but I think we can blame the fact that this decision isn't as good as it could have been on our election of a conservative government two years ago, and on a long-standing conservative judiciary.
Now that you know my opinion about that, what good is it?
We should be proud of the collective effect of hundreds of thousands of open source supporters.
There is an enforcement committee that will stick around for a while, and three "independent" directors of Microsoft are charged with making sure the company complies.
Let's not forget that the EU still hasn't dropped its last shoe on Microsoft's monopoly.
Judge Kollar-Kotelly's ruling in the Microsoft antitrust trial was not good news but neither was it a doomsday ruling. Microsoft had already been found liable for monopolistic practices, and the court was just deciding the remedy phase for those plaintiffs who hadn't settled along with the Justice Department quite a while ago.
Basically the court decided that the previous settlement was mostly good enough. Hardly anything is new in this decision.
But it is interesting to me to see how such cases are won and lost. Microsoft controlled the definitions that the court accepted and by doing so it won this battle over its future. The court said clearly that the definitions were of paramount importance: "Integral to understanding the two remedies proposed in this case is a preliminary understanding of the manner in which the two remedies treat middleware." (Executive Summary, p. 5) The court found that Microsoft's definition of middleware was more consonant with the treatment of the term during the liability phase of the trial.
Middleware is software that resides in the middle between the operating system and something else. "It relies on the interfaces provided by the underlying operating system while simultaneously exposing its own APIs to developers." If defined broadly, such middleware would include almost any software product. If defined narrowly, it would encompass software that provides the functionality of Internet browsers, email client software, networked audio/video client software, and instant messaging software.
The court decided to accept Microsoft's narrow definition of middleware.
Microsoft now has the obligation to expose operating system APIs that are necessary to implement middleware as that term is defined by the court. To avoid confusion, the court specifically identified APIs for network and server-based applications as requiring disclosure. The court specifically excluded APIs for interactive television software, handheld devices, and Web services.
Obviously, if you can get a court to accept your definitions of terms, you can watch your opponent's proposed remedy disappear in the wind.
The open source community should make sure that Microsoft does publish all the APIs it is required to by this decision. We want to provide valuable open source software that can compete, on Microsoft's own platform and on Linux computers, against Microsoft's middleware products.
This decision gives us some prospect of competing against Microsoft, but the playing field is not even close to being level.
Assuming that the court was not going to require Microsoft to disclose *all* of its APIs, which APIs should the court have forced public? This is a strange question for an open source attorney to be asking, because from my perspective all APIs should be open, all source code published. That's the essence of open source software. But we live in a world in which antitrust law does not prevent competition from proprietary software vendors.
So how should the court have defined middleware so as to get important APIs disclosed without destroying capitalism?
I'd be interested in your thoughts about the definition of middleware.
All open source licenses are contracts subject to contract law, with the possible exception of the GPL and LGPL -- and I except those only because the FSF prefers not to think of them as contracts.
I'm not in the PR business, I'm a lawyer. And I'm telling you that, regardless of your dreams and nightmares, or your philosophical wishes, you are dealing with contracts when you license software.
Not to side-track this click-wrap issue but....
I suggest you take up the philosophy of setting conditions upon *use* with Richard Stallman. He wrote in a 3/15/2002 posting to license-discuss@opensource.org:
"The reason we've decided that this ASP requirement is legitimate is that it is a matter of requiring making the modified source code available in a case of public use. It extends existing GPL requirements coherently to a new scenario of usage.
"It would be wrong to require publication of modified versions that are used privately, but inviting the public to use a server is not private use."
I can't speak for anyone else at OSI, but I can tell you that I have proposed a license that places conditions upon use, namely that *use* of a derivative work of the licensed software on a server to deliver services to the public would require publication of the source code. This is entirely consistent with the RMS quotation above. See www.rosenlaw.com/osl.html.
Nobody cares whether you actually read the license agreement. The point is, it was presented to you, you had an opportunity to read it, you clicked on "I ACCEPT," and you can't now defend your breach of contract by pleading ignorance. (You can still plead stupidity, but last I researched it, that doesn't mean you don't pay damages.)
The click-wrap provision has nothing to do with other provisions in a license restricting use. A click-wrap provision is merely a way to ensure that the licensee has read and assented to the terms of the license, or at least that he can't afterwards say "I didn't know...." The click-wrap issue deals with assent to a contract, not use.
The only possible nexus between the two issues is whether a licensor can require someone to click his assent to the license prior to use of the software. I read nothing in the copyright act that prohibits such a license requirement.
True, a contract is not necessary to enforce copyright law. But as a licensor I may prefer to rely on contract rather than copyright law. For those who do, a click-wrap may be essential.
There is a separate discussion on license-discuss@opensource.org that is focusing on "use" issues. Please don't confuse the two.
As to your "name of mud" comment, please don't resort to ad hominem arguments. Stick to the issues.
As one of the people who was present at the OSI board meeting, and as one who expressed some strong sentiments about the click-wrap issue, I want to comment directly.
The issue is not whether OSI should require that licenses contain a click-wrap provision. That was never under consideration.
Some of us attorneys (scum though we may be!) believe that courts will not enforce a license unless there has been a clear manifestation of assent to the contract expressed by the license. Those of us who share that belief, which is based upon our reading of many court cases, want to allow licensors to include a click-wrap provision in their open source licenses.
Some of you referred to the article by Eben Moglen to the effect that the GPL doesn't require assent because it isn't a contract. Nobody ever suggested that the GPL be amended to include a click-wrap provision, or that anyone modify their GPL software startup scripts to include a click-wrap button. In fact, nobody ever suggested that *any* existing open source license be changed to include a click-wrap provision.
Some of you replied that you don't like click-wrap, or ignore them, or press the button to accept without actually reading the license.... That, too, isn't the issue. Merely because a license provides a mechanism for assent to its terms doesn't mean that all who fail to follow the procedure will be summarily executed. You simply won't be able to raise the defense -- if you're ever challenged for doing something not permitted by the license -- that you weren't properly informed of the consequences. But since I make it a habit of not giving legal advice in general fora like these, feel free to ignore what I say or to consult your own attorney for advice.
So please, comment on the issue at hand: Should the OSD be amended to make it clear that a click-wrap provision in a license will make that license non-open source? Or should licensors be allowed to include a click-wrap provision in an open source license?
A final note: Regardless of what OSI does, those of you who hate click-wrap licenses will remain free not to use any software that is licensed under a click-wrap license.
Slashdot Mirror
The "really bad legal advice" was unfortunately the original application for a trademark on "open source" that you yourself filed before I became involved in OSI, and that the PTO rejected before I became OSI's attorney. Let's not relive that past, Bruce, and please don't try to blame me for the situation I encountered when I was first asked to repair your application.
If such a provision were in the licenses for major open source software, then companies like SBC would have to forego open source software if they wanted to assert such ridiculous patents against us.
"Mutual Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License if You file a lawsuit in any court alleging that any OSI Certified open source software that is licensed under any license containing this 'Mutual Termination for Patent Action' clause infringes any patent claims that are essential to use that software."
If this provision were in the Linux license, then Caldera would be unable to sue for patent infringement unless it was willing to forego its license to use and distribute Linux. :-)
This addresses the potential problem of patent infringement, but it wouldn't help if someone infringed a copyright. That's still a bad.
The DMCA and similar laws in other countries are terrible laws for those who want to reverse engineer. There are so many ambiguities and uncertainties about enforceability -- even the constitutionality -- of that law. I personally wouldn't take a risk of reverse engineering unless I talked to my lawyer.
That applies to proprietary software. The problem doesn't exist for open source software.
Don't waste your time reverse engineering open source software, just read the source code.
I don't mean to sound too simplistic about this point. I just happen to think its one of the major selling points for open source software.
Announce it on SlashDot if they try to. /Larry
A: Neither the states nor the DoJ will do any enforcing. Ultimately the federal district court will enforce this judgment. The parties (e.g., the states and Microsoft) will probably argue about many things in the next 5 years. I don't expect the current DoJ to give much of a damn about controlling Microsoft's behavior.
/Larry
I think the result would have been very different if the plaintiffs had been able to convince the court to adopt its definitions of such terms as "middleware" rather than Microsoft's much narrower definitions. Now whether that decision was because the plaintiffs didn't argue their case strongly enough, or because the judge was disinclined to accept such arguments, I honestly don't know.
I've won (and lost) cases based on my eloquence (or lack of it) in court. There have even been situations where the judge hearing my arguments was dumber than the bench he was sitting on.
I don't think the attorneys in such a high-profile case as this lacked in eloquence, and I certainly don't think this judge was dumb!
Your notion of "blame" assumes that I think this is an all-bad-news decision. I think my interview comments made the point that there's some things here that we should be able to use to our advantage.
/Larry
NOT a relative, thank God. /Larry
Now that you know my opinion about that, what good is it?
/Larry
My suggestion was to consult a lawyer before reverse engineering. In some instances it is legal and in others not. /Larry
There is an enforcement committee that will stick around for a while, and three "independent" directors of Microsoft are charged with making sure the company complies.
Let's not forget that the EU still hasn't dropped its last shoe on Microsoft's monopoly.
And we DO know how to get press attention.
/Larry
Judge Kollar-Kotelly's ruling in the Microsoft antitrust trial was not good news but neither was it a doomsday ruling. Microsoft had already been found liable for monopolistic practices, and the court was just deciding the remedy phase for those plaintiffs who hadn't settled along with the Justice Department quite a while ago.
Basically the court decided that the previous settlement was mostly good enough. Hardly anything is new in this decision.
But it is interesting to me to see how such cases are won and lost. Microsoft controlled the definitions that the court accepted and by doing so it won this battle over its future. The court said clearly that the definitions were of paramount importance: "Integral to understanding the two remedies proposed in this case is a preliminary understanding of the manner in which the two remedies treat middleware." (Executive Summary, p. 5) The court found that Microsoft's definition of middleware was more consonant with the treatment of the term during the liability phase of the trial.
Middleware is software that resides in the middle between the operating system and something else. "It relies on the interfaces provided by the underlying operating system while simultaneously exposing its own APIs to developers." If defined broadly, such middleware would include almost any software product. If defined narrowly, it would encompass software that provides the functionality of Internet browsers, email client software, networked audio/video client software, and instant messaging software.
The court decided to accept Microsoft's narrow definition of middleware.
Microsoft now has the obligation to expose operating system APIs that are necessary to implement middleware as that term is defined by the court. To avoid confusion, the court specifically identified APIs for network and server-based applications as requiring disclosure. The court specifically excluded APIs for interactive television software, handheld devices, and Web services.
Obviously, if you can get a court to accept your definitions of terms, you can watch your opponent's proposed remedy disappear in the wind.
The open source community should make sure that Microsoft does publish all the APIs it is required to by this decision. We want to provide valuable open source software that can compete, on Microsoft's own platform and on Linux computers, against Microsoft's middleware products.
This decision gives us some prospect of competing against Microsoft, but the playing field is not even close to being level.
Assuming that the court was not going to require Microsoft to disclose *all* of its APIs, which APIs should the court have forced public? This is a strange question for an open source attorney to be asking, because from my perspective all APIs should be open, all source code published. That's the essence of open source software. But we live in a world in which antitrust law does not prevent competition from proprietary software vendors.
So how should the court have defined middleware so as to get important APIs disclosed without destroying capitalism?
I'd be interested in your thoughts about the definition of middleware.
Good suggestion. That encompasses section 117 rights as well.
Then how about a provision of the OSD that reads something like the following:
"An open source license cannot restrict any fair use rights that would be available for a copyrighted work in the absence of a license."
The question is, can an open source licensor that *wants to do so* require a click-wrap on his/her license?
All open source licenses are contracts subject to contract law, with the possible exception of the GPL and LGPL -- and I except those only because the FSF prefers not to think of them as contracts.
I'm not in the PR business, I'm a lawyer. And I'm telling you that, regardless of your dreams and nightmares, or your philosophical wishes, you are dealing with contracts when you license software.
Not to side-track this click-wrap issue but....
I suggest you take up the philosophy of setting conditions upon *use* with Richard Stallman. He wrote in a 3/15/2002 posting to license-discuss@opensource.org:
"The reason we've decided that this ASP requirement is legitimate is that it is a matter of requiring making the modified source code available in a case of public use. It extends existing GPL requirements coherently to a new scenario of usage.
"It would be wrong to require publication of modified versions that are used privately, but inviting the public to use a server is not private use."
I can't speak for anyone else at OSI, but I can tell you that I have proposed a license that places conditions upon use, namely that *use* of a derivative work of the licensed software on a server to deliver services to the public would require publication of the source code. This is entirely consistent with the RMS quotation above. See www.rosenlaw.com/osl.html.
Nobody cares whether you actually read the license agreement. The point is, it was presented to you, you had an opportunity to read it, you clicked on "I ACCEPT," and you can't now defend your breach of contract by pleading ignorance. (You can still plead stupidity, but last I researched it, that doesn't mean you don't pay damages.)
The click-wrap provision has nothing to do with other provisions in a license restricting use. A click-wrap provision is merely a way to ensure that the licensee has read and assented to the terms of the license, or at least that he can't afterwards say "I didn't know...." The click-wrap issue deals with assent to a contract, not use.
The only possible nexus between the two issues is whether a licensor can require someone to click his assent to the license prior to use of the software. I read nothing in the copyright act that prohibits such a license requirement.
True, a contract is not necessary to enforce copyright law. But as a licensor I may prefer to rely on contract rather than copyright law. For those who do, a click-wrap may be essential.
There is a separate discussion on license-discuss@opensource.org that is focusing on "use" issues. Please don't confuse the two.
As to your "name of mud" comment, please don't resort to ad hominem arguments. Stick to the issues.
The issue is not whether OSI should require that licenses contain a click-wrap provision. That was never under consideration.
Some of us attorneys (scum though we may be!) believe that courts will not enforce a license unless there has been a clear manifestation of assent to the contract expressed by the license. Those of us who share that belief, which is based upon our reading of many court cases, want to allow licensors to include a click-wrap provision in their open source licenses.
Some of you referred to the article by Eben Moglen to the effect that the GPL doesn't require assent because it isn't a contract. Nobody ever suggested that the GPL be amended to include a click-wrap provision, or that anyone modify their GPL software startup scripts to include a click-wrap button. In fact, nobody ever suggested that *any* existing open source license be changed to include a click-wrap provision.
Some of you replied that you don't like click-wrap, or ignore them, or press the button to accept without actually reading the license.... That, too, isn't the issue. Merely because a license provides a mechanism for assent to its terms doesn't mean that all who fail to follow the procedure will be summarily executed. You simply won't be able to raise the defense -- if you're ever challenged for doing something not permitted by the license -- that you weren't properly informed of the consequences. But since I make it a habit of not giving legal advice in general fora like these, feel free to ignore what I say or to consult your own attorney for advice.
So please, comment on the issue at hand: Should the OSD be amended to make it clear that a click-wrap provision in a license will make that license non-open source? Or should licensors be allowed to include a click-wrap provision in an open source license?
A final note: Regardless of what OSI does, those of you who hate click-wrap licenses will remain free not to use any software that is licensed under a click-wrap license.