undefined | Better HN

0 pointsDannyBee14y ago0 comments

Even in that case, he's trying to classify 1000+ open source licenses into 4 categories, which doesn't really work out well without a dictator.

People have different views on what "permissive" is. Even if you told people what they should choose for each license, they will still choose what their ideology says is right about the license.

IE plenty of people will choose "permissive" for GPL.

I've spent an inordinate amount of time classifying licenses into ~4 categories for compliance at Google, so i know where this path leads :) In my case, I can end discussions by fiat and say "this is how it's going to be". When you have 1000+ different project owners who each get to make their own decision, the field will become useless because you won't be able to tell what it really means.

0 comments

5 comments · 1 top-level

madrobby14y ago· 4 in thread

It's actually really simple:

"Permissive": anything that is generally MIT/BSD/WTF/Apache 2.0

"Restrictive": anything that is GPL or requires you to pay for or share all sources

Given that the vast majority of software use only one of a handful of licenses, I think that's a non-issue (tho there may be edge cases, I agree with that). For stuff that is not categorized, people can just put in "other".

(Do you have a list of those classifications btw, that would be useful.)

In general, a setting like this would likely raise awareness of people sharing code that they should choose a license in the first place. Far too many useful pieces of code on GitHub don't come with a license or copyright statement at all.

DannyBeeOP14y ago

Okay, so let's start simple: Where does LGPL fit into these two? (LGPL is in the top 5 licenses, so it's important)

So, vast majority depends on how you look at it.

If you are talking about organized software projects, yes, the vast majority use about 20 licenses (I cut off the count at 90%)

If you are talking about code that is out there and has a license marking, "Other" is the #3 category, and we classify over 1000 licenses. (I hand check a lot of these, and only about 1% are classification errors, not really licensed, or munged).

So as you can see, the story is not great, particularly for people who want to just take pieces of code.

Don't get me wrong, I absolutely and completely agree that things should be marked with licenses and give people some idea of what they can do. I'm just saying doing it usefully is not as simple as giving people 2-4 categories and saying "have at it!"

As for the categories we have, our categories are based on what would be required if the source is used in a product shipping outside of Google. The categories have been mentioned publicly before, so i'll mention that they are "notice", "reciprocal", "restricted", and "use by exception only" (IE you can only use it if you talk to us first)

mindcrime14y ago

Right, and likewise for the MPL, which is a sort of copyleft license, but is generally considered "weak copyleft" unlike the GPL, which is "strong copyleft."[1]

[1]: http://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyle...

gte910h14y ago

Restrictive is primarily the case because they don't allowed DRM binaries to be used. The LGPL doesn't have that flaw.

You can't use GPLed code on Apple, Nintendo, Sony or Microsoft gaming platforms due to the binary copy restriction.

metamattl14y ago

> "Restrictive": anything that is GPL or requires you to pay for or share all sources

Paying for sources, sounds an awful lot like proprietary software. Pay for binaries, sure... sources shouldn't be withheld and should be available for a nominal fee, which in the case of GitHub and others, is $0.

j / k navigate · click thread line to collapse