Live data from Hacker News

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

mir.aculo.us

121–130 of 138 posts

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

#121

Earlier quoted context omitted.

No, the GPL linking exception exists to allow proprietary code to link against GPL'd code. It is a common myth (propagated by anti-GPL activists) that using GPL'd code in your software requires you to put your software under the GPL. In reality, your code can be under nearly any open-source license. I often receive emails from users asking me to re-license one of my libraries from GPL to BSD/MIT so they can use it in…

So are you saying I can copy and paste some useful functions from your GPL code into my BSD code? And then the next person can use my code (with the pasted code from your project) in their proprietary software, given they stick to the requirements from my BSD license? As far as I understand, the viral nature of the GPL does not allow this.

Sort of.

If you copy and paste functions into your code, then those functions are still under the GPL, and your code is still under the BSD.

Anybody could then copy and paste your BSD code into their proprietary software, and only have to conform to the BSD licence's requirements.

The main issue with this is that it when you mix code from various sources in the same file, it can be very difficult for readers to know what licenses each section of code has. For that reason, when I need to include code which has a different license or copyright from the main work, then I put it in its own file with its own copyright/license header.

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

#123
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.

I'm usually in favour of modified BSD or a similar permissive license; but whenever I read someone who is bitching about the GPL because it is too restrictive (i.e. it forces them to give back as they were given,) I consider only adhering to the GPL in the future.

> I consider only adhering to the GPL in the future.

Exactly my feelings!

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

#124

Earlier quoted context omitted.

Many people don't know what "copyleft" is, so "restrictive" makes more sense. I could see that holding true among the general population, but among developers? What developer who's going to be browsing Github doesn't know what copyleft means? There are more restrictions. Yes and no. Even licenses like the Apache License do impose restrictions of sorts, and the whole "permissive" vs "restrictive" thing is hardly a bin…

"Yes and no. Even licenses like the Apache License do impose restrictions of sorts, and the whole "permissive" vs "restrictive" thing is hardly a binary proposition. It's a continuum... and that's not even considering that saying "restrictive" raise the issue of "restrictive for who?" Yes, arguably the GPL is more restrictive in terms of how a developer can interact with GPL'd code, but from an end-user perspective t…

or the patent stuff in the Apache license

Exactly. That's a great example of what I had in mind. Nobody talks about it, but that stuff is there and is important.

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

#125

Earlier quoted context omitted.

No, the GPL linking exception exists to allow proprietary code to link against GPL'd code. It is a common myth (propagated by anti-GPL activists) that using GPL'd code in your software requires you to put your software under the GPL. In reality, your code can be under nearly any open-source license. I often receive emails from users asking me to re-license one of my libraries from GPL to BSD/MIT so they can use it in…

My impression is that I cannot license derivative works of GPL works under a permissive license. Is this incorrect?

It depends on what sort of "derivative" it is. Follow these two simple rules of thumb:

1. You can't change the license on other people's code.

2. Other people can't change the license on your code.

-----------

1.

If you fork an application licensed under the GPL, and you make some changes, the original code is still licensed under the GPL. You may not distribute it under the BSD or MIT licenses.

If your changes are big enough, you could maybe license just those under a more permissive license, but then your final product really has two licenses (see case #2).

-----------

2.

If you fork an application licensed under 3-clause BSD, and you copy code into it from both a GPL'd library and an MIT'd library. The application's code is still BSD'd, but your project itself is now derived a derived work of three separate projects (with three separate licenses), and you will need to obey all of them:

* You will need to include the licence text and copyright information of all three projects (required by GPL BSD MIT)

* You may not use the names of the original application's authors to endorse or promote your work (required by BSD). You may use the names of the GPL or MIT library authors (permitted by GPL MIT).

* Anyone who compiles binaries of your project, including yourself, will need to include the complete corresponding source code (required by GPL).

-----------

Note that there's a difference between having a choice between multiple licences (aka "dual-licensed", "multi-licensed") and having a codebase covered by multiple licenses.

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

#126

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…

The problem is, what do you do about dual/multi licensed projects, or projects which contain code that's under a mixture of licenses?

All questions that were answered over a decade ago by sites like SourceForge. Though not perfect, their solution was using tags for each license, and letting developers tag their project with multiple licenses (among other attributes, like language used, development state, etc.). This tagging system was called the Trove system, but since a software company has named itself "Trove Software", my last few Google queries didn't lead me to the origins of the system, only Freshmeat and SourceForge's references to the name.

http://sourceforge.net/apps/trac/sourceforge/wiki/Software%2...

http://freecode.com/articles/fm3s-fresh-features-tagging

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

#127

Earlier quoted context omitted.

Besides the blog content license is CC BY-NC-SA. That's copyleft, isn't it? Interesting choice for a person with a strong opinion against the GPL.

1) his blog content isn't software 2) the general issue with GPL isn't copyleft; it's the patent clauses (in GPLv3), and all of the various distribution requirements, plus the essential forbiddance of DRM (in GPLv3) So no, it isn't so interesting.

At the risk of coming off as one of the maligned "personal opinion" people, I have to object a little to (2). That may be the general issue, I could agree, but it's not my issue.

Because my issue is the sheer length and complexity of the GPL; I have read it and I do not pretend to understand it, and I don't personally as a developer want to release under a license whose implications I don't really understand. The problems just start with Section 1 and accumulate from there.

For me, the nastiest part is not really the copyleft or DRM so much as the no-linking aspect of GPL. I still don't know what precisely constitutes "linking". I don't know whether Python is in violation of the GPL because the standard library has a readline module, and I don't know if my own code is in violation of the GPL because it's written in Python. GPLv3 actually made this point a little clearer; in GPLv3 you would say "Python as a whole plus its readline library is probably GPL, but as long as you don't write 'import readline' you could probably release under something else instead." Now that there is a BSD version of readline called editline, I wonder if even that analysis holds. But the GPL makes even this analysis complicated, because if Python forgot to mention that the whole package was GPL, then actually their license to readline can potentially be revoked at any time by the readline copyright holders.

And there are some nasty parts too, like the ongoing incompatibility between the Eclipse Public License and the GPL. You now have people explaining how to get readline and wrap Clojure in a readline interface (which is allowed) because Clojure presumably isn't allowed to connect directly to readline in its own REPL.

LGPL, at least, I don't have to worry about this crap when building an application which uses yours as a tool. You can license under LGPL if you really think that GPL's legal phrasing is absolutely magnificent and you love it. I don't want to release under such an ugly license myself, and GPL forces me to violate my aesthetic principles.

So, never mind, some guy whining about GPL over here. (whistles aimlessly.)

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

#128
post #8

Earlier quoted context omitted.

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?

If one feels that the license is flawed, then why not? It's possible to not like the viral clauses for various reasons, such as incompatibility with other viral licenses, but feel there is some issue, like patents, that are not well-covered under the BSD license, for example.

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

#130
post #83

Earlier quoted context omitted.

Or who code for the Xbox, Sony, Apple or Nintendo platforms, where you can't turn off the DRM on your binary, so can't use GPLed code in your project even if you release the entire project as source/art/whatever.

Copyleft tries to discourage closed platforms. As such, you wouldn't expect Copyleft-ists to support those platforms by making developing for them easier/cheaper. They give you the carrot of free code; the stick is the viral nature of the license. Expecting to reap the fruit without giving anything is best left to spoiled brats, not clear thinking developers. In fact, the FSF proudly claim that by keeping some librar…

[deleted]
Post reply on HN