51–60 of 138 posts
Earlier quoted context omitted.
The LICENSE or COPYING file in the repository wins, obviously. Also, not everyone would set the setting. But it's a start.
Just seems like a source of potentially expensive misunderstandings.
Earlier quoted context omitted.
I can't include code under GPL in my own code without changing my own code to GPL. That's why it ruins my day.
Only if you are distributing the combined work and not giving the source code along with it. Preventing that is the whole point of GPL.
Why on earth would the GPL ruin your day? What's with all the fear mongering? The only practical difference is you're forced to put up your patches somewhere… which you've probably already done when you hit 'fork' on Github.
I can't include code under GPL in my own code without changing my own code to GPL. That's why it ruins my day.
2. You're using free code off the internet. If you don't like the license terms, don't use it. It's within the author's prerogative to set his or her own license to his or her own code.
(The most you can do is send them a politely worded email on how you want to use their code without being obliged to the virality clause - I imagine a lot of people would be okay with moving down to the LGPL at least. If not… deal with it.)
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.
My personal take would be to limit it to: 1. licenses that are certified by the OSI, and 2. licenses listed as "GPL compatible" by the FSF, assuming that (2) isn't just a subset of (1) anyway.
That would include by far the majority of popular and widely used licenses. Maybe have an "Other" field for anything else?
Earlier quoted context omitted.
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 100…
[1]: http://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyle...
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.
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.
My point goes further than people forgetting to add a license, though. Some people think that just adding it as an open repo to GitHub is enough, which, depending on the country, it clearly isn’t.
In my opinion, GitHub should educate people a bit more about this. A simple feature like this could just be enough.
Earlier quoted context omitted.
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 (fo…
It would be boneheaded from a PR stand point, and it is insulting towards the GPL.
> Other license writers could also want to be treated specially.
You seem to have a serious gripe with the GPL. The GPL (its unnamed ancestor, to be pedantic) is the mother of open source licenses. It enables Freedom, with a capital "f" for its users, at the expense of obligations for people who distribute binaries. Liberal licenses turn the situation around.
Labeling the GPL, but not liberal licenses as restrictive is heavily biased, and simply does not reflect reality (since liberal licenses put implicit restrictions on binaries recipients).
I speak as a license author, BTW: https://github.com/pygy/The-Romantic-WTF-Public-License
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.
However, if your objective is to convince people of an idea, then you should consider that some opinions are beside your point, and don't need to be expressed. These really are two completely different objectives, and sometimes, if your objective is to persuade and explain, then you have to omit certain opinions of your own which will detract from your point.
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…
No. "Restrictive" vs. "permissive" captures exactly the relevant information. If I look for some code to include in my project, I don't care if the license is "copyleft" or "copyright" or whatever. I just need to know if including the code puts legal restrictions on my project. For example, both GPL and CC-NC are "restrictive", but GPL is "copyleft" while CC-NC is not. Also, "copyleft" would somehow suggest compatibi…
Licenses are complicated, and what people want to do with code is complicated too; "restrictive" vs. "permissive" cannot be defined well. "copyleft" represents a well-defined, understandable concept; while not without edge cases, it makes it fairly clear what kind of license we're talking about.
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.