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

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.