Brevity maybe, but ease of understanding no. Copyleft licenses interact with copyright law in ways that permissive licences just don't need to. The closest you can get is probably MPL-2.0.

The GPL is particularly bad here as it pretends to define what is or isn't a derivative work, which is outside the scope of a licence but within the scope of a court. The EUPL was created partly because EU directives bound the viral clause in ways the FSF won't admit to, although that one isn't simple either (I'm not a fan of its compatibility clause).

No, the MIT license is short exactly because it has so little restrictions. You simply can't encode the desired result of GPL into 160 words like MIT can.

> I can understand the MIT license, and my corp lawyer can easily understand all the consequences of using something under MIT license.

Sounds like you need a better lawyer.

The consequences of the GPL are not all that complicated. In most cases it boils down to offering the source if you distribute the code outside your organisation.

> In most cases

Therein lies the problem. When dealing with the law, you don't want to be relatively sure that you won't go to prison or won't get sued for $1M, you want to be completely sure.

Something like the GPL is complex and non-standard as far as its interactions with the legal system go, because it is essentially a sort of hack of copyright law. If it goes before a court, you have no idea what might potentially happen. So rather than deal with that kind of complexity and uncertainty, you'd use something under MIT or Apache License that is just much better understood.

> Therein lies the problem. When dealing with the law, you don't want to be relatively sure that you won't go to prison or won't get sued for $1M, you want to be completely sure.

Not really. Unless you are redistributing it does not affect you at all.

> Something like the GPL is complex and non-standard as far as its interactions with the legal system go

it is widely used, and most people are running some copyleft software anyway, most commonly GPL or a variant such as LGPL. Linux servers, Android phones, routers, web browsers....

The situations which cause that obligation to kick in can be decidedly non-obvious.

How so?

Say you have linked against a GPL'd dependency which you have not modified but for which there is no API-compatible substitute. Are you now bound by the terms of the GPL? FSF says "yes", which tends to surprise people. But if there is an API-compatible, non-GPL'd substitute, the answer arguably becomes "no". Note that this has nothing to do either with your work or with your direct dependency, but on the existence of some random artifact out in the ecosystem which may come into existence at any point in the timeline.

API is not a random artifact but a dedicated feature designed to separate one program from another. It also implies much more stability for the external connections to the code.

It's like saying that display is a "random artifact" of a computer not making any difference in its design or usage.

The API isn't the random artifact. The third party package that also implements it is.

There are whole industries built around the notion that “License: MIT” is everything that is required to meet the notification requirements in the license. So I wouldn't say that the MIT license is easy to understand.

> I can understand the MIT license, and my corp lawyer can easily understand all the consequences of using something under MIT license. With the GPL, not so much.

Any IP lawyer who hasn't come across the GPL yet is probably not worth listening to.

I mean, would you listen to a bridge engineer who hasn't yet heard of a calculator? Sure, they may understand their shit, but if they haven't heard of calculators yet they are clearly not in the industry.

Any IP lawyer who hasn't yet read the GPL and formed a professional opinion on it isn't equipped to handle IP matters at all.