3 ms·

There certainly are "respected and well-understood" "standard" texts, for example, the Apache or GPL licenses are widely understood and are used for "all kinds

There certainly are "respected and well-understood" "standard" texts, for example, the Apache or GPL licenses are widely understood and are used for "all kinds of applications already." The legal analyses of these texts runs into the millions of pages; we know quite a lot about them at this point. What I believe you misunderstand is that "the aim" or "the whole concept" of an EULA is not to explain things clearly to end users. On the contrary, "the aim" of an EULA is to offer terms that are favorable to the licensor (and thus unfavorable to the end user), and this aim is best accomplished when the user does not especially comprehend the document. In other words, "the aim" of an EULA is to be obfuscatory. Anyone who wanted to use a standard document has many options to choose from that are probably familiar to you. ISVs who have passed over the ten-or-so standard texts that you are familiar with will not be convinced by an eleventh.

cm3 10y ago
Well, then EULAs as they are done today should be forbidden. I've read Apache2 and GPL2 licenses and I can't say I comprehend them fully. Read the liability clauses in GPL and Apache licenses and compare them to MIT or BSD.
- drewcrawford 10y ago
  Saying that licenses should be readable to software developers is like saying sourcecode should be readable to lawyers. It's a nice idea, but in the real world, even problems as simple and universal as loading an image over HTTPS is totally impenetrable to anyone outside the software development profession. It is the same for the law. Even the basic "email-grade" legal problems are actually very complicated, and it is no good trying to simplify them down to a lay level. I'll defer to Lawrence Rosen on this, from his book Open Source Licensing: Software Freedom and Intellectual Property Law: > The same programmers who cringe when a lawyer attempts to write high-quality software feel no qualms about writing their own open source licenses. Their goal, it appears, is to craft something that sounds like a license, to define a form of software freedom with reasonable terms and conditions, and then wait for the community to adopt the license and distribute software under it. This technique sometimes works. Some members of the open source community are more concerned with mak- ing a philosophical statement, getting free software distributed to the world, and letting license enforcement take care of itself somehow in the future. That can be a commendable goal, but from a lawyer’s perspective, it is amateurish and risky. The reason that BSD/MIT seem readable to you is actually that they lack a lot of clarity on important points. For example, they say nothing at all about patents, which is the primary type of software litigation today. So an Oracle-type could offer you software under an MIT license, and then turn around and sue you under patent law for using the software they offered you. Whether they would win is an interesting question, but we will not find out because you will settle. Meanwhile, Apache2 or GPL3 or other post-1970s licenses have actual clauses to deal with this. So now your lawyer can print out the license, highlight a sentence, scribble "SEE?" below it, add "Respectfully submitted, John Smith Esq." at the bottom and that is the end of your lawsuit.

cm3 10y ago

Well, then EULAs as they are done today should be forbidden. I've read Apache2 and GPL2 licenses and I can't say I comprehend them fully. Read the liability clauses in GPL and Apache licenses and compare them to MIT or BSD.

drewcrawford 10y ago
Saying that licenses should be readable to software developers is like saying sourcecode should be readable to lawyers. It's a nice idea, but in the real world, even problems as simple and universal as loading an image over HTTPS is totally impenetrable to anyone outside the software development profession. It is the same for the law. Even the basic "email-grade" legal problems are actually very complicated, and it is no good trying to simplify them down to a lay level. I'll defer to Lawrence Rosen on this, from his book Open Source Licensing: Software Freedom and Intellectual Property Law: > The same programmers who cringe when a lawyer attempts to write high-quality software feel no qualms about writing their own open source licenses. Their goal, it appears, is to craft something that sounds like a license, to define a form of software freedom with reasonable terms and conditions, and then wait for the community to adopt the license and distribute software under it. This technique sometimes works. Some members of the open source community are more concerned with mak- ing a philosophical statement, getting free software distributed to the world, and letting license enforcement take care of itself somehow in the future. That can be a commendable goal, but from a lawyer’s perspective, it is amateurish and risky. The reason that BSD/MIT seem readable to you is actually that they lack a lot of clarity on important points. For example, they say nothing at all about patents, which is the primary type of software litigation today. So an Oracle-type could offer you software under an MIT license, and then turn around and sue you under patent law for using the software they offered you. Whether they would win is an interesting question, but we will not find out because you will settle. Meanwhile, Apache2 or GPL3 or other post-1970s licenses have actual clauses to deal with this. So now your lawyer can print out the license, highlight a sentence, scribble "SEE?" below it, add "Respectfully submitted, John Smith Esq." at the bottom and that is the end of your lawsuit.