koalalorenzo/python-digitalocean

Why LGPL?

Closed this issue · 3 comments

tony commented

#33

LGPL wasn't written with scripting languages in mind. It's still a huge license that can create derivatives. It hasn't been tried in court in any jurisdiction I operate in, to my knowledge (USA + IL). The licenses language is ambiguous on what creates a derivative. I don't want to risk creating one or being accused of doing so just to use a python library for digital ocean.

Since this is the most popular package for digital ocean and python, would you consider switching it to MIT/BSD/ISC/Apache2, etc?

For the moment, does anyone know any alternatives without viral clauses?

please check #17
Leaving this issue open for a while, in case somebody has feedback to add.

tony commented

no wonder, this is the same library I commented in during 2015. 2 years later, the only real digital ocean python library I can find has viral terms in the license, for apparently no reason.

It really is a bad idea to use LGPL for scripting languages. The wording inside it is ambiguous. Most python/js/ruby/etc. libraries are MIT/BSD/ISC/Apache explicitly because of this.

I contributed to GPL projects before, but there were C/C++.

In my circumstances, which I can't control, I can't pull in LGPL python/ruby/js code.

C/C++ libs, it's fine.

there could be stop-gap measure that all future contributions are MIT/BSD/Apache 2 licensed so there's no need to catch up in the mean time.

Closing, as nobody seems to find interest in this.
(Please re open in case! This is just bigger than what one may think... it requires the approval from all the previous contributor to change a license)