License about python-digitalocean HOT 16 CLOSED

@tony I'm not sure what your gripe is with the LGPL. It clearly states that subclassing does not cause your software to be covered by the license.

An “Application” is any work that makes use of an interface provided by the
Library, but which is not otherwise based on the Library. Defining a subclass
of a class defined by the Library is deemed a mode of using an interface
provided by the Library.

And calling functions provided by the library will be considered making use of an "interface".

As for packaging

What if I import from site-package/dist-packages as source?
What if I import as an egg?

From Section 4

1) Use a suitable shared library mechanism for linking with the Library. A
suitable mechanism is one that (a) uses at run time a copy of the Library
already present on the user's computer system, and (b) will operate properly
with a modified version of the Library that is interface-compatible with the
Linked Version.

This is exactly how site-package/dist-package and egg work. They both allow you to upgrade the library.

What if I vendorize (including it in the source code of my project)?

This is probably not allowed, since the user won't be able to "upgrade" the library.

What if I sublcass Urwid classes in my app?

Already covered

What if I monkey patch urwid in my app?

Anything you can achieve with monkey patching, you can achieve with subclassing. So an Application that monkey-patches the Library should not be covered under the license.

from python-digitalocean.

@moyamo Are you a lawyer?

from python-digitalocean.

I will soon! 👍

from python-digitalocean.

I highly recommend Apache 2.

Alternatively, you can get help picking by using http://choosealicense.com/. It was written by some GitHubbers.

from python-digitalocean.

I think I will choose GPL v3 because I would like to avoid "sublicensing".

from python-digitalocean.

I added GPL v3 here: 91791a0
I hope this choice will not be a problem for you guys!

from python-digitalocean.

Sounds good to me!

from python-digitalocean.

@koalalorenzo : yeah the license will make it difficult to stick this on MIT/BSD/Apache projects since GPL isn't compatible with them. Would it be difficult for you to switch this to to a more permissive license?

from python-digitalocean.

Because is not the first time this is requested, I will probably change the license for the next release! @tony what is your problem with the current license? Just to understand what "seems" wrong with the GPL.

from python-digitalocean.

I think the problem @tony is having is that the GPL is a "viral" license. Any software that uses this license must also be licensed under the GPL. Under clause 5c

You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.

This is a problem for proprietary software and other permissive open source software (such as those license under the Apache, BSD, MIT etc.).

from python-digitalocean.

If we'd like to stay with a "copy-left" license but make it more compatible with other licenses the LGPL is always an option http://www.gnu.org/licenses/lgpl-3.0.html

The choosealicense.com short human-readable summary:

Primarily used for software libraries, LGPL requires that derived works be licensed under the same license, but works that only link to it do not fall under this restriction.

from python-digitalocean.

As @andrewsomething is saying, I was thinking to switch to a LGPL... but I want to understand what is the problem that is limiting somebody to use this library instead of others.

from python-digitalocean.

from python-digitalocean.

My focus is on coding, I'd like to avoid a protracted license issue on gh (see below) :)

MIT or BSD is GPL compatible.
LGPL is a gray area. It probably leaves MIT/BSD/Apache people out because of how its worded.

I go into it in detail on licensing in python at urwid/urwid#41

from python-digitalocean.

This could take a while. I will switch to LGPL in 7 days. If no contributors will complain here, by declaring the intention to not release his contribution under LGPL, in 7 days from today (so at the end of the 27th of March 2015 ) I will switch to LGPL. I think this will be the best way to do that.

Thank you for your suggestions guys!

from python-digitalocean.

If no contributors will complain here, by declaring the intention to not release his contribution under LGPL, in 7 days from today (so at the end of the 27th of March 2015 ) I will switch to LGPL.

I'm fully in support of LGPL over GPL.

I prefer Apache/BSD/MIT for just about everything, due to past experiences of interacting with the collision of open source and corporations. They have a visceral reaction and don't even want to bother dealing with legal ramifications. They'll just choose a library that isn't GPL, like https://github.com/devo-ps/dopy. That's exactly what Ansible did.

In the case of this library, I couldn't imagine anyone extending it in a private fork and not wanting to contribute back to it. This is completely targeting a proprietary system run by a proprietary company for their own profit. It really makes no difference here.

from python-digitalocean.