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:
- flask-script, python methods for stdin prompts, BSD license: https://github.com/tony/tmuxp/blob/e5791e55f5ecfe4793b8b246c056193c1b12a064/tmuxp/cli.py#L42
- salt, python method for finding binary through PATH's.: https://github.com/tony/tmuxp/blob/e5791e55f5ecfe4793b8b246c056193c1b12a064/tmuxp/util.py#L204
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.

License question #32

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions