Use a more portable LICENSE?

[tony]

Any hope of getting this on a permissive license?

I can't use this on github.com/tony/patches, as I'm hoping to be able to use it to grab bugzilla issues/attachments, GPL isn't backward compatible with MIT (only forwards).

Looks like you may be able to keep it permissively licensed:

'bugzilla' python module for talking to a Bugzilla instance over XMLRPC

But I haven't looked over the code closely enough.

If not, the only other client lib I see is https://github.com/gdestuynder/simple_bugzilla (MPL), but this lib has more activity ATM.

[crobinso]

I'm happy to relicense my contributions to LGPL but it will take some work to track down other contributors for their sign off.

[tony]

I'm happy you're willing to consider license changing.

Since this is client API and it's python, are you open to considering something even more permissive (MIT, BSD, ISC, etc?).

A few reasons for this: First, python is a scripting language so I feel there's not as much of a concern over binary blobs / viewing the source. Second, most python licenses are already permissive. Third, the language in the LGPL is muddy and really not clear toward scripting languages and the realities presented (copy-pasting, vendorizing, subclasses, monkey patching, etc). Forth, there isn't any evidence viral licensing would increase reciprocity / deter freeloaders, since python projects like django, pandas, sqlalchemy, celery, etc. already get a lot of stuff back.

[crobinso]

I haven't given it much thought TBH, just that most projects I work on are GPL or LGPL. When I pursue changing the license I'll consider it more

[crobinso]

@wgwoods and @abn are the other devs that would need to sign off on relicensing. At this point I would do MIT just because it seems to be most common in the python library space (at least according to pypi) but if others have stronger opinions I'm flexible

[abn]

I'm happy to re-licence my contributions to python-bugzilla. Consider this my sign-off.

[wgwoods]

I'm also happy to let my contributions to python-bugzilla be re-licensed under the MIT license, or any other OSI-approved license.

[crobinso]

I've been advised I need to get everyone who has lines of code in the repo to signoff. For completeness I'm attaching the full git annotate --incremental output as of commit 13783ac

python-bugzilla-13783acf3e-annotate.txt

[AdamWill]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License - Adam Williamson

[aristeu]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License - Aristeu S. Rozanski F.

[dzickusrh]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License - Don Zickus

[ktdreyer]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License - Ken Dreyer

[Kyras]

I agree to relicense my python-bugzilla contributions from GPLv2 to
the MIT License - Martin Lacko

[lhh]

I agree to relicense my python-bugzilla contributions from GPLv2 to
the MIT License - Lon Hohberger

[scop]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License. Ville Skyttä

[ralphbean]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License. Ralph Bean

... but I'm not super jazzed about it. Viral clause, ftw.

[djmitche]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License. -- Dustin J. Mitchell

[ksato9700]

I agree to relicense my python-bugzilla contributions from GPLv2 to
the MIT License. -- Kenichi Sato

[abadger]

I am not willing to relicense my contributions to python-bugzilla to the MIT license. I am willing to relicense to any chosen version of the LGPL if that helps.

[ehabkost]

I agree to relicense my python-bugzilla contributions from GPLv2 to
the MIT License. Eduardo Habkost ehabkost@redhat.com

[keszybz]

I agree to relicense my python-bugzilla contributions from GPLv2 to
the MIT License (though I too would prefer any LGPL version). Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl

[ktdreyer]

@tony I wrote https://github.com/ktdreyer/txbugzilla (MIT licensed) if you're up for using Twisted :) I'm using it for my team's chatbot at work. txbugzilla does not have a rich API like python-bugzilla and obviously python-bugzilla is ten times easier, but it gets the job done.

[bmbouter]

I am requesting that my contribution stay as GPL. I wanted to share that openly to help facilitate a transparent decision.

[shi2wei3]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License.
Wei Shi wshi@redhat.com

[pkubatrh]

I agree to relicense my python-bugzilla contributions from GPLv2 to
the MIT License. Petr Kubat

[mhlavink]

While I prefer (L)GPL over MIT, I agree to relicense my python-bugzilla contributions from GPLv2 to
the MIT License. Michal Hlavinka

[Lekensteyn]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License. Peter Wu

[crobinso]

Thank you everyone for responding.

To summarize as of this writing: two contributors haven't responded yet (rmarko, aj.lewis), two I did not contact because their remaining changes were only in comments or text files (mnovotny, dario), two contributors did not agree to relicense to MIT, everyone else agreed to relicense to MIT, and some mix indicated they would be okay with LGPL as well.

Personally I don't have strong feelings about changing the license, and I certainly don't have the desire to do anything antisocial like removing people's code to facilitate a license change, so I will be abandoning this effort and sticking with the GPL.

Maybe LGPL is a palatable option for everyone but for now I've run out of energy to consider it and chase that down

[wgwoods]

aw y'allllllllll. 😕

For what it's worth, @crobinso and I had a pretty detailed conversation about relicensing back in February, and while I (like a lot of you) strongly preferred to keep all my contributions some variety of copyleft I eventually came around to MIT, for this particular project. Here's why:

1. @tony makes some good points above: most Python projects are under MIT-style licenses and don't have problems getting contributions - and GPL/LGPL protections for shipping source alongside binaries don't really apply here.
2. At heart python-bugzilla is just a client for the bugzilla API; since bugzilla itself is under a good copyleft license I don't feel like we're losing much by relicensing the client code under a more permissive license.
3. If I had to guess, I'd say most changes downstream users make are for handling custom/local use cases, which they wouldn't want to contribute back (and we can't really use anyway).
4. I don't know that the current licensing has itself resulted in contributions we wouldn't have otherwise gotten, but it is keeping away new users. Is this actually the tradeoff we want to make here?

So. Having thought about it a while, I concluded that - in this particular case - I'm fine with MIT, as requested and as is the de facto standard in the Python community.

But failing that, like I said above - I'm okay with any OSI-approved license that makes everyone else happy. So maybe a compromise is in order. @abadger and @bmbouter, if you're absolutely unwilling to allow python-bugzilla to be MIT-licensed, what if we use the same license as bugzilla: MPL-2.0? It's copyleft but still MIT-compatible, in that you can use (unmodified) MPL-2.0 files in a MIT project without losing copyleft on the former or changing the license on the latter. @tony, would that work for your purposes?

[tony]

I had read this and didn't realize we had hold outs for GPL.

The license not changing has downsides. It could deny access to people who don't feel like upending their way of doing things to comply with that license's terms. Which in my opinion, aren't very palatable in the python ecosystem.

The thing with license issues like this is when people see an incompatible license, they may not voice their concerns because they don't want to create noise. So it's not always easy to gauge people who lose access to software because issues outside their control make compliance untenable.

In any event, if it's closed, thanks for your participation. If @crobinso has more energy sometime in the future, maybe this can be looked at again.

---

Re: @wgwoods (#25 (comment))

So. Having thought about it a while, I concluded that - in this particular case - I'm fine with MIT, as requested and as is the de facto standard in the Python community.

Yep. That's what I'm thinking. I tend to prefer licenses that fit in with what other packages are using.

MPL-2.0 files in a MIT project without losing copyleft on the former or changing the license on the latter.

I'm fine with MPL as a license by itself. In this specific instance, I think MPL could be worth discussing more, but MIT may be a better fit when it comes to the python package ecosystem.

The reason why I think this is since this is a library that's a client to access bugzilla, I'm more inclined that it's in a license more common among Python packages, rather than the host software itself.

@tony, would that work for your purposes?

So, for those curious, my purpose was wanting to create a CV portfolio of open source contributions. The hope is people with open source contributions could show off their work more conveniently.

I actually did follow through with this: https://github.com/tony/cv. Here's the GitHub scraper: https://github.com/tony/cv/blob/master/scripts/github.js

The hope is a library like this can be used to pull/sift through Bugzilla trackers. Currently, I have to add my contributions on FreeBSD's Bugzilla by hand.

Re (#25 (comment)):

One option for @crobinso and the rest of the team to consider is making a contribution guideline so future contributions are dual licensed MIT+GPL. That way if the people who felt like GPL change their mind, MIT is a viable option in the future and there's not a need to "catch-up".

Personally I don't have strong feelings about changing the license, and I certainly don't have the desire to do anything antisocial like removing people's code to facilitate a license change, so I will be abandoning this effort and sticking with the GPL.

In the mean time, if people need a python bugzilla client, they're going to have to write their own from scratch. They're being denied service, because the license's terms aren't tenable to their situations.

The lack of accessibility due to license obligations is the real thing that's the problem. And perhaps, even a bigger political issue than removing GPL commits in some way*. At least if it's me, that's the opposite of what I'm trying to achieve with open source - I don't want to burden my users with complicated terms. Especially since viral licenses are more often used in compiled languages. That's my theory.

With MIT, it's forward compatible with GPL. So the theory is the theory is MIT could suit the needs of people who prefer GPL, while not disabling access to people who can't agree to GPL's terms.

Maybe LGPL is a palatable option for everyone but for now I've run out of energy to consider it and chase that down

LGPL may be a fine license in itself, but it's generally not used in the Python community or scripting languages.

* didn't SDL2 do something similar when they went from LGPL -> ISC? I am having trouble finding out how they did it

---

Thanks everybody for considering this license change.

[ehabkost]

@tony:

In the mean time, if people need a python bugzilla client, they're going to have to write their own from scratch. They're being denied service, because the license's terms aren't tenable to their situations.

I'm curious about this part: what exactly is the current license preventing you from doing?

[tony]

I'm curious about this part: what exactly is the current license preventing you from doing?

From worrying. From a volunteer enterprise with finite resources diverting time and effort into license compliance what-if's instead of coding and making a project accessible as possible, with the least catches. From being ideologically neutral in license choices (if my downstream user wants to pick GPL, that's fine, but I don't think potential upstream dependencies should affect that, even tangentially). The long term sustainability of my projects, and my downstream users.

python-bugzilla case is different from most GPL projects.

python-bugzilla is more than just a script that can be accessed through CLI/subprocess commands. If python-bugzilla were strictly an application, there's no issue there.

However, since this is a library and package for a scripting language, there's more areas where license clauses cause friction with users. In my case, I don't want to pull in GPL libs because I think my user's site-packages shouldn't have GPL code in it. If they ever tried to say, use kivy, or release a built desktop version using one of my libraries, and code is GPL, they're now potentially unknowingly rolling a GPL release.

Get where I'm coming from? I don't want downstream users to be snagged by license compliance issues unexpectedly. I can't predict the future. But if sticking to permissive licenses in upstream dependencies help protect this from happening, that's one logistical reason why I don't pull in code like that.

There is one general rule of thumb and way I like to frame this: I'm of the belief that the burden lies of the license with more frills to justify why the additional compliance rules are necessary - not the other way around. That's to say, what benefit does GPL provide that BSD/ISC/MPL/etc doesn't? What's the data backing it? In this case, python is a bustling community and only a handful of libraries have derivative clauses, and those aren't very active.

A final note: GPL is a fine license, I contribute to GPL projects. Those tend to be for compiled languages.

[abadger]

I don't think that MIT can be called "standard" in the Python Community... Standard is something that "almost" everyone uses. A naive look at pypi shows that MIT is about 40% which is larger than the other OSI License tags but doesn't rise to the level of standard (The GNU family of licenses, for instance, is 25% of the total by the same naive metric). (A datapoint for later: All MPL versions only total 0.5% of OSI Licenses on Pypi.) (Google search is leading me to believe that in the OSS world at large, MIT and GNU family are neck and neck at about 32% of projects a piece).

Also note, Python programs can be distributed in non-source form. Byte code will run fine without corresponding source, for instance. There are various obfuscators and "freezers" as well (pex being one of the most well-known).

Third note: a few of the mentioned murkiness of the LGPL are not murky at all (for instance, copy and pasting is not murky... if the work is copyrightable, that's a license violation). The majority of the murkiness mentioned are problems with LGPLv2 but are clarified by LGPLv3.

Those clarifications out of the way, in addition to being okay with LGPL (any version), I may be okay with the MPL but I have some reservations. My goal is to put my work under a copyleft license so that changes related to that work are also copyleft. I don't mind unrelated work which benefits from my projects being under non-copyleft or proprietary licenses. For that reason, I license all of my library code as LGPL rather than GPL. MPLv2.0 and LGPLv3 appear to be the left foot and right foot treading on the line of "my-work" vs "your-work" so if most of the contributors here prefer the "MPLv2.0, compatible with secondary licenses" over the LGPLv3, I'd probably go along but if a significant number prefer the LGPL, I would plant myself in that camp, too. (Being clear, I mean, they would rather have this project licensed under "MPLv2.0, compatible with secondary licenses" rather than LGPL. I want to know that "everyone wants to do this" rather than "everyone is willing to do this" [for some definition of everyone])

My reservations about the MPLv2.0 vs the LGPLv3:

• MPLv2.0 is a more complex license.
  • It attempts to pull many features of a dual licensing scenario inside of a single license.
  • It has multiple versions which are not alike in spirit or in practice. MPLv1.x is not copyleft whereas MPLv2.0 is. MPLv2.0 itself has two versions, one of which is GPL compatible ("compatible with secondary licenses") and one of which is not ("incompatible with secondary licenses").
  • Some terms (for instance, "secondary licenses") don't have the standard English meaning.
• MPLv2.0 is less popular than the GNU family of licenses. License proliferation and license familiarity are real problems.
• The MPLv2.0 sells itself as being a per-file copyleft as opposed to LGPL being a per-work copyleft. This has both pros and cons.
  • Per-file is grounded in concrete objects that makes it easier to understand what is covered versus what is not.
  • However, if you actually care about copyleft, some concept of per-work is necessary. You can circumvent MPL's copyleft simply by placing your changes into a separate file from the MPL'd code. The obvious way this can be used is for adding features (which is on the edge where some will think it's a good thing and others, a bad thing) but even bugfixes can be made under a different license via monkeypatching, subclassing, and otherwise overriding the base code from outside of the file.

Looking at my reservations above, I see that I share many of the same criteria for licensing as @tony, however, I do include copyleft as one of my criteria and I do place that criteria at the top of my hierarchy.

A final note... because of the necessity of getting sign off from everyone in order to relicense, it's likely that the two contributors that haven't responded will be as big a problem for the effort to loosen the license as the people who have actively expressed a desire to keep some sort of copyleft.

[vortechs2000]

I agree to relicense my python-bugzilla contributions from GPLv2 to the MIT License. AJ Lewis

[vortechs2000]

Sorry I'm slow to respond - was on vacation and ignoring email :D