[kemitchell]

Readability goes to whether a license is misleading. The more readable, the less potential to mislead, assuming effect isn't compromised for it.

If you found GPL easy to read, v2 or v3, you join a list that as far as I know includes no active open licensing lawyers. Of all the major, painful, routine questions about open license compliance, those from GPLs outnumber all the rest.

Getting through the text is one thing. But that alone is not what I mean by a license being readable. In substance, rather than form, it has to be a functional set of rules.

If by term of art you mean defined with precision, neither open source nor free software meet that standard, unless you count definitions that say "whatever such-and-such organization says" or "whatever such-and-such organization's founder says".

The OSD may be readable for you, but only in the way GPL was. There's no legal or otherwise technical precision beneath those pleasant terms answering old, important questions.

More on that: https://writing.kemitchell.com/2019/04/23/OSD-wontfix.html

[cyphar]

> Readability goes to whether a license is misleading.

Nobody said the license text was misleading. The point is that the use of the term "open software" is misleading because it leads the reader to think it's similar to "open source" which in fact isn't.

On the topic of precise definitions, you might argue that "open source" is imprecise because it has other meanings and was in common use before OSI. But "free software" was a brand-new term and has a specific definition (the four freedoms). The DFSG are guidelines and tests to verify if the definition is followed.

[kemitchell]

The four freedoms, or What is free software? on fsf.org, are even less precise than the Open Source Definition. None of those is an effective "test" in any technical sense. Frequently, debates about whether licenses "pass" them turn into debates about what the words of the test mean, rather than what the terms of the license mean.

To give a sense, FSF says "four freedoms", but they actually require at least five. The fifth (number 4) is the right to make and share nonfree work based on free work within organizations, known as "private changes". FSF writing doesn't explain the boundary between running and changing, or why free software licenses can set conditions on changing, but not running, or why AGPL gets to break that rule. They don't explain how anti-Tivo or anti-DRM satisfy the freedoms.

Readable licenses are important because they cut the welds on the hood of software licensing. Devs can read Parity or Prosperity or Charity or Blue Oak and decide for themselves whether it's open or free or public or simply allows them to do what they want to do. They don't have to trust intermediaries, who it turns out apply unexpressed, private views on what the definitions mean as or more often than expertise on what the licenses mean.

As for Parity and strong copyleft generally, consider:

> I make my code available for use in free software, and not for use in proprietary software, in order to encourage other people who write software to make it free as well. I figure that since proprietary software developers use copyright to stop us from sharing, we cooperators can use copyright to give other cooperators an advantage of their own: they can use our code.

Copyright has given authors broader and stronger control of their work in the last three decades. Why haven't FSF copyleft licenses gotten correspondingly stronger?