Live data from Hacker News

Why I’d like a “license type” setting for GitHub projects

mir.aculo.us

31–40 of 138 posts

Re: Why I’d like a “license type” setting for GitHub projects

#31
post #8

I think having a hard-coded drop down for actual licenses is a good idea, because then we can do the searching and filtering you suggest. I don't like grouping them into 'types'. I think that's too much of a value judgement. Any enterprise's legal department is going to approve or disapprove of specific licenses, so that's what developers like me will be looking for. Potential issues: * Modified licenses (eg: JSLint'…

A list of every type if license can't work, because it needs to be constantly updated and people may want to write their own, etc. That's why the general type makes much more sense for a quick glimpse if some code is probably suitable license-wise for your project.

You're against the GPL, but you're okay with people writing their own new licenses?

Re: Why I’d like a “license type” setting for GitHub projects

#32

Earlier quoted context omitted.

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 am…

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…

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)

Re: Why I’d like a “license type” setting for GitHub projects

#33
post #29

The unnecessary editorializing is annoying. The point, which I agree with, could have been made without the self-centered snipes at licenses you happen to dislike.

It's my blog, the concept of which is that I write my opinion in blog posts.

Re: Why I’d like a “license type” setting for GitHub projects

#34
post #21

Earlier quoted context omitted.

As a guy who sends these notes, the response rate drops very quickly if the project hasn't been touched in the past year, and this is not uncommon. So you end up with a lot of badly marked or unmarked open source, which isn't great.

The license/copying file that is actually distributed with the code still is what you have to go by. Without license information you MUST assume full copyright sadly.

I agree. Sadly, we also run into plenty of cases distributing LICENSE files that don't match file headers, etc.

Re: Why I’d like a “license type” setting for GitHub projects

#35
post #2

And when the drop-down disagrees with the COPYING or LICENSE file...?

One obvious solution is for github to autodetect the license if a LICENSE file is present. This will work in most cases, most people just copy&paste one of a small set of licenses.

Re: Why I’d like a “license type” setting for GitHub projects

#37
post #29

The unnecessary editorializing is annoying. The point, which I agree with, could have been made without the self-centered snipes at licenses you happen to dislike.

It's my blog, the concept of which is that I write my opinion in blog posts.

This is my reply box, the concept of which is that I discuss what I like or don't like about the topic at hand.

Re: Why I’d like a “license type” setting for GitHub projects

#38
GitHub already parses README files of various formats. I wonder how hard it would be to just parse a LICENSE/COPYRIGHT file if it's available. This would make sure the licenses are distributed with the code. If the license file couldn't be parsed, a "Custom License" link to the corresponding license file could be a good general fallback too.

Re: Why I’d like a “license type” setting for GitHub projects

#39
post #37

Earlier quoted context omitted.

It's my blog, the concept of which is that I write my opinion in blog posts.

This is my reply box, the concept of which is that I discuss what I like or don't like about the topic at hand.

Pissing contest?

Re: Why I’d like a “license type” setting for GitHub projects

#40
post #25
post #19

Earlier quoted context omitted.

Have you considered emailing the author? I know that personally, I've relicensed code to be more permissive on request. Of course, you have to ask, but sending an email might be less work than writing your own version.

Does it make you more vulnerable to law suits if the author says no and you decide to code/acquire something similar?

Honestly, I don't know. I'd suppose it depends more on the sort of thing we're talking about than anything. If it's something like "Obtvse", or a fully formed system and you're copying it outwardly, then probably yes.

If it's a ilbrary that fetches RSS feeds as part of a larger system, I'm guessing no.

Of course, it also depends significantly on the author. If it's a public git repository, one assumes that it's something people wish to be forked.

Though I suppose an interesting experiment would be to publicly post closed source code with a closed source license attached as honeypots and sue everyone that forks / modifies your code base.

Post reply on HN