[License-discuss] step by step interpretation of common permissive licenses

Massimo Zaniboni massimo.zaniboni at asterisell.com
Fri Jan 13 21:54:46 UTC 2017


On 13/01/2017 19:36, Chuck Swiger wrote:

> On Jan 13, 2017, at 10:05 AM, Massimo Zaniboni <massimo.zaniboni at asterisell.com> wrote:
>> I tried interpreting the terms of common permissive licenses following a "step by step" approach, like if they were instructions in programminng code, and I found with my big surprises that doing so they became non permissive licenses, or permissive licenses only using some "border-line" interpretation.
>
> This is a pretty common mistake that developers tend to make when reviewing licenses.

> The law doesn't come in a fully denormalized grammar suitable for context-free parsing; more importantly, judges aren't compilers.

Ok I see your point of view: every sentence of written language if 
analyzed in a too much formal way, can lose its true meaning.

According this, I 100% agree with you for MIT license, because it starts 
with a long preamble saying that you can do whatever you want, 
comprising re-licensing, and then there is a very small part saying that 
"the above copyright notice and this permission notice shall be included 
in all copies or substantial portions of the Software." So in this case 
it is sufficient to cite/credit the original work, otherwise the MIT 
preamble does not make any sense.

But I don't agree for BSD and ISC license. I think that they are poorly 
written also applying common-sense, not only from the point of view of a 
programmer, reading them in a too much logical way :-)

First I note that Apache says explicitely that you can distribuite 
derived work under different license terms. On the contrary GPL says 
explicitely that you must license derived work under the same license.

ISC says simply:

"Permission to use, copy, modify, and/or distribute this software for 
any purpose with or without fee is hereby granted, provided that the 
above copyright notice and this permission notice appear in all copies."

ISC does not mention the term sublicense/relicense/license, so reading 
it without knowing it is a permissive license, it can appear also like a 
variant of a viral license like GPL. Also GLP software can be 
distribuited with or without fee. If you interpret the term "appear" 
like "license term applications" instead of "citation/credit", then the 
ISC license seems a variant of the GPL without the requirement to 
include the source code. Only the fact that you know in advance that ISC 
is a permissive license, suggest you the correct interpretation.

The BSD license has the same problem:

"Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are 
met: [...] Redistributions in binary form must reproduce the above 
copyright notice, this list of conditions."

The sentence "reproduce the above ..." can be understood like the 
requirement that derived work must be licensed under the same license. 
So it can appear like a variant of GPL where there is no necessity to 
release also the source code. By the way also in GPL "Redistribution and 
use in source and binary form, with or without modification are 
permitted". Not much difference.

So summing up, I think:

* GPL and Apache are completely clear.

* MIT license is not so precise like GPL and Apache, but its clearly a 
permissive license. I concede this.

* I concede that BSD and ISC can be interpreted like permissive 
licenses, because I was wrong in interpreting terms like "reproduce", 
"shall include" like a requirement to use the same license terms also in 
derived products. But I still think that they are poorly written, and 
they can be misunderstood if the reader does not know in advance that 
they are permissive licenses, also if this is clearly impossible in 
real-world. So mine is only a theorical point.

IMHO if possible it is better using more clear licenses like GPL, Apache 
and in minor measure MIT.

Regards,
Massimo



More information about the License-discuss mailing list