- 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.)

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.

Thanks for taking note.

Whereas, said party....

Yeah. Thankfully, the SCOTUS shares our cultural quirk, as Dowling v. United States showed.

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)

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 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.

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!

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?

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 ;-))

This is a handy chart: http://www.dwheeler.com/essays/floss-license-slide.html

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.

http://monkey.org/openbsd/archive/misc/0402/msg01095.html

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...

In Java world it can hardly be more popular.

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.

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).

Corollary: Nominalism hard at work...

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 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!

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.

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.

Good luck anyway!

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

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.

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?

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.

See http://freedomdefined.org/Licenses/NC

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.

> 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.

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.

Anybody can edit the license summary and attributes, so it's literally "every other guy from the internet"

"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

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.

I wish every legal document carried a tl;dr.

* or they made themselves important, but whatever, the problem is not their nominal work.

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.

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.

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?

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.

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.

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.

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.

I do think offering this as a service for most companies would be a very useful (if small) business.

"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"

Otherwise, it's got potential and probably is better than GitHub's choosealicense thing

https://www.brightfort.com/eulalyzer.html

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.

Having said that, in its current state tldrlegal isn't much help.

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.

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