Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apache License v2 #64

Closed
kennethreitz opened this issue Jun 16, 2011 · 12 comments
Closed

Apache License v2 #64

kennethreitz opened this issue Jun 16, 2011 · 12 comments
Milestone

Comments

@kennethreitz
Copy link
Contributor

No description provided.

@rboulton
Copy link
Contributor

Are you planning to change to this license? If so, please be aware that it's incompatible with projects licensed under the GPLv2. (And I'd be sad and unable to use the module in the main place I want to.)

@kennethreitz
Copy link
Contributor Author

Hmm, thanks for pointing that out.

I'm planning on switching mostly because of the contribution clauses.

@kennethreitz
Copy link
Contributor Author

What project are you using that's GPLv2? Most popular GPLv2 projects are dual licensed w/ v3 as well.

@rboulton
Copy link
Contributor

One example is imgseek (http://www.imgseek.net), which is incorporated in (a patched version of) Xapian (http://xapian.org). Xapian itself is GPLv2 or later, but imgseek is v2 only (which is one reason that it's not in the main distribution of Xapian).

I've come across a few others, though I agree it's not common.

@kennethreitz
Copy link
Contributor Author

Hmm, thanks for the info.

The main feature of the Apache v2, the patent killall clause, is what causes the GPLv2 incompatibility. Obviously, there's nothing in Requests that's patentable, so it may be overboard. I'll look into alternatives.

I'll likely add a contribution clause to the existing license.

@rboulton
Copy link
Contributor

I've not looked the contribution clauses in the Apache license before - I assume you mean clause 5: "Submission of Contributions". It's an interesting approach, but I'm not sure how safe it would be to rely on it. I think you (in general) really should get explicit confirmation from a contributor that it's okay to redistribute their code under the project's license anyway, to be on the safe side. Assuming that they've read the license properly and are happy with that clause seems unwise. In particular, I always ask to check that contributors have the right to give you such a license (employees usually need to get their employers permission for code written in work time, for example) before incorporating it - if they get it wrong, you're still liable to some extent for distributing it. If you don't ask, they often don't even think of that potential problem. (Except for simple one line fixes, etc, where there isn't a copyright concern.)

Certainly, I don't think that the act of forking requests and pushing some changes to that fork would count as a "Contribution intentionally submitted for inclusion in the Work" - I think there's a strong case that you need something more explicit than that.

One other thing to think about: it's possible you might want to contribute requests to the python core (in the distant future?). Maybe you should just use the python license, to make that easier?

It's your choice, of course, and I'd be happy to license the contributions in my fork on github under any open source license (and I have the right to, too!), but hopefully my comments are of some help.

@rboulton
Copy link
Contributor

FWIW, my preferred license these days, unless there's a very compelling reason otherwise, is MIT/X - it's clear enough that it's actually reasonable to expect people to have read it, and it doesn't get in the way of anything. That, combined with getting an explicit message from contributors that they agree to it, seems pretty safe to me.

@kennethreitz
Copy link
Contributor Author

Holding this off, for now.

@ThomasWaldmann
Copy link

AL2 licensed software is rather unfortunate for any GPL v2-only project that would like to use it due to that incompatibility.

But please don't underestimate that even GPL v2+ licensed projects also might not want to de-facto restrict themselves and their users to GPL v3 just because they would like to use some AL2 code. Tomorrow they might need some GPL v2 only code and then they can't use it because that would create a combination that's not licensable at all any more.

Similar if they already use GPL v2 code (although most code is v2+), then they can't use AL2 code already without causing that problem.

So it would be really great if you could license requests under a more compatible license.

A potential GSOC student proposed to use requests (which I technically find great), but it currently looks like we can't allow it. :-(

@Lukasa
Copy link
Member

Lukasa commented Apr 23, 2013

You should probably talk to @kennethreitz about whether he's prepared to dual-license Requests, either in general or in specific cases.

@kennethreitz
Copy link
Contributor Author

Nope.

@Lukasa
Copy link
Member

Lukasa commented Apr 23, 2013

Looks like GPLv2 projects are out of luck then @ThomasWaldmann. Sorry!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants