Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mir.aculo.us

Post reply on HN
Print view View original

21–30 of 138 posts

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

#21

Post by rubyruy »

DannyBee wrote: post #12
Manfred wrote: post #4

Earlier quoted context omitted.

Then you send a quick note to the owner of the repository to ask him what's up.

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.

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

#22

Post by metamattl »

madrobby wrote: post #10
mindcrime wrote: post #5

For "GPL type" licenses, it would probably be better to use the term "copyleft" rather than "restrictive" since their copyleft nature is really what's particular about them. That said, I'd almost prefer a setting that lets you specify the exact license. The problem is, what do you do about dual/multi licensed projects, or projects which contain code that's under a mixture of licenses? I suppose you could argue that i…

Many people don't know what "copyleft" is, so "restrictive" makes more sense. There are more restrictions. For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.

Even if "restrictive" is misleading?

Copyleft licenses really don't seem to be a problem unless you're trying to make something proprietary?

Unless I'm missing some other restriction...

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

#23

Post by metamattl »

huskyr wrote: post #17

I was actually rather surprised when switching from Google Code to Github that they didn't have a license option. Especially if you need code for a business licenses are pretty crucial. I don't like this idea however. It's too general. I would make the license an input field with autosuggest with 10 or so of the most popular licenses (like Google Code). If you have something funky you can still enter it.

The FSF has a pretty decent list of licenses -- http://www.gnu.org/licenses/license-list.html#SoftwareLicens...

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

#24

Post by metamattl »

madrobby wrote: post #18
DannyBee wrote: post #13

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…

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

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

#25

Post by tommi »

bmelton wrote: post #19
orta wrote: post #15

Earlier quoted context omitted.

This happened to me yesterday, and it was the only type of code of it's ilk I could find. Real shame, probably going to have to write my own version.

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?

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

#26

Post by metamattl »

orta wrote: post #15
superalloy wrote: post #7

> Don’t you just hate it when you find some great piece of code on GitHub and then you realize that somewhere at the end of the README the frightful acronym GPL is ruining your good mood? Yes. But what I ‘hate’ even more is not finding any license info. Adding this would probably help in that area as well.

This happened to me yesterday, and it was the only type of code of it's ilk I could find. Real shame, probably going to have to write my own version.

Generally speaking, GitHub public repos are only for free software projects.

A lot of people just forget to put up a license. I file a polite bug with the project, and they generally fix it within a day or so.

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

#27

Post by metamattl »

DannyBee wrote: post #9

I would love this, but there are at least a thousand open source licenses. Even if you limit it to licenses that have at least 1% adoption rates, you still have at least 40 (there are more, i just stopped counting). As such, this would be a confusing dropdown. A free form text field with autocomplete (and synonyms, so if you typed "general public license", it would still autocomplete GPL.

Not really. There's less than 100 licenses out there, and most projects use a subset of around 10 of them.

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

#28

Post by d0mine »

madrobby wrote: post #10
mindcrime wrote: post #5

For "GPL type" licenses, it would probably be better to use the term "copyleft" rather than "restrictive" since their copyleft nature is really what's particular about them. That said, I'd almost prefer a setting that lets you specify the exact license. The problem is, what do you do about dual/multi licensed projects, or projects which contain code that's under a mixture of licenses? I suppose you could argue that i…

Many people don't know what "copyleft" is, so "restrictive" makes more sense. There are more restrictions. For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.

you could use "keep it free" if "copyleft" is not descriptive enough, though just the name of a license would work best.

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

#30

Post by madrobby »

pygy_ wrote: post #20
madrobby wrote: post #10

Earlier quoted context omitted.

Many people don't know what "copyleft" is, so "restrictive" makes more sense. There are more restrictions. For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.

Prepare for an uproar if an entity the size of GitHub summarizes the GPL as "restrictive". The GPL enables freedom for the end user, who's entitled to obtain and modify the source of the programs he uses. It offers some protection against repressive governments and monopolistic companies, a much broader scope than what permissive licenses enable (freedom for the developers). "Copyleft" is well defined and easy to goo…

So what if there's an uproar? Other license writers could also want to be treated specially.

This is just about a general filter, into "proprietary", "do whatever you want to", and "restrictive" open source licenses; for developers when they choose which projects on GitHub might be a good fit for their needs.

If you read the GPL it puts a lot of restrictions on what you can do as a developer. So do other licenses (for example licenses that allow you to use the source in open source projects but require some form of payment when used for commercial products).

Post reply on HN