11–20 of 138 posts
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.
And when the drop-down disagrees with the COPYING or LICENSE file...?
Then you send a quick note to the owner of the repository to ask him what's up.
So you end up with a lot of badly marked or unmarked open source, which isn't great.
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.
The drop down has 4 entries. Please read the article again. :)
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.
And when the drop-down disagrees with the COPYING or LICENSE file...?
> 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.
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.
Earlier quoted context omitted.
The drop down has 4 entries. Please read the article again. :)
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…
"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.
> 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.
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.
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.
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 google. Education doesn't hurt people.