ScottDuckworth/python-anyvcs

License question

Closed this issue · 11 comments

tony commented

Thank you for your library, Scott.

Is there a particular reason why lgpl v3 is was chosen and not something more permissive apache/mit/bsd?

ScottDuckworth commented

I'm glad to see that there is interest in the library! I hope you find it to be useful.

I, along with the contributions of one of my co-workers (@OEP), developed python-anyvcs as a component of a larger project for work. We wanted to share our efforts with the open source community while ensuring that derivative works will also be shared with the community.

The Apache, MIT, and BSD licenses all require that software using this library (or something derived from it) be attributed back to our company, as does LGPLv3. But unlike LGPLv3, they do not require that improvements to the library which get distributed are made available to us. This fact that improvements to our code are available back to us came into play when talking with our company's intellectual property team about releasing this library under an open source license.

My understanding of the LGPLv3 is that the software library can be used by any other software, regardless of license, as long as the source code, copyright and license of this library is made known and available, and that any modifications that are made to this library and distributed must be released under the LGPLv3. This does not prevent anyone from using this library in any software, commercial or not. However, I have seen that "some companies" (I've never seen which companies) would rather pay for proprietary software than use (L)GPL'ed code, but in my opinion that's their loss.

If a sufficient argument can be made for a more permissive license, we will take it under consideration. Alternatively, we may consider a dual licensing scheme.

tony commented

Who ever shunned a software project because the license was too permissive? Too free and easy to read? The license is too pure and simple.

Who ever shunned contributing or using a software project because the license was too restrictive? I could think of a few: twbs/bootstrap#2054.

I do not know the particulars about linking LGPL libraries. I'm assuming I could link python-anyvcs and subclass it in my own software and not trigger a reaction to make me release my software as LGPL/GPL also.

I used to use GPL/LGPL and paste it everywhere thinking I was guaranteeing upstream patches that would ensure the livelihood of my project, and it was being used for good. In practice, even today, I don't want to worry over the warts and triggering GPL problems.

My main reasoning for GPL/LGPL back in the day - on its face, is your current reasoning. LGPL/GPL theoretically guarantees upstream diffs to the main project.

  • But it's complicated, and life is complicated. Usage is complicated, and you / the public may not care about how I customized a piece of code in many cases. We just want to use a library to get stuff done, we chafe when it gets in our way. Do I have to give it back? When? Should I give it back, what if it sucks? If it's not worthy as a patch, I could still provide it in a repo - but no one says I have to put it on pypi. And no one may want / care about my modification. The trivialities are written in a complex legal document, we just want to code and ship.

    Try googling the BSD, MIT and Apache licenses. Look at that purity and succinctness. I hope I sell you and your partner on a superior life path.

  • For programmers incorporating libs (I believe this may be more involved than simply linking a dependency, but I'm not sure) In practice, this is python library that people may was to subclass. They may want to copy a module or package and give attribution just for that definition, here's an example of me doing it:

    But also let's think about python libraries where extending classes is super super common. Like SQLAlchemy, where we're extending BaseDeclarative (https://github.com/search?q=declarative.declarative_base%28%29&type=Code&ref=searchresults).

  • In practice, having a more permissive license motivates me to extend/tweak more because of point above, but also, if I incorporate a piece and give it a useful change, it makes more sense for me to offer a patch upstream. This means I get credit for having a patch, and I no longer have to maintain a piece of code that goes out of sync with that codebase.

    I'm aware my examples don't incorporate full libs, only snippets. For a time I was using https://github.com/pypa/pip VCS libs: https://github.com/pypa/pip/tree/develop/pip/vcs and trying to subclass those for my project. It never quite worked out (https://github.com/tony/pullv/blob/1fc575d2b7d626f63700e1cccd7d92ca9e5acbfb/run_tests.py#L311), but this would be something I believe GPL and LGPL would have prevented me from doing.

  • General patching isn't prevented. If an end user wants to submit a patch, they will still do it if they want it to be apart of the software they use.

    Freeloaders. I think to the perception of many, GPL / LGPL's teeth is less about openness and more about people profiting without giving back to the codebase. Tell that to FreeBSD. Tell that to saltstack.

tony commented

@ScottDuckworth @OEP

I think it'd be a step forward to see this project put under a BSD / MIT / Apache license.

pip uses MIT: https://github.com/pypa/pip/blob/develop/LICENSE.txt

ScottDuckworth commented

I've talked with @OEP and we're gonna run a change of license by our IP team. Reopening this issue until that is resolved.

ScottDuckworth commented

The 3-clause BSD license is being considered.

tony commented

I support 3-clause BSD license.

http://opensource.org/licenses/BSD-3-Clause

https://github.com/mitsuhiko/flask and https://github.com/mitsuhiko/werkzeug use 3 clause.

SQLAlchemy, pip and co. use MIT. I do not know the difference between 2 clause BSD and MIT.

tony commented

@ScottDuckworth Any status updates on the license decision? I have an active project I'd like to incorporate this in (https://github.com/tony/pullv) and 3-clause would be perfect. 👍

OEP commented

Since it's been a while I figured I'd try and update:

  • At the moment Scott and I are the only contributors and we both are OK with the license change, so we're not waiting on responses from contributors
  • I haven't heard anything regarding contact with the license team; not sure if we have to physically meet (what we've done in the past) or if they regularly do stuff via email. If it's a physical meeting we need, I'll note that we work for university and sometimes it's hard to get that around this time of year (IMHO, in general too 😄)

If I had to guess, they'll probably be receptive to the license change, but will probably just want to understand the differences. It's probably an easy point to argue since the license is out of Berkeley and that university has released larger works under the license.

tony commented

@OEP @ScottDuckworth

Glad to know you are both OK with the license change.

So this is waiting on a response from the license team at your university? I'll be waiting to hear back on the news. :)

ScottDuckworth commented

Change to BSD 3 clause license is in the develop branch. Will push a new version shortly.