@jdavid thank you for your response

libgit2 uses the same license, and I think that's the reason pygit2 uses this license. It was that way when I took maintenance of the project, and I actually do like the copyleft property.

As the maintainer I hope you are aware of the implications of libgit2's license on pygit2.

Does pygit2 actually mix / share source with libgit2 or git in any way? Or just link to it?

If it actually borrows code from libgit2 or git, license change wouldn't work because it'd be a derivitive no matter what.

As it stands, the ruby plugin is licensed MIT.

I actually do like the copyleft property.

I never doubled the good intention of copyleft and those who extol it. The problem is in contemporary times we're beginning to find the benefits that copyleft assures us don't need to be put to paper. The virtue of the project and its contributor's being open source leads to the code being available and accessible for the sake of convenience. Contributions end up coming back because its burdensome to maintain internal forks, when a proprietary project dev's does the numbers, it almost always results in them benefitting from contributing back a patch so the community share the responsibility maintaining it.

The linking exception allows to be used the way it is intended to from proprietary software.

It seems to be well-engrained in the marketing pitch of libgit2. Its executed very well. From viewing the libgit homepage with the company logos for Microsoft, GH, etc (it must be commercial friendly) and "permissive licensing". libgit2's README says its under a very permissive license (emphasis libgit2's) . I'm sorry this isn't true.

The linking exception is a paragraph. Its stapled on top of 2000+ words of legalese that could have very strong implications to the developer. It doesn't say under X and Y circumstances, "it may not be used".

Rather, it covers broad circumstances, "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof," with potentially punitive ramifications, even to open source projects, "to be licensed as a whole at no charge to all third parties under the terms of this License."

Even if my ambitions are an open source project, I don't want to risk exposing my downstream users to GPL's terms. It then effects their code base all the same, and to make matters worse, its not portable in the open source world. GPL code is forever walled off from the rest of the open source community, every contribution is actually a debt in a game economics sense, because should one ever been in a circumstance where GPL doesn't suit them, they either have to expend resources building their own library (One of the big motivations behind the rise of Clang and LLVM was GCC doubling down GPLv3) or agree use diplomacy in an effort to get them to convert (doesn't always work).

With pygit2's license, there is an exception to the broad circumstance, "unlimited permission to link the compiled version of this library into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file". Who in the python community uses the term "linking" and "compiling"?

So if I put an app using pygit2 on Android Store with Kivy... I can't use buildozer with .py files, it must be pyc. What if an intermediary compiler like jython/pypy/pyston/cython/any other non-cpython implementation/my own build scripts alters the pygit2's code before its "compiled"?

That is a foggier area, since python is used in a practical sense differently than C/C++ where we often see GPL used. I go into some points over my concerns with (L)GPL / GPL with linking exceptions at urwid/urwid#41 (comment).

A change is still possible, but it would require a large consensus from pygit2 contributors. And I have never heard the opinion on this matter by other contributors. So the change is unlikely to happen...

I have a lot of gratitude to you and the contributors. I think the intention is clear they want the library to useable to many as possible.

Uh oh!

Please convert to MIT #632

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions