license

[tony]

Hi,

I'm working on a library @https://github.com/tony/libvcs/ that could utilize this project for richer functionality. However there is a snag I found that the current license on pysvn conflicts with libvcs (BSD).

Any thoughts on making this license compatible with MIT/BSD?

[dsoprea]

There won't be a conflict as long as you don't store the sourcecode for
PySVN in your project. Dynamically including it from a public repository
doesn't violate the license.

[tony]

Hey! 😄 Thanks for getting back. Its good to know your intention is that. I have not heard this perspective on GPL in python before. I am more familiar with hearing that in terms of LGPL.

But even with LGPL, there's enough ambiguity (https://twistedmatrix.com/pipermail/twisted-python/2004-May/007944.html). I've spent quite a bit of time trying to dig up info on actual cases of LGPL re: importing via public repos/pip and came up surprisingly dry. I'd rather not open downstream to the uncertainty. I had a similar conversation at ScottDuckworth/python-anyvcs#32 a few years back.

The other reason is I want to avoid duplicate effort wherever possible. A lot of the reason its not easy to come up with cases to clarify (L)GPL in python is many averted the issue by picking something permissive. A lot of it I feel is due to distribution being in source code anyway (no binary blob issue except in extensions, which are often built from source at install time against system headers, etc.) The only other thing it'd bring to the table is reciprocity, there was actually a case of that a while back, aside from that contributions tend to come back since maintaining a fork/vendorizing is costly.

[dsoprea]

I'm not sure what I'm supposed to be taking away from your last post. Is the issue resolved?

As far as licensing goes, my desire is, obviously, to allow people to use and find value in my projects. I love solving a problem for myself and then allowing it to be used by others to prevent duplicated effort. However, the philosophy is that commercial interests have money and can afford licensing a third-party solution (right or wrong; see loophole) and that people working for open-source should be supporting other people that are working for open-source. The loophole is that commercial interests (like my employer, yours, and others') can still use it as long as they're not managing its delivery or privatizing it, which is the common case in Python's situation.

[tony]

In terms of pysvn, I don't believe (L)GPL would be well-suited to incorporating it with other libraries. I base this more off of current practice with python libraries. I did an analysis of it a few years ago at saitoha/canossa#1 (comment).

As far as licensing goes, my desire is, obviously, to allow people to use and find value in my projects. I love solving a problem for myself and then allowing it to be used by others to prevent duplicated effort.

That is good! We have overlap there.

However, the philosophy is that commercial interests have money and can afford licensing a third-party solution (right or wrong; see loophole) and that people working for open-source should be supporting other people that are working for open-source.

Like QT-style licensing?

Are you looking into the possibility of GPL licensing and then having a commercial-license for your software? Like http://isotope.metafizzy.co/license.html does?

There are commercial places that will choose a non-GPL alternative if given the choice. There's still an opportunity to fork it and add value commercially to permissive licensed projects (FreeBSD has FreeNAS, OrbisOS in PS4, etc). The benefit is that one can fork something like FreeBSD and choose to to contribute upstream and / or open source new components.

Bare in mind, anyone has the right to grab MIT/BSD code and re-license it as GPL since its forward compatible. However, the problem lies in GPL not being backward compatible to MIT/BSD.

As for commercial ambitions with python and licensing python code, I haven't seen or head of many examples. Maybe https://riverbankcomputing.com/software/pyqt/intro. I don't know how commercially successful they are. People are wary of using (L)GPL in python due to the nature of it being in source form and the language of the license not covering the how python is often used in practice. Unlike compiled languages where we link libraries (such as gtk) or communicate with an executable (such as GPL and git(1)) I've had times where I've also copied out individual files and functions from python/JS projects (of course providing attribution and tweaking after).

I could probably talk about it for a lot longer. But if I could make 3 points about the pysvn/libvcs and GPL wouldn't work:

1. How a derivitive / combined work is created is ambiguous due to the nature of interpreted/scripting languages (urwid LICENSE urwid/urwid#41 (comment) under Why it's not permissive).
2. If a derivitive work is created and distributed, GPL applies its own terms to the whole project that incorporates it, requiring its source be released under those terms. That is a bit too strict of a thing for something I'm releasing open source 😄
3. Licenses like ISC/MIT/BSD are far simply and less prone to disagreeing over, they make far less opinion. One can still decide to fork an maintain a GPL version of a project. It can't work the other way around.
   3b. Its a real pain to turn back on at a later time. urwid permissive relicensing effort urwid/urwid#135

IMO you get to have your cake and eat it too with MIT/BSD in python.

[ids1024]

Here is what the FSF says about what license to use for libraries:

For libraries, we distinguish three kind of cases.

Some libraries implement free standards that are competing against restricted standards, such as Ogg Vorbis (which competes against MP3 audio) and WebM (which competes against MPEG-4 video). For these projects, widespread use of the code is vital for advancing the cause of free software, and does more good than a copyleft on the project's code would do.

In these special situations, we recommend the Apache License 2.0.

For all other libraries, we recommend some kind of copyleft. If developers are already using an established alternative library released under a nonfree license or a lax pushover license, then we recommend using the GNU Lesser General Public License (LGPL).

Unlike the first case, where the library implements an ethically superior standard, here adoption for its own sake will not accomplish any special objective goal, so there's no reason to avoid copyleft entirely. However, if you require developers who use your library to release their whole programs under copyleft, they'll simply use one of the alternatives available, and that won't advance our cause either. The Lesser GPL was designed to fill the middle ground between these cases, allowing proprietary software developers to use the covered library, but providing a weak copyleft that gives users freedom regarding the library code itself.

For libraries that provide specialized facilities, and which do not face entrenched noncopylefted or nonfree competition, we recommend using the plain GNU GPL. For the reasons why, read “Why you shouldn't use the Lesser GPL for your next library”.

http://www.gnu.org/licenses/license-recommendations.html

It seems pysvn fits in the second category, so based on the FSF recomendations LGPL would be appropriate. Of course, the FSF has a bias for L(GPL) copyleft licensing, and a more liberal license license like MIT/BSD as @tony is sugesting may be better.

[rutsky]

@dsoprea am I correct that your intention is to have all PySvn users to use GPL 2-compatible license?

E.g. if I'm developing project that will use PySvn, my project should have GPL 2 or GPL 3 license (but not BSD/Apache, since they are less stricter than GPL).

[dsoprea]

It only matters if you ship both together. If you're dynamically pulling down dependencies then it doesn't matter. On Dec 16, 2016 19:17, "Vladimir Rutsky" <[email protected]> wrote: @dsoprea <https://github.com/dsoprea> am I correct that your intention is to have all PySvn users to use GPL 2-compatible license? E.g. if I'm developing project that will use PySvn, my project should have GPL 2 or GPL 3 license (but not BSD/Apache, since they are less stricter than GPL). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AArraigojeJ3dyQ9gwdOaSlRCjsGG8Geks5rIyo3gaJpZM4I-aPj> .