3 ms·

I hate to be a party pooper, but I think this site is completely naïve from a legal perspective, and actually harmful. There are many ambiguities not covered by

by wes-exp 13y ago

I hate to be a party pooper, but I think this site is completely naïve from a legal perspective, and actually harmful. There are many ambiguities not covered by simple bullet point descriptions. Ask yourself, why are licenses long in the first place? 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!

clarry 13y ago
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.
XiZhao 13y ago
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).

by wes-exp 13y ago

clarry 13y ago

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.

XiZhao 13y ago

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