If I were you I would now transform all known licenses into their own structured version and publish that, put all in a simple website for people to consult and link to.
In that same website, you could even have a "crete your personalized license" where you would instruct people on how to create their own Legalfile.
When hosting their own Legalfile on GitHub, for example, people would link to your site so visitors can understand what does that Legalfile mean.
Thanks! That's something that could be done, totally. But wanted first some discussion, to get a valid, viable model and then do the work of creating Legalfiles for most popular existing licenses.
It’s fine to create a table or tool or app to help people find the license they want, but please do not encourage people to put this file you are describing in their repos.
There is no form of law that is as complex or specialized as copyright law. The forms of these licenses are complex not because no one was smart enough to realize it would be nice if they were simpler but because that complexity is required to adequately and accurately define the terms of the license being granted.
If a developer posts some code on github with an MIT or Apache or GPL vWhatever license, that’s how that code is licensed. The legal terms and issues are clear and well defined and done in a way that is known to stand up in court. If they post their code with that license AND your file containing your description of the license’s meaning and implications AND there is some subtlety of copyright law in some region somewhere around the world that you didn’t appreciate then in the best case that package is now licensed under two licenses, one written by an experienced lawyer and one written by someone with no knowledge of copyright law in that location (which is unlikely to be interpreted the way you want by the courts in that region) because yes your legal file could well be interpreted as a form of license. That’s the best case, the case where you just created a new, non-OSI-approved license that has implications neither you nor anyone else thought about, wanted, or anticipated. In the worst case, which is actually the important case in most legal scenarios, the developer is now guilty of making false representations about how their software is licensed, because that summary they added describing how the software is licensed does not align with how that region’s copyright law history interprets that particular form of license and the court views the legal file as a form of advertising that makes claims of a legal nature. It’s more than possible to have both the best case scenario (which is bad, because that code is now licensed by a license written by someone who didn’t understand copyright law) AND the worst case (the developer is guilty of fraud or misrepresentation or false advertising or some other crime for having attempted to license it under the well-written license while advertising it as being available under what the court views as a different set of license terms).
You’re a software developer. Law is like C++. It’s an incredibly powerful language designed by professionals to be used by professionals as a means of discussing edge cases most people never have to think about but that courts do. Think of courts like compilers, except every court compiles the code just a little bit differently in ways that are not entirely deterministic in advance and are determined in part by watching the historical behavior of thousands of other non-deterministic compilers acting on other pieces of code in the past. Sure you can come along and make a “simplified” version of C++17 that’s “much easier for normal people to read” but unless you are a world class language designer with decades of experience in C++ the odds your simplified version of C++ is actually a good idea are very slim. Law is like that. It’s hard, for a reason, and the reason is that it needs to be able to encode hard concepts that are rare in normal contexts but have to be addressed by the law, just like the way C++ needs to encode hard concepts around object lifetime behavior and ownership and etc. that most causal programmers never need to worry about but that sometimes are needed and are why C++ exists and is hard.
There is a movement in law directed at making legal documents more human readable. It’s an important effort being undertaken by people with tremendous experience in legal language. That’s very different from a developer saying “I’m not a lawyer but hold my beer because this is easy.”
tl;dr this is fine for helping people search a database of existing licenses but don’t encourage people to put this kind of file in...
@yodon, I gather you're a lawyer? (I am.) @Sirikon's idea could work if each phrase in his taxonomy (e.g., "cannot" and "hold-liable") were mapped to standardized, more-detailed language, akin to a macro.
This would be analogous to the widespread use of three-letter abbreviations in INCOTERMS 2010 [0], such as "DDP" to signify that goods are to be "delivered duty paid," or "EXW" (ex works) to signify that the customer will pick up the goods at the seller's factory. Each of those terms, and many others, is fleshed out in INCOTERMS publications [1].
It'd also be analogous to the old commercial code books in the days of charge-by-the-word telegraphy, where COGNOSCO might mean "Dining out this evening, send my dress clothes here" or DIONYSIA might mean "Amputation is considered necessary." [2]
@dctoedt As they say IANAL, but more importantly I suspect the project author isn’t a lawyer. The issue isn’t the viability of a standard for simplifying legal documents (insert overused XKCD standards comic), its the viability of a standard for simplifying legal documents that was designed by non-experts.
That said, I’m doubtful a code-book approach like you suggest would result in a net improvement in readability of existing licenses (which I think is the goal), particularly in an era when AI-driven contract analysis engines are starting to be able to read and summarize legal documents for informing normal people on the document’s meaning as well as experienced lawyers. My guess is in 2-3 years something like google translate will actually be able to do a better job of achieving these license readability goals than any of the human-authored approaches in discussion here.
"@Sirikon's idea could work if each phrase in his taxonomy (e.g., "cannot" and "hold-liable") were mapped to standardized, more-detailed language, akin to a macro."
Maybe a good first step could be the definition of this language if it doesn't exist yet.
For several years I've been playing around with something like that as a side project — see http://www.CommonDraft.org (which isn't especially pretty; I'm in the middle of refactoring it to make it more Lego-like).
There is no form of law that is as complex or specialized as copyright law.
Had a good laugh with a bunch of fellow lawyers about that. Copyright law is one of the simpler areas of law, as far as complexity goes. What makes copyright complex isn't the law, it's tracking the ownership of rights.
First of all, thank you for your detailed response.
I mostly agree on everything you're saying. Just a detail:
"If they post their code with that license AND your file containing your description of the license’s meaning and implications AND there is some subtlety of copyright law in some region somewhere around the world that you didn’t appreciate then in the best case that package is now licensed under two licenses"
Would be useful a, somehow, disclaimer that says "This Legalfile thing isn't valuable by itself, as it's just a simplified representation of a more complex license which exists in the same folder".
I, of course, understand the overwhelming complexity of laws, thought on this as a tool to say "This package is FOR SURE not suitable for your current goals", as a tool to ease some things up, but always be thought as an assistant that provides useful information, but may not have and understand everything.
Specifically, the Debian copyright file provides full annotation about what parts of a package are licensed under what and by who. It only indicates licenses -- it's up to the end users to determine what those mean -- but it is machine readable.
The names of the licenses themselves are part of a list of names called SPDX that's used across distributions and is developed by the Linux Foundation.
This should be for developers, for creators. A way to ease the task of checking legal compatibilities.
Also, in my opinion, a way to give this to all developers is the commitment of package managers maintainers to include legality checking in the process of installing third-party packages.
In case you missed it, Github open sourced Licensed, a cross-language cross-(package manager) tool to find and store metadata about all licenses used in a git repo, to surface potential dependency problems.
19 comments
[ 3.6 ms ] story [ 12.6 ms ] threadIf I were you I would now transform all known licenses into their own structured version and publish that, put all in a simple website for people to consult and link to.
In that same website, you could even have a "crete your personalized license" where you would instruct people on how to create their own Legalfile.
When hosting their own Legalfile on GitHub, for example, people would link to your site so visitors can understand what does that Legalfile mean.
There is no form of law that is as complex or specialized as copyright law. The forms of these licenses are complex not because no one was smart enough to realize it would be nice if they were simpler but because that complexity is required to adequately and accurately define the terms of the license being granted.
If a developer posts some code on github with an MIT or Apache or GPL vWhatever license, that’s how that code is licensed. The legal terms and issues are clear and well defined and done in a way that is known to stand up in court. If they post their code with that license AND your file containing your description of the license’s meaning and implications AND there is some subtlety of copyright law in some region somewhere around the world that you didn’t appreciate then in the best case that package is now licensed under two licenses, one written by an experienced lawyer and one written by someone with no knowledge of copyright law in that location (which is unlikely to be interpreted the way you want by the courts in that region) because yes your legal file could well be interpreted as a form of license. That’s the best case, the case where you just created a new, non-OSI-approved license that has implications neither you nor anyone else thought about, wanted, or anticipated. In the worst case, which is actually the important case in most legal scenarios, the developer is now guilty of making false representations about how their software is licensed, because that summary they added describing how the software is licensed does not align with how that region’s copyright law history interprets that particular form of license and the court views the legal file as a form of advertising that makes claims of a legal nature. It’s more than possible to have both the best case scenario (which is bad, because that code is now licensed by a license written by someone who didn’t understand copyright law) AND the worst case (the developer is guilty of fraud or misrepresentation or false advertising or some other crime for having attempted to license it under the well-written license while advertising it as being available under what the court views as a different set of license terms).
You’re a software developer. Law is like C++. It’s an incredibly powerful language designed by professionals to be used by professionals as a means of discussing edge cases most people never have to think about but that courts do. Think of courts like compilers, except every court compiles the code just a little bit differently in ways that are not entirely deterministic in advance and are determined in part by watching the historical behavior of thousands of other non-deterministic compilers acting on other pieces of code in the past. Sure you can come along and make a “simplified” version of C++17 that’s “much easier for normal people to read” but unless you are a world class language designer with decades of experience in C++ the odds your simplified version of C++ is actually a good idea are very slim. Law is like that. It’s hard, for a reason, and the reason is that it needs to be able to encode hard concepts that are rare in normal contexts but have to be addressed by the law, just like the way C++ needs to encode hard concepts around object lifetime behavior and ownership and etc. that most causal programmers never need to worry about but that sometimes are needed and are why C++ exists and is hard.
There is a movement in law directed at making legal documents more human readable. It’s an important effort being undertaken by people with tremendous experience in legal language. That’s very different from a developer saying “I’m not a lawyer but hold my beer because this is easy.”
tl;dr this is fine for helping people search a database of existing licenses but don’t encourage people to put this kind of file in...
This would be analogous to the widespread use of three-letter abbreviations in INCOTERMS 2010 [0], such as "DDP" to signify that goods are to be "delivered duty paid," or "EXW" (ex works) to signify that the customer will pick up the goods at the seller's factory. Each of those terms, and many others, is fleshed out in INCOTERMS publications [1].
It'd also be analogous to the old commercial code books in the days of charge-by-the-word telegraphy, where COGNOSCO might mean "Dining out this evening, send my dress clothes here" or DIONYSIA might mean "Amputation is considered necessary." [2]
[0] https://en.wikipedia.org/wiki/Incoterms
[1] https://iccwbo.org/resources-for-business/incoterms-rules/in...
[2] https://en.wikipedia.org/wiki/Commercial_code_(communication...
That said, I’m doubtful a code-book approach like you suggest would result in a net improvement in readability of existing licenses (which I think is the goal), particularly in an era when AI-driven contract analysis engines are starting to be able to read and summarize legal documents for informing normal people on the document’s meaning as well as experienced lawyers. My guess is in 2-3 years something like google translate will actually be able to do a better job of achieving these license readability goals than any of the human-authored approaches in discussion here.
Maybe a good first step could be the definition of this language if it doesn't exist yet.
Had a good laugh with a bunch of fellow lawyers about that. Copyright law is one of the simpler areas of law, as far as complexity goes. What makes copyright complex isn't the law, it's tracking the ownership of rights.
I mostly agree on everything you're saying. Just a detail:
"If they post their code with that license AND your file containing your description of the license’s meaning and implications AND there is some subtlety of copyright law in some region somewhere around the world that you didn’t appreciate then in the best case that package is now licensed under two licenses"
Would be useful a, somehow, disclaimer that says "This Legalfile thing isn't valuable by itself, as it's just a simplified representation of a more complex license which exists in the same folder".
I, of course, understand the overwhelming complexity of laws, thought on this as a tool to say "This package is FOR SURE not suitable for your current goals", as a tool to ease some things up, but always be thought as an assistant that provides useful information, but may not have and understand everything.
Specifically, the Debian copyright file provides full annotation about what parts of a package are licensed under what and by who. It only indicates licenses -- it's up to the end users to determine what those mean -- but it is machine readable.
The names of the licenses themselves are part of a list of names called SPDX that's used across distributions and is developed by the Linux Foundation.
https://spdx.org/
which as the GP says is the source of license codes used by Debian, as well as the license field in NPM's package.json.
https://spdx.org/licenses/
Companies don't really care for this, as they'll use their lawyers to vet compatibility, and lawyers rely on the original license's verbiage.
Individuals and smaller companies will still continue to comply/violate terms, as small fish typically face no consequences from violating terms
Also, in my opinion, a way to give this to all developers is the commitment of package managers maintainers to include legality checking in the process of installing third-party packages.
Official announcement here: https://githubengineering.com/improving-your-oss-dependency-...
Repo here: https://github.com/github/licensed