TldrLegal – Software Licenses Explained in Plain English(tldrlegal.com)
tldrlegal.com
TldrLegal – Software Licenses Explained in Plain English
https://tldrlegal.com/
33 comments
I agree that oversimplifying is a problem and the devil is in the details.
Having said that, I believe it's possible to present licenses in an easier-to-digest way by hilighting specifics and providing examples of real-world implications that different clauses carry with them, providing perspective from multiple different view points.
There are many ways to do this, but one method would be to present the visitor with questions about what he intends to do (or intends to let others do) with code covered by a given license, and proceed to point out the relevant restrictions and obligations in that case.
For example, do you intend to redistribute the work?
In case of the 2-clause BSD license, this should hilight the fact that for binary distribution, you are obliged to include the license in documentation and/or other materials; and perhaps give examples of cases where this might be a problematic requirement.
For GPLv2, it would have to go into detail about having to provide the source or a written offer (and then make sure you have the source around for three years!), etc.
None of this is substitute for actually reading the license texet, but this sort of a resource could really help people understand points they glossed over, forgot, or somehow misunderstood, or whose implications (negative or positive) they did not realize. Add cross-references and people could really check their undestanding of the license text they've read.
Actually, I was hoping this would be exactly that resource, and that is why I asked in another comment about whether there's any legal backing behind this project. Because if somebody is going to write an elaborate guide to some license, it'd better be good, and not based on common misconceptions.
Having said that, I believe it's possible to present licenses in an easier-to-digest way by hilighting specifics and providing examples of real-world implications that different clauses carry with them, providing perspective from multiple different view points.
There are many ways to do this, but one method would be to present the visitor with questions about what he intends to do (or intends to let others do) with code covered by a given license, and proceed to point out the relevant restrictions and obligations in that case.
For example, do you intend to redistribute the work?
In case of the 2-clause BSD license, this should hilight the fact that for binary distribution, you are obliged to include the license in documentation and/or other materials; and perhaps give examples of cases where this might be a problematic requirement.
For GPLv2, it would have to go into detail about having to provide the source or a written offer (and then make sure you have the source around for three years!), etc.
None of this is substitute for actually reading the license texet, but this sort of a resource could really help people understand points they glossed over, forgot, or somehow misunderstood, or whose implications (negative or positive) they did not realize. Add cross-references and people could really check their undestanding of the license text they've read.
Actually, I was hoping this would be exactly that resource, and that is why I asked in another comment about whether there's any legal backing behind this project. Because if somebody is going to write an elaborate guide to some license, it'd better be good, and not based on common misconceptions.
TLDRLegal creator here. Let me explain my point of view: the big huge problem is that most people aren't educated in-depth about licensing, yet 90% of the legwork that most people need to determine if a license is usable or not can be done rather quickly in a way that shares commonalities with many others. If you know right away you can't disclose your proprietary source, than knowing about affero, patent rights, warranty, Tivoization, and etc becomes irrelevant. TLDR aims to be a step in the right direction -- to reduce risk and improve the current state of where people who already "TLDR" licenses will at least get the gist of it. Yet it's clearly stated on the site that summaries aren't replacements for license texts. Yet the best part is that all of your ideas can get into the summary pages too. If you think it's important, there are many ways to highlight unannounced features of licenses (full text or expanded license attributes for instance).
"GPL v3 tries to close some loopholes in GPL v2." And what, in plain English, would those loopholes be?
GPLv2 says: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein.".
GPLv3 explicit says: "not allow patents to restrict development and use of software"
GPLv3 also say that you can not use hardware restrictions as a trick to circumventing the no-further-restrictions legal requirement.
One could argue that GPLv2 already include everything GPLv3 do in form of that single line. Doing such interpretation would for all practical purposes upgrade every gplv2-only project to the same conditions as of GPLv3 (but with fewer license compatibilities). The FSF clearly decided not to go that route, and created the GPLv3.
GPLv3 explicit says: "not allow patents to restrict development and use of software"
GPLv3 also say that you can not use hardware restrictions as a trick to circumventing the no-further-restrictions legal requirement.
One could argue that GPLv2 already include everything GPLv3 do in form of that single line. Doing such interpretation would for all practical purposes upgrade every gplv2-only project to the same conditions as of GPLv3 (but with fewer license compatibilities). The FSF clearly decided not to go that route, and created the GPLv3.
The GPLv3 served two main purposes:
1) Prevent Tivoization[0]. As noted below, it could be argued that the GPLv2 already forbade this, but that is left up to legal interpretation (which did not always agree in practice). So they made this explicit in the GPLv3.
2) Allow interoperability between the different "flavors" of the GPL. The GPL comes in three "flavors" - regular, lesser, and Affero. Under v2, projects using the regular GPL could not be combined with projects using the Affero GPL. Under v3, all three of these can be safely mixed.
(Essentially, for v3, each of the "flavors" includes an explicit exception for the other two, if I remember correctly).
[0] https://en.wikipedia.org/wiki/Tivoization
1) Prevent Tivoization[0]. As noted below, it could be argued that the GPLv2 already forbade this, but that is left up to legal interpretation (which did not always agree in practice). So they made this explicit in the GPLv3.
2) Allow interoperability between the different "flavors" of the GPL. The GPL comes in three "flavors" - regular, lesser, and Affero. Under v2, projects using the regular GPL could not be combined with projects using the Affero GPL. Under v3, all three of these can be safely mixed.
(Essentially, for v3, each of the "flavors" includes an explicit exception for the other two, if I remember correctly).
[0] https://en.wikipedia.org/wiki/Tivoization
As a software developer, I want people to use my stuff. Once over the hurdle of writing something that people might find useful, I have to choose a license. When it's a library, I usually choose something without much restrictions, like MIT or Apache v2, or else developer will just go look elsewhere.
However there is a project which is a full blown application, and I went GPLv3, because I want anybody to be able to use it, or fork it. However it would bother me if someone was using this project to earn money, as I personally forfeited deriving any income from this project (not even donations). Apparently GPLv3 allows commercial use (I didn't realize that when I picked the license).
What license would best match my concerns?
However there is a project which is a full blown application, and I went GPLv3, because I want anybody to be able to use it, or fork it. However it would bother me if someone was using this project to earn money, as I personally forfeited deriving any income from this project (not even donations). Apparently GPLv3 allows commercial use (I didn't realize that when I picked the license).
What license would best match my concerns?
There are no common open source licenses which forbid commercial use, as that is against the various different guidelines for what constitutes open source or free software (the Free Software Foundation Free Software definition: https://www.gnu.org/philosophy/free-sw.html, the Debian Free Software Guidelines: https://www.debian.org/social_contract, or the Open Source Definition: http://opensource.org/osd-annotated).
Probably the closest you can get in the form of commonly recognized license that meets those criteria is the Creative Commons Attribution-NonCommercial-ShareAlike license: http://creativecommons.org/licenses/by-nc-sa/4.0/. It was designed for creative works (books, movies, music, and so on) rather than software, so it doesn't address some technicalities that come up in the software field, but it is a license which allows modification and redistribution but not commercial use.
However, you have to ask yourself, why do you want to do this? Are you planning on selling the software commercially yourself? If someone else happens to make some money by adding features to your software and releasing them back to the community for anyone to use (which they are required to do under the terms of the GPL), does that actually hurt you? Or if they don't change it and just sell it straight, why would anyone buy that over the free version?
Why did you voluntarily forfeit making any money, even donations? Would you accept donations if offered? How about accept a contract to add a particular feature? If you won't accept that, why would you want someone else not to be able to accept such an offer to add a given feature? If your users are willing to pay for development, but you don't want to accept the money, should someone else not be able to accept the money, put the work in, and release their changes under the same license?
I would recommend sticking to the GPLv3. Most of the kinds of commercial use that are actually objectionable, like adding proprietary features and selling that version at a premium, are not possible under the GPLv3.
Probably the closest you can get in the form of commonly recognized license that meets those criteria is the Creative Commons Attribution-NonCommercial-ShareAlike license: http://creativecommons.org/licenses/by-nc-sa/4.0/. It was designed for creative works (books, movies, music, and so on) rather than software, so it doesn't address some technicalities that come up in the software field, but it is a license which allows modification and redistribution but not commercial use.
However, you have to ask yourself, why do you want to do this? Are you planning on selling the software commercially yourself? If someone else happens to make some money by adding features to your software and releasing them back to the community for anyone to use (which they are required to do under the terms of the GPL), does that actually hurt you? Or if they don't change it and just sell it straight, why would anyone buy that over the free version?
Why did you voluntarily forfeit making any money, even donations? Would you accept donations if offered? How about accept a contract to add a particular feature? If you won't accept that, why would you want someone else not to be able to accept such an offer to add a given feature? If your users are willing to pay for development, but you don't want to accept the money, should someone else not be able to accept the money, put the work in, and release their changes under the same license?
I would recommend sticking to the GPLv3. Most of the kinds of commercial use that are actually objectionable, like adding proprietary features and selling that version at a premium, are not possible under the GPLv3.
As you say, CC licenses are not appropriate for software. The CC-NC clause is also bad for ANYTHING because non-commercial clauses are bad and incompatible. The PRIMARY effect of an NC clause is to be a Wikipedia-incompatible clause, regardless of whether there's ever any commercial use or not.
See http://freedomdefined.org/Licenses/NC
See http://freedomdefined.org/Licenses/NC
I agree with you, I was just trying to answer his question while at the same time trying to clarify why he felt like a non-commercial clause was necessary.
Please don't be anti-commerce. Commerce is healthy.
http://mimiandeunice.com/2010/10/01/non-commercial/
You are probably conflating the idea that most commercial software is proprietary, so not only does it make money but it does so by restricting the users' freedoms. The GPL is exactly what you want to block this. The GPL says you can only make money with this if you figure out how to do so while respecting user freedom! You should be happy to allow that.
Any license that has a blanket anti-commerce clause is non-Free and non-Open, i.e. is proprietary, by all standards. Do not use such a license.
http://mimiandeunice.com/2010/10/01/non-commercial/
You are probably conflating the idea that most commercial software is proprietary, so not only does it make money but it does so by restricting the users' freedoms. The GPL is exactly what you want to block this. The GPL says you can only make money with this if you figure out how to do so while respecting user freedom! You should be happy to allow that.
Any license that has a blanket anti-commerce clause is non-Free and non-Open, i.e. is proprietary, by all standards. Do not use such a license.
Looks to me like you are conflating the idea because I rather not see someone using the fruit of work to earn an income I must be "anti-commerce" and need to be lectured about it.
Software licences for dummies - hell, I'm mostly clueless about this so I had a good look.
One point I will make is that as soon as you read the relevant material on this site, you have to go into a dark corner and read the small print.
I've noticed the odd comment or two on this page mentioning lawyers. A bit expensive, but they're the most qualified people to talk to, bar (sorry, bad pun) judges.
At college, I used to live with someone training to be a barrister. Whereas the average thickness of my maths and science texts is, say 500 pages, I saw one book on law hitting around 2,500 pages. It ranks alongside the London Knowledge for verbosity.
One point I will make is that as soon as you read the relevant material on this site, you have to go into a dark corner and read the small print.
I've noticed the odd comment or two on this page mentioning lawyers. A bit expensive, but they're the most qualified people to talk to, bar (sorry, bad pun) judges.
At college, I used to live with someone training to be a barrister. Whereas the average thickness of my maths and science texts is, say 500 pages, I saw one book on law hitting around 2,500 pages. It ranks alongside the London Knowledge for verbosity.
Social media connect under "Follow tldr" is broken for me (Chrome 33 on OSX).
Also, use "e.g." not "i.e." -- while similar, the contextually mean different things. The former is "for example", the latter is "for instance."
Really gave me doubts to the integrity of the website if such a simple grammar mistake was made on the front page, in the call-to-action.
Food for thought.
Also, use "e.g." not "i.e." -- while similar, the contextually mean different things. The former is "for example", the latter is "for instance."
Really gave me doubts to the integrity of the website if such a simple grammar mistake was made on the front page, in the call-to-action.
Food for thought.
Aargh! Fix that horrible "jumping of links when I try to click them" behaviour of the page.
This reminds me of - https://www.youtube.com/watch?v=wJuXIq7OazQ
"There is not one section... it's just the vibe of the thing"
"I'm afraid Mr Denuto, you'll have to be more specific"
"There is not one section... it's just the vibe of the thing"
"I'm afraid Mr Denuto, you'll have to be more specific"
Maybe I'm the only one but I don't find this overview convincing.
It's totally stupid that this is not itself Open Source.
Otherwise, it's got potential and probably is better than GitHub's choosealicense thing
Otherwise, it's got potential and probably is better than GitHub's choosealicense thing
TLDR is actually older than choosealicense
Actually, I knew that, but I'd forgotten about it until now. My point still stands that it is otherwise better (it would be if it were Free/Libre/Open itself)
Seems to be missing a few, e.g. Apache 1.1.
Now, I just glanced at the thing, and the very first thing that annoys me is this: Why would you require an account for submissions? Or rather, why would you need to have any kind of user accounts mechanism at this site?
The second problem is that the combination of TLDR and legal. One should at least bother to skim through the license of a program they'll use. BSD/MIT are about 20 lines, and GPL3 is about 700 lines:
This website is unnecessary.
The second problem is that the combination of TLDR and legal. One should at least bother to skim through the license of a program they'll use. BSD/MIT are about 20 lines, and GPL3 is about 700 lines:
% find /usr/share/licenses/common/ -name '*.txt' | xargs wc -l
470 /usr/share/licenses/common/MPL/license.txt
193 /usr/share/licenses/common/PSF/license.txt
151 /usr/share/licenses/common/PerlArtistic/license.txt
165 /usr/share/licenses/common/LGPL3/license.txt
88 /usr/share/licenses/common/EPL/license.txt
377 /usr/share/licenses/common/CDDL/license.txt
76 /usr/share/licenses/common/W3C/license.txt
68 /usr/share/licenses/common/PHP/license.txt
201 /usr/share/licenses/common/Artistic2.0/license.txt
661 /usr/share/licenses/common/AGPL3/license.txt
339 /usr/share/licenses/common/GPL2/license.txt
55 /usr/share/licenses/common/RUBY/license.txt
63 /usr/share/licenses/common/CCPL/cc-by-sa-3.0.txt
61 /usr/share/licenses/common/CCPL/cc-by-nc-3.0.txt
12 /usr/share/licenses/common/CCPL/cc-readme.txt
58 /usr/share/licenses/common/CCPL/cc-by-nc-nd-3.0.txt
60 /usr/share/licenses/common/CCPL/cc-by-3.0.txt
63 /usr/share/licenses/common/CCPL/cc-by-nc-sa-3.0.txt
57 /usr/share/licenses/common/CCPL/cc-by-nd-3.0.txt
502 /usr/share/licenses/common/LGPL2.1/license.txt
202 /usr/share/licenses/common/Apache/license.txt
217 /usr/share/licenses/common/CPL/license.txt
397 /usr/share/licenses/common/FDL1.2/license.txt
416 /usr/share/licenses/common/LPPL/license.txt
674 /usr/share/licenses/common/GPL3/license.txt
54 /usr/share/licenses/common/ZPL/license.txt
451 /usr/share/licenses/common/FDL1.3/license.txt
6131 total
This website is unnecessary.
The uncountable flames on Web forums, the GPL FAQ, all the questions on the FSF IRC channel and so on are IMHO enough proof that licensing is complicated and people have trouble reading and understanding licenses. Correct & well laid out information about them is hard enough to find. I think a new website could help with that. It could also guide people in choosing a license for their code.
Having said that, in its current state tldrlegal isn't much help.
Having said that, in its current state tldrlegal isn't much help.
4 reasons:
1. It's hard work summarizing licenses. I'd like to give people a chance to get credited for their contributions to the community and be social about licenses.
2. A little harder to make bold/troll edits if all of them are moderated by both license submitters and admins on the site. Any information around legal things are very sensitive and impactful - although TLDR doesn't claim to be a law firm or provide legal advice, we still try our best to have good quality content.
3. Future ability to build tools for the community on this dataset, where data is attached to user accounts.
4. Easier way to understand how many people are participating and announce new, important features.
Finally, TLDR doesn't encourage you to ignore the license. It provides you an out before you delve in deep.
1. It's hard work summarizing licenses. I'd like to give people a chance to get credited for their contributions to the community and be social about licenses.
2. A little harder to make bold/troll edits if all of them are moderated by both license submitters and admins on the site. Any information around legal things are very sensitive and impactful - although TLDR doesn't claim to be a law firm or provide legal advice, we still try our best to have good quality content.
3. Future ability to build tools for the community on this dataset, where data is attached to user accounts.
4. Easier way to understand how many people are participating and announce new, important features.
Finally, TLDR doesn't encourage you to ignore the license. It provides you an out before you delve in deep.
This is even a shorter tl;dr: use MIT or Apache. Who would choose other licenses, more complicated, if they didn't mean to screw you later.
You could shorten that tl;dr by removing mention of the Apache license. Which is much longer and more complicated than the MIT license, and incompatible with GPLv2 (at least according to the FSF).
Yeah but Apache gives you an explicit grant to patent rights whereas MIT, although doesn't explicitly restrict it, doesn't grant it either.
This is awesome. There are a lot of things I love about this country, but one thing we've done bad is create lawyers. Where I live (DC) 1 in 12 people are lawyers.
I wish every legal document carried a tl;dr.
I wish every legal document carried a tl;dr.
If you don't like a life with lawyers, you'll be terrified about a life without them. The problem is not lawyers. It is that we* made them important.
* or they made themselves important, but whatever, the problem is not their nominal work.
* or they made themselves important, but whatever, the problem is not their nominal work.
America inherited its legalistic nature from England. Uncoincidentally, the U.S. and England are two of the most successful societies in the history of the world. :)
This sounds like a massive case of mixing correlation with causation.
Of course its difficult to separate correlation from causation on this subject. The best study I've seen on the matter (Magee, "The Optimum Number of Lawyers") doesn't try to detangle the correlation and the causation too much, though it does try to account for a number of other variables.
That said, its hard to ignore the track record of Anglo law. England was able to embrace a market economy earlier than its competitors in part due to its legalistic fixation on property rights. It had well developed legal structures suitable for bringing private money into the tasks of colonization and empire building. Its interesting to note that as China modernizes its economy, it is bringing over American legal experts to update its legal system.
That said, its hard to ignore the track record of Anglo law. England was able to embrace a market economy earlier than its competitors in part due to its legalistic fixation on property rights. It had well developed legal structures suitable for bringing private money into the tasks of colonization and empire building. Its interesting to note that as China modernizes its economy, it is bringing over American legal experts to update its legal system.
Okay, now you seem to be setting up a strawman.
Yes, legal frameworks that support things like property rights are important. The parent, however, was making a point about how the law has gotten overly complex over the decades, so much so that we now have an entire cadre of people whose sole job is to help others navigate that complexity.
It doesn't help that most legal documentation is written in bizarre, arcane language, as opposed to plain, spoken English.
Yes, legal frameworks that support things like property rights are important. The parent, however, was making a point about how the law has gotten overly complex over the decades, so much so that we now have an entire cadre of people whose sole job is to help others navigate that complexity.
It doesn't help that most legal documentation is written in bizarre, arcane language, as opposed to plain, spoken English.
It's not a straw man, because I'm not using "no law" and "no property rights" as the basis of comparison. Non-Anglo countries still had law and property rights. What Anglo countries had, and have, are very sophisticated legal systems and legalistic societies that leverage the legal system for more purposes. It's one thing for a farmer to be able to sue someone who takes his land. It's another for farmers to be able to hedge against bad harvests by entering into contracts and having the contracts traded as property rights on derivatives exchanges. The complexity and sophistication of Anglo legal systems readily support the complex and sophisticated corporate, financial, and insurance transactions that underly modern economies. It's not a coincidence that the world's three largest financial centers, New York, London, and Hong Kong, are all common law jurisdictions based on English common law.
And complaining that legal contracts are written in "bizarre, arcane language" seems to me to be like a high level manager complaining about programs being written in C++ or Javascript, instead of plain spoken English. After all, why do you need so many lines of this "code" when he just explained precisely everything the program should do in 15 minutes?
And complaining that legal contracts are written in "bizarre, arcane language" seems to me to be like a high level manager complaining about programs being written in C++ or Javascript, instead of plain spoken English. After all, why do you need so many lines of this "code" when he just explained precisely everything the program should do in 15 minutes?
>> What Anglo countries had, and have, are very sophisticated legal systems and legalistic societies that leverage the legal system for more purposes. It's one thing for a farmer to be able to sue someone who takes his land. It's another for farmers to be able to hedge against bad harvests by entering into contracts and having the contracts traded as property rights on derivatives exchanges.
I think of a country's legal system as a computer program. Anglo countries have been developing their program for a long time. Therefore, it can do a ton of different things, including allowing farmers to hedge against bad harvests in the manner you describe.
One problem is that, as programs get more sophisticated, they also become slower, and you end up needing to throw more resources at them to make them run at acceptable performance. This becomes an issue when not every user can afford those resources: what you end up with is some people running the program at state-of-the-art hardware (i.e. rich people who can afford expensive legal representation), and others running it on decades-old hardware (i.e. public defenders). When these groups are pitted against each other (e.g. in a lawsuit), one group dominates, either by using the threat of litigation to force the other side to do something or by winning the trial.
Complexity in programs also cause other problems. For example, as a program gets more complex, it becomes harder to maintain and debug. If you write new code, you have to make sure it won't conflict with any of the old functionality. It becomes harder to test, harder to bring new people up to speed, and harder to train users because there's just so much the program can do. The problem is that, while you can refactor a program's code, you can't necessarily refactor the legal system: it just gets more and more complex, with no end in sight.
>>And complaining that legal contracts are written in "bizarre, arcane language" seems to me to be like a high level manager complaining about programs being written in C++ or Javascript, instead of plain spoken English. After all, why do you need so many lines of this "code" when he just explained precisely everything the program should do in 15 minutes?
Programs are written in programming languages because that's what computers understand. If you wrote the program in plain spoken English, it would not run. However, user documentation of the program is written in plain spoken English because that's what the user speaks. The phrase, "To create a new account, click the 'Register' button," does not require the user to hire a specialized, highly-paid professional who will interpret it for him.
The law is like, or should be like, user documentation, because it is ultimately consumed by humans. Therefore it makes sense to write it in a language that most humans will understand. Right now though, it is written in the equivalent of a programming language, which is why we need lawyers to make it understandable. It really is ridiculous, if you think about it.
I think of a country's legal system as a computer program. Anglo countries have been developing their program for a long time. Therefore, it can do a ton of different things, including allowing farmers to hedge against bad harvests in the manner you describe.
One problem is that, as programs get more sophisticated, they also become slower, and you end up needing to throw more resources at them to make them run at acceptable performance. This becomes an issue when not every user can afford those resources: what you end up with is some people running the program at state-of-the-art hardware (i.e. rich people who can afford expensive legal representation), and others running it on decades-old hardware (i.e. public defenders). When these groups are pitted against each other (e.g. in a lawsuit), one group dominates, either by using the threat of litigation to force the other side to do something or by winning the trial.
Complexity in programs also cause other problems. For example, as a program gets more complex, it becomes harder to maintain and debug. If you write new code, you have to make sure it won't conflict with any of the old functionality. It becomes harder to test, harder to bring new people up to speed, and harder to train users because there's just so much the program can do. The problem is that, while you can refactor a program's code, you can't necessarily refactor the legal system: it just gets more and more complex, with no end in sight.
>>And complaining that legal contracts are written in "bizarre, arcane language" seems to me to be like a high level manager complaining about programs being written in C++ or Javascript, instead of plain spoken English. After all, why do you need so many lines of this "code" when he just explained precisely everything the program should do in 15 minutes?
Programs are written in programming languages because that's what computers understand. If you wrote the program in plain spoken English, it would not run. However, user documentation of the program is written in plain spoken English because that's what the user speaks. The phrase, "To create a new account, click the 'Register' button," does not require the user to hire a specialized, highly-paid professional who will interpret it for him.
The law is like, or should be like, user documentation, because it is ultimately consumed by humans. Therefore it makes sense to write it in a language that most humans will understand. Right now though, it is written in the equivalent of a programming language, which is why we need lawyers to make it understandable. It really is ridiculous, if you think about it.
> I think of a country's legal system as a computer program. Anglo countries have been developing their program for a long time. Therefore, it can do a ton of different things, including allowing farmers to hedge against bad harvests in the manner you describe.
Anglo legal systems aren't more sophisticated merely because they've been in development longer. It's that English society was legalistic and willing to readily embrace legal abstractions. Think of the conceptual leap from a traditional right to property (i.e. the legal system will keep someone from taking my land by force), to the Anglo notion of property (nearly any set of rights and obligations between parties can be wrapped into a contract that can be held and traded like property). The latter concept is tremendously enabling of markets, but it's not obvious. It was invented by a society that was totally comfortable thinking in legal abstractions, and that proved to be a competitive advantage.
> One problem is that, as programs get more sophisticated, they also become slower, and you end up needing to throw more resources at them to make them run at acceptable performance.
Let's analogize the legal system to a computer operating system. My phone runs Kit Kat, whose big feature is that it can "comfortably" support phones with as little as 512 MB of RAM. This is almost 10x as much RAM as I had in my high-end desktop computer some years ago (PII-era), which ran NT 4.0 just fine. Operating systems get slower and more complex every year, but nobody seems to really see that as enough of a reason to forgo the benefits of the complexity. Nobody cares about absolute overhead, but relative overhead. In the U.S., the legal sector's share of GDP has been steadily declining since the 1970's.
> The law is like, or should be like, user documentation, because it is ultimately consumed by humans.
Legal documents are much more like formal design specifications (http://en.wikipedia.org/wiki/Formal_specification) than user documentation. Legal documents are references against which disputes can be resolved. Nobody would use user documentation to resolve a dispute about, say, whether a feature was implemented properly--they'd look at the specification.
Anglo legal systems aren't more sophisticated merely because they've been in development longer. It's that English society was legalistic and willing to readily embrace legal abstractions. Think of the conceptual leap from a traditional right to property (i.e. the legal system will keep someone from taking my land by force), to the Anglo notion of property (nearly any set of rights and obligations between parties can be wrapped into a contract that can be held and traded like property). The latter concept is tremendously enabling of markets, but it's not obvious. It was invented by a society that was totally comfortable thinking in legal abstractions, and that proved to be a competitive advantage.
> One problem is that, as programs get more sophisticated, they also become slower, and you end up needing to throw more resources at them to make them run at acceptable performance.
Let's analogize the legal system to a computer operating system. My phone runs Kit Kat, whose big feature is that it can "comfortably" support phones with as little as 512 MB of RAM. This is almost 10x as much RAM as I had in my high-end desktop computer some years ago (PII-era), which ran NT 4.0 just fine. Operating systems get slower and more complex every year, but nobody seems to really see that as enough of a reason to forgo the benefits of the complexity. Nobody cares about absolute overhead, but relative overhead. In the U.S., the legal sector's share of GDP has been steadily declining since the 1970's.
> The law is like, or should be like, user documentation, because it is ultimately consumed by humans.
Legal documents are much more like formal design specifications (http://en.wikipedia.org/wiki/Formal_specification) than user documentation. Legal documents are references against which disputes can be resolved. Nobody would use user documentation to resolve a dispute about, say, whether a feature was implemented properly--they'd look at the specification.
>> Nobody cares about absolute overhead, but relative overhead. In the U.S., the legal sector's share of GDP has been steadily declining since the 1970's.
Yes, but you shouldn't look at relative overhead in terms of the legal sector's share of the GDP, because that doesn't tell you the whole story. What you need to look at is relative overhead in terms of the average person's ability to afford legal services. Essentially, it comes down to this: if people are able to use the threat of litigation to bully others because they know that lawsuits would be too expensive for those others, something is terribly, terribly wrong.
>>Nobody would use user documentation to resolve a dispute about, say, whether a feature was implemented properly--they'd look at the specification.
I'd say that if users cannot use the feature because they don't understand it, it doesn't matter whether it was implemented properly: it's a failed feature.
Essentially what we are asking people is to abide by the law, but making the law too complicated to understand by the average person. Do you honestly not see the problem with that? I read somewhere that everyone is a criminal because we just have too many laws and people break them all the time without realizing it.
Yes, but you shouldn't look at relative overhead in terms of the legal sector's share of the GDP, because that doesn't tell you the whole story. What you need to look at is relative overhead in terms of the average person's ability to afford legal services. Essentially, it comes down to this: if people are able to use the threat of litigation to bully others because they know that lawsuits would be too expensive for those others, something is terribly, terribly wrong.
>>Nobody would use user documentation to resolve a dispute about, say, whether a feature was implemented properly--they'd look at the specification.
I'd say that if users cannot use the feature because they don't understand it, it doesn't matter whether it was implemented properly: it's a failed feature.
Essentially what we are asking people is to abide by the law, but making the law too complicated to understand by the average person. Do you honestly not see the problem with that? I read somewhere that everyone is a criminal because we just have too many laws and people break them all the time without realizing it.
[deleted]
[deleted]
Citation needed.
"iTunes" has no results. So I searched "Apple Terms" like the autocomplete suggests, and get "Nothing summarized yet". No "Fulltext" for that one either. Why suggest it if you don't have it?
I also can't click the back button from "https://tldrlegal.com/license/apple-terms-of-service#changes..., it seems to send me right back to itself.
I also can't click the back button from "https://tldrlegal.com/license/apple-terms-of-service#changes..., it seems to send me right back to itself.
Hey, tldrlegal creator here. Glad to see feedback popping on HN again! Here's some answers:
1. You're totally right about ToS. Tldrlegal was just code and OSS licenses for a while -- I just added terms of service and the apple tos today. They're in the autocomplete to just feature both types but you're right -- it's irresponsible to suggest that before it's ready.
2. The back button issue is just a redirect one from the js routing on that page. The reason is because it defaults to the first tab link, which is kept as an anchor for js-disabled loaders.
Thanks for the notes!
1. You're totally right about ToS. Tldrlegal was just code and OSS licenses for a while -- I just added terms of service and the apple tos today. They're in the autocomplete to just feature both types but you're right -- it's irresponsible to suggest that before it's ready.
2. The back button issue is just a redirect one from the js routing on that page. The reason is because it defaults to the first tab link, which is kept as an anchor for js-disabled loaders.
Thanks for the notes!
It's not just suggested as autocomplete, it's actually given as an example of a search on the front page, just FYI.
Please don't just duplicate work that is already being done. Partner with http://tosdr.org/ instead
These are kids building this product in Silicon Valley.
I'm surprised there isn't more work done already -- this industry is notorious for having operating inefficiencies.
But hey, that's what a free market is, right? Let the market decide which competitor is best. These guys are funded and need to generate that return, right?
I'm surprised there isn't more work done already -- this industry is notorious for having operating inefficiencies.
But hey, that's what a free market is, right? Let the market decide which competitor is best. These guys are funded and need to generate that return, right?
(ToS;DR project lead here)
We’re a not-for-profit. And all our code is at https://github.com/tosdr/
I’m all fine to see other projects tackling the issue. But I’m not a big fan of closed-source services that exploit people’s participation.
(Or maybe I completely miss the source code to tldrlegal.com, in such case I apologize! But then, don’t hide it ;-))
We’re a not-for-profit. And all our code is at https://github.com/tosdr/
I’m all fine to see other projects tackling the issue. But I’m not a big fan of closed-source services that exploit people’s participation.
(Or maybe I completely miss the source code to tldrlegal.com, in such case I apologize! But then, don’t hide it ;-))
I was talking about the tl;dr guys :P
I met a lawyer at LinuxCon Europe last year. One thing interesting she said was that of all the other professions, a software developer was the closest to actually understanding legalese. That's because devs understand if-then-else, switch-case, variables etc.. That's exactly what the legal language style is.
Whereas, said party....
Whereas, said party....
They may be good at parsing the syntax of legal text, but in my experience software people are worse than "typical" people at understanding the meaning. My hypothesis is that programming gets them used to thinking about things in absolute terms, and they cannot deal with the fuzziness inherent in law.
This is partially because developers have a cultural quirk where they believe that, e.g., "file sharing is not theft"/"manipulating a URL can't be a crime"/"laws about disclosing protected information invariably contain a public policy exception which comports to the temperament of the dev community" are axiomatic and thereby create an internally consistent legal system which fails to falsify those axioms but also fails to meaningfully resemble the legal system we actually operate in. This results in developers sincerely believe things like "Your Bitcoins are unprotected by the legal system because nobody can steal a number", which is a proposition that is absurd to the legal system as "JavaScript is not a programming language" is to a programmer.
developers have a cultural quirk where they believe that, e.g., "file sharing is not theft"
Yeah. Thankfully, the SCOTUS shares our cultural quirk, as Dowling v. United States showed.
Yeah. Thankfully, the SCOTUS shares our cultural quirk, as Dowling v. United States showed.
This was a ruling in 1985 based on physical theft laws being applied to copyright. <s>It also never made it to the Supreme Court.</s> (edited -- sorry misread this part)
Since then, many other laws have been passed, and it's likely that SCOTUS would apply those rather than using this case as a precedent. They didn't make a sweeping judgement about the meaning of copyright -- only declared that a laws about theft did not apply to copyright. Specific Copyright laws passed after 1985 would probably still apply.
http://en.wikipedia.org/wiki/Dowling_v._United_States_(1985)
Since then, many other laws have been passed, and it's likely that SCOTUS would apply those rather than using this case as a precedent. They didn't make a sweeping judgement about the meaning of copyright -- only declared that a laws about theft did not apply to copyright. Specific Copyright laws passed after 1985 would probably still apply.
http://en.wikipedia.org/wiki/Dowling_v._United_States_(1985)
I think the problem though is that while legalese is hyper-defined, it is also formulaic and still defined by usage rather than specification. Software development has been less helpful for me to read legalese than reading philology textbooks.
I wish Law would be completely expressed in a logical language. If that were true all interpretation would be automatically handled by computers and software tools would help non-lawyers avoiding the cost of lawyers.
Well, law used parts of object orientation well before we started using it. http://en.wikipedia.org/wiki/Lex_specialis
I saw this linked somewhere else months ago and keep forgetting about it. Extremely useful if you really don't want to read through a large license file to see if you can use a library in a project or not.
I noticed that the BSD 2 has a 'CANNOT' group that says:
> Hold Liable
> Describes the warranty and if the software/license owner can be charged for damages.
which reads awkwardly.
It's like someone was describing the category "Hold Liable" instead of what the BSD2 license says about liability. Most of the descriptions have this problem. Something like "The software/license owner can't be charged for damages or shortcomings." might flow better, though that implies having descriptions for both the positive and negative case.
edit Oh, normally the descriptions are hidden (with scripts enabled). So it's as if I asked "what is it?" by clicking and the description is the answer. That makes more sense.
> Hold Liable
> Describes the warranty and if the software/license owner can be charged for damages.
which reads awkwardly.
It's like someone was describing the category "Hold Liable" instead of what the BSD2 license says about liability. Most of the descriptions have this problem. Something like "The software/license owner can't be charged for damages or shortcomings." might flow better, though that implies having descriptions for both the positive and negative case.
edit Oh, normally the descriptions are hidden (with scripts enabled). So it's as if I asked "what is it?" by clicking and the description is the answer. That makes more sense.
You can suggest changes to any page! Just hot the edit button after you login!
Great domain! See what we did here, where every paragraph is summarized in human readable English.:
http://aviary.com/legal/terms
I do think offering this as a service for most companies would be a very useful (if small) business.
I do think offering this as a service for most companies would be a very useful (if small) business.
I really wonder whenever it's possible to write TOS/EULA/alike without the legalese part, just with plain simple wording and human-friendly style. Had any lawyer experimented with that, or that's just not possible?
It's probably possible, but trials are decided on the letter of the law, not the spirit. It's easier for a lawyer to write in legalese then stress about making human readable words cover all the scenarios legalese was intended to cover.
I wish the Apache License was more popular. It's in the same spirit as the MIT License, but it provides more protections regarding patents, for example. This prevents the "bait and switch" method of licensing a work under a permissive license but restricting it under patent law.
But it can't be used by software that chose BSD, MIT, MPL, LGPLv2.1, GPLv2, or other common licenses. This is fairly benign for an end-user application, but it's a restrictive choice for libraries.
This is a handy chart: http://www.dwheeler.com/essays/floss-license-slide.html
This is a handy chart: http://www.dwheeler.com/essays/floss-license-slide.html
Apache is compatible with every one of those licenses except gplv2-only.
Section 4 of the apache license says: "You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole" - https://www.apache.org/licenses/LICENSE-2.0.html
It can't be relicensed, but people has argued that you can't do that with BSD or other permissive licenses. You can't take BSD code and make it MIT, which restricts a MIT project if they want to only use the MIT license.
Section 4 of the apache license says: "You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole" - https://www.apache.org/licenses/LICENSE-2.0.html
It can't be relicensed, but people has argued that you can't do that with BSD or other permissive licenses. You can't take BSD code and make it MIT, which restricts a MIT project if they want to only use the MIT license.
I don't interpret that to mean that you can violate the terms of the Apache license, but rather that modifications or derivative work can bear a different license. Every user is still bound by the terms of the Apache license, including the patent indemnification clause which does not appear in those other licenses. If you disagree, could you point me to a legal opinion? Note that OpenBSD still ships Apache 1.3 because they believe Apache 2.0 is incompatible.
http://monkey.org/openbsd/archive/misc/0402/msg01095.html
http://monkey.org/openbsd/archive/misc/0402/msg01095.html
Of course you can not violate the terms of the Apache license. Similar to BSD code in a MIT project, you need to follow the original license in order to be in compliance.
David Wheeler arrows indicate that two licenses may be combined, and that the combined work can effectively be treated as having the license at the end of the arrow. If you pull BSD licensed code into MIT, you have to follow the BSD license and include a BSD copyright notice.
more: https://stackoverflow.com/questions/10903720/new-bsd-license... http://www.epractice.eu/files/11-04-07_PhL_FLOSS_Licences_Co...
David Wheeler arrows indicate that two licenses may be combined, and that the combined work can effectively be treated as having the license at the end of the arrow. If you pull BSD licensed code into MIT, you have to follow the BSD license and include a BSD copyright notice.
more: https://stackoverflow.com/questions/10903720/new-bsd-license... http://www.epractice.eu/files/11-04-07_PhL_FLOSS_Licences_Co...
> I wish the Apache License was more popular.
In Java world it can hardly be more popular.
In Java world it can hardly be more popular.
Ugh Apache. What you are looking for is this: http://coil.apotheon.org/
Looks promising. Not sure what I think of the concept of a 'Manager' (user who was the original submitter) being the only one to approve changes, seems a bit odd considering the rest of the community aspect.
A similar site, tosdr.org, was launched a couple years back to help filter through website TOS. It lacks a community editable system, and even with various publicity and funding still has a limited set of sites in their index.
Hopefully this new site can gain more traction and continue to develop.
A similar site, tosdr.org, was launched a couple years back to help filter through website TOS. It lacks a community editable system, and even with various publicity and funding still has a limited set of sites in their index.
Hopefully this new site can gain more traction and continue to develop.
Yeah, TLDRLegal is actually older than ToS;DR, and I noticed that the community there kinda stagnated because editing was so difficult. I don't know what happened to them after they got their 10k from indiegogo, but I think they're still around. The idea of "managers" is to keep an authority reviewing the content since legal info is sensitive and can be very impactful to people, but TLDR admins can always transfer management from one person to another.
Interesting point about mangers being an authoritative source, but if the manger is just the first user isn't that a bit arbitrary?
Good luck anyway!
Good luck anyway!
Cool site! I really appreciate this information, you did a great job.
I just wanted to remark on a few UI bits that drove me nuts:
1. The social links. Not only are they not necessary, but there appears to be a bug with the Facebook widget (Chrome 35, OSX) that causes it to be about 1000px tall and invisibly cover the entire "Newest" column, making all of them unclickable.
2. The expansion of the 'rules' sections on hover. Not only is that information not really useful in that format (tiny text, difficult to read, too terse to be useful), the expansion makes it difficult to click on what you want. It may be best to either omit them or leave them expanded by default.
Thanks for a useful site!
I just wanted to remark on a few UI bits that drove me nuts:
1. The social links. Not only are they not necessary, but there appears to be a bug with the Facebook widget (Chrome 35, OSX) that causes it to be about 1000px tall and invisibly cover the entire "Newest" column, making all of them unclickable.
2. The expansion of the 'rules' sections on hover. Not only is that information not really useful in that format (tiny text, difficult to read, too terse to be useful), the expansion makes it difficult to click on what you want. It may be best to either omit them or leave them expanded by default.
Thanks for a useful site!
Thanks for the feedback, I actually really agree with the rules comment. The old browse ui had these click filters on rules like 'commercial use' that let you filter on licenses based on rules. The new ui had to retire that for a bit, but i had requests to keep the rules at least which was easy enough to do. Unfortunately it's difficult to leave them a open as it drastically skews how the columns are aligned. I'll keep brainstorming.
Minor nitpick: `i.e.` should be `e.g.` in this case (for the search field's hint).
I'm surprised there is no entry for ODbl -- https://tldrlegal.com/search?q=odbl
It is an interesting project and likely useful.
At the same time, I wonder how clear the descriptions are, particularly of the permissive licenses (this is a critique, not a teardown). I looked at the FreeBSD and MIT licenses because of the fact that there is a subtle difference in the licenses which can cause some confusion: the MIT license explicitly allows sublicensing while the BSD licenses do not.
The descriptions were good. The MIT description was exactly the way I read the license text. The 2-clause BSD/FreeBSD license said "you can do almost anything" which immediately raises the question of "what can't you do?" My reading of the license is that the answer is "sublicense" (i.e. you can include the work in product of a different license, but you cannot change the license on the BSD code in the process of transmitting it, and that this limitation does not exist in the MIT license, were you can not only change the license but likely assert status as licensor when you do so). IANAL, but this is the sense I get from Larry Rosen's book ont he subject.
Again, I don't know that licenses can be perfectly explained in plain English, so this is a fairly minor concern if the site exists primarily as a conversation starter rather than something that people want to use as some sort of authoritative reference.
At the same time, I wonder how clear the descriptions are, particularly of the permissive licenses (this is a critique, not a teardown). I looked at the FreeBSD and MIT licenses because of the fact that there is a subtle difference in the licenses which can cause some confusion: the MIT license explicitly allows sublicensing while the BSD licenses do not.
The descriptions were good. The MIT description was exactly the way I read the license text. The 2-clause BSD/FreeBSD license said "you can do almost anything" which immediately raises the question of "what can't you do?" My reading of the license is that the answer is "sublicense" (i.e. you can include the work in product of a different license, but you cannot change the license on the BSD code in the process of transmitting it, and that this limitation does not exist in the MIT license, were you can not only change the license but likely assert status as licensor when you do so). IANAL, but this is the sense I get from Larry Rosen's book ont he subject.
Again, I don't know that licenses can be perfectly explained in plain English, so this is a fairly minor concern if the site exists primarily as a conversation starter rather than something that people want to use as some sort of authoritative reference.
I have to take issue with TldrLegal’s summary of the ISC license: https://tldrlegal.com/license/-isc-license
It starts out with, “The ISC license is not very well regarded because it has an “and/or” wording that makes it (debatably) legally vague.” Um, really? There is only one person who thinks that: rms. The ISC license isn’t the most popular permissive license, but it is reasonably common, being used by several large organizations (like, well, the ISC), and of course by a number of people for personal projects.
So aside from it not being copyleft, why _does_ rms (and thus the FSF licenses page) dislike the ISC license? Well, the ISC and Pine licenses both contain the following wording:
“Permission to use, copy, modify, and distribute this software… is hereby granted…”
University of Washington apparently tried to claim that this disallowed distribution of modified versions of Pine. Of course, that interpretation is completely ridiculous, as evidenced by 1) the reaction on debian-legal https://lists.debian.org/debian-legal/2002/11/msg00138.html and 2) the large number of people who use the license to this day.
But because _one_ copyright holder interpreted those words in a way that nobody else does, the FSF has claimed ever since that any license using such wording is dangerous (not nonfree, just dangerous). Which is silly. Anyone can misinterpret a license—I have seen several people release code under the GPL and then try to claim that prevents commercial redistribution. Would the FSF list that as a reason not to use the GPL? Of course not.
Anyway, the thing that bothered me the most about the TldrLegal entry was the statement that it’s “not very well regarded.” More accurate would be to say “not well regarded _by the FSF_”, but even that wouldn’t paint the whole picture because it doesn’t account for organizations like OpenBSD or ISC who actively prefer it.
By the way, here’s some interesting reading from Paul Vixie about the history of the ISC license: https://groups.google.com/forum/#!msg/comp.protocols.dns.bin... In response to the noise made by the FSF, the ISC changed the “and” to “and/or,” though of course that didn’t change the FSF’s mind at all. OpenBSD still uses the “and” wording.
It starts out with, “The ISC license is not very well regarded because it has an “and/or” wording that makes it (debatably) legally vague.” Um, really? There is only one person who thinks that: rms. The ISC license isn’t the most popular permissive license, but it is reasonably common, being used by several large organizations (like, well, the ISC), and of course by a number of people for personal projects.
So aside from it not being copyleft, why _does_ rms (and thus the FSF licenses page) dislike the ISC license? Well, the ISC and Pine licenses both contain the following wording:
“Permission to use, copy, modify, and distribute this software… is hereby granted…”
University of Washington apparently tried to claim that this disallowed distribution of modified versions of Pine. Of course, that interpretation is completely ridiculous, as evidenced by 1) the reaction on debian-legal https://lists.debian.org/debian-legal/2002/11/msg00138.html and 2) the large number of people who use the license to this day.
But because _one_ copyright holder interpreted those words in a way that nobody else does, the FSF has claimed ever since that any license using such wording is dangerous (not nonfree, just dangerous). Which is silly. Anyone can misinterpret a license—I have seen several people release code under the GPL and then try to claim that prevents commercial redistribution. Would the FSF list that as a reason not to use the GPL? Of course not.
Anyway, the thing that bothered me the most about the TldrLegal entry was the statement that it’s “not very well regarded.” More accurate would be to say “not well regarded _by the FSF_”, but even that wouldn’t paint the whole picture because it doesn’t account for organizations like OpenBSD or ISC who actively prefer it.
By the way, here’s some interesting reading from Paul Vixie about the history of the ISC license: https://groups.google.com/forum/#!msg/comp.protocols.dns.bin... In response to the noise made by the FSF, the ISC changed the “and” to “and/or,” though of course that didn’t change the FSF’s mind at all. OpenBSD still uses the “and” wording.
> “not well regarded _by the FSF_”,
This is a slight misrepresentation. FSF explicit says that there's no reason to avoid software released under ISC license, but recommend developers to use the very similar Expat License and FreeBSD License in order to make University of Washington argument moot (https://www.gnu.org/licenses/license-list.html#ISC).
If FSF intended to call it "dangerous", they would have written that instead. see for example the section about Utah Public License.
> In response to the noise made by the FSF, the ISC changed the “and” to “and/or,” though of course that didn’t change the FSF’s mind at all.
I think you got your history wrong there. Before accepting the license as a free software license, the Free Software Foundation asked for clarification of the text. In July 2007, as a result, "and distribute" was changed to "and/or distribute", after which the license was accepted (see https://en.wikipedia.org/wiki/ISC_license).
This is a slight misrepresentation. FSF explicit says that there's no reason to avoid software released under ISC license, but recommend developers to use the very similar Expat License and FreeBSD License in order to make University of Washington argument moot (https://www.gnu.org/licenses/license-list.html#ISC).
If FSF intended to call it "dangerous", they would have written that instead. see for example the section about Utah Public License.
> In response to the noise made by the FSF, the ISC changed the “and” to “and/or,” though of course that didn’t change the FSF’s mind at all.
I think you got your history wrong there. Before accepting the license as a free software license, the Free Software Foundation asked for clarification of the text. In July 2007, as a result, "and distribute" was changed to "and/or distribute", after which the license was accepted (see https://en.wikipedia.org/wiki/ISC_license).
Tldrlegal creator here. Good points, your depth of understanding on this license has really illuminated on how lacking or misleading the current summary can be. Do you think you can suggest some alternative working using the edit button on the site? I will merge your changes in ASAP.
Check out EULAlyzer as well:
https://www.brightfort.com/eulalyzer.html
https://www.brightfort.com/eulalyzer.html
This seems quite nice. Two things I'd love to see, which would make it even more handy:
- I'd love to see each license that has a standard SPDX identifier (https://spdx.org/licenses/) include that identifier as metadata in its tldrlegal record. (And ideally tldrlegal.com should have a standard URL to reach the one-and-only license corresponding to a given SPDX identifier.)
- I'd love to see standardized tags for OSI-compliant Open Source licenses, GNU-approved Free Software licenses, GPLv2-compatible licenses, and GPLv3-compatible licenses. (For the latter two, it'd be interesting to have a generalized tagging mechanism for saying "compatible with (other license record)", but in practice those are the two cases that matter most, and too much generality might not be a good thing.)
Also, this site seems to be doing something with icon fonts that doesn't work: I see missing-character glyphs for characters F098 and F099 where Facebook and Twitter icons should appear, and an "fl" ligature where a search button should appear. (Firefox 27 on Linux, in case that matters.)
I also don't see the placeholders on the username, email, and password fields in the form that pops up when clicking the "Sign Up" link; the placeholders in the form on the front page do appear. (Consider using real labels rather than placeholders for forms like that, to make them more accessible.)
- I'd love to see each license that has a standard SPDX identifier (https://spdx.org/licenses/) include that identifier as metadata in its tldrlegal record. (And ideally tldrlegal.com should have a standard URL to reach the one-and-only license corresponding to a given SPDX identifier.)
- I'd love to see standardized tags for OSI-compliant Open Source licenses, GNU-approved Free Software licenses, GPLv2-compatible licenses, and GPLv3-compatible licenses. (For the latter two, it'd be interesting to have a generalized tagging mechanism for saying "compatible with (other license record)", but in practice those are the two cases that matter most, and too much generality might not be a good thing.)
Also, this site seems to be doing something with icon fonts that doesn't work: I see missing-character glyphs for characters F098 and F099 where Facebook and Twitter icons should appear, and an "fl" ligature where a search button should appear. (Firefox 27 on Linux, in case that matters.)
I also don't see the placeholders on the username, email, and password fields in the form that pops up when clicking the "Sign Up" link; the placeholders in the form on the front page do appear. (Consider using real labels rather than placeholders for forms like that, to make them more accessible.)
The Firefox issue is a classic indicator that the site would work in Firefox with one additional step and the creators didn't bother checking.
In this case: Firefox expects CORS to load fonts from a different domain, e.g. CloudFront.
https://coderwall.com/p/ub8zug
The other classic is that Firefox expects fonts to be served with the correct mine-type.
In this case: Firefox expects CORS to load fonts from a different domain, e.g. CloudFront.
https://coderwall.com/p/ub8zug
The other classic is that Firefox expects fonts to be served with the correct mine-type.
what is the best license where you maintain the brand name of the open source software, and allow end user to modify it according to their needs but not release it under a different brand name OR use it to run commercial services off the software (that will require commercial license) ?
Do you really want people releasing code under your brand?
In any case, a license with such restrictions is considered non-free, so you won't find them on the OSI or FSF. There's CC-BY-NC, but they don't recommend applying it to software. I don't know if there's any other freely usable license with such terms, you may need to pay a lawyer to write you one. Or you could ask, say, the MAME developers if they license you theirs: http://mamedev.org/legal.html
In any case, a license with such restrictions is considered non-free, so you won't find them on the OSI or FSF. There's CC-BY-NC, but they don't recommend applying it to software. I don't know if there's any other freely usable license with such terms, you may need to pay a lawyer to write you one. Or you could ask, say, the MAME developers if they license you theirs: http://mamedev.org/legal.html
Very useful.
Hey guys, tldrlegal creator here. Just a quick note -- I am really glad to see discussions about license interpretations here, this is exactly what I hoped for when I first started the project. As a reminder on tldrlegal you can give feedback using the black tab on the right and also suggest a change to any license page by editing it when you're signed in! My biggest goal is to make sure content on tldr is of the highest quality and I'm really grateful that you guys are taking the time to critique and raise questions about the ways things have been summarized. Many of the summaries are outdated, and the best way for you guys to get your thoughts integrated is to use the editing features on the site!
Tldr - you can edit license content on the site!
Are there any actual lawyers behind this project? Or is it yet another site where every other guy from the Internet who thinks he knows what some license means decides to tell everyone else about it?
> Or is it yet another site where every other guy from the Internet who thinks he knows what some license means decides to tell everyone else about it?
Anybody can edit the license summary and attributes, so it's literally "every other guy from the internet"
Anybody can edit the license summary and attributes, so it's literally "every other guy from the internet"
So it's a lot like the following comment which I grabbed from somewhere on the Interweb:
"Wikipedia is the best thing ever. Anyone in the world can write anything they want about any subject, so you know you are getting the best possible information." - Michael Scott
"Wikipedia is the best thing ever. Anyone in the world can write anything they want about any subject, so you know you are getting the best possible information." - Michael Scott
Well I didn't try that, but other comments here say that you may suggest changes which then must be approved by a manager.
But even if anyone could post and edit content without any approval process, the content could still be heavily moderated after the fact.
So my question still stands.
But even if anyone could post and edit content without any approval process, the content could still be heavily moderated after the fact.
So my question still stands.
Could you keep the badges expanded instead of on hover? It would make for easier comparison.
I defer to the IT / Digital Legal Companion, by Gene K. Landy, an actual lawyer:
"The Myth of the Two-Page Contract
... Many times a client has brought us a complex multiyear distribution deal and wanted a 'simple two-page agreement.' Sometimes, they even ask for a one-page deal! The ostensible goal is to cut down negotiation time. But for most negotiated deals, it is a myth that adequate contracts can be short in this way. If the lawyer tries to comply (and we have tried), the result will almost always be to make the deal ambiguous. ... Managing complex deals full of contingencies with as imprecise a tool as the English language is tough enough; it is not prudent to try (or force your lawyer to try) to make agreements more risky than they have to be."
The sentiment could not be more clear: all that legalese is in the agreement for a reason. "Simplifying" licenses into bullet points does not adequately capture their content, and it is a huge UI fail to make people think that it does.
Let's start with the site's treatment of GPLv3. You get a few bullet point labels about e.g. source code disclosure plus a three-sentence summary. "GPL v3 tries to close some loopholes in GPL v2." Oh, really, what are those loopholes? No discussion of code signing, patent rights, affero vs. non-affero, among many other issues.
Even the bullet points themselves do not adequately capture nuance. That the GPLv3 allows commercial use is technically true, hence the label "commercial use". However, what isn't mentioned is the fact that the GPLv3 separately prohibits practically every known business model for profiting from software.
These ambiguities are not minor issues; they are fundamental. Let's not wrongly give people the idea that complex licenses can be summed up with a few bullet points, any more than our technical work can be summed up with a few crappy analogies!