PySimpleGUI now requires a (paid) license. Opinions?

Python Help
1

The rather popular GUI package PySimpleGUI recently changed its policy. That means that from now on, a license is required. This license is free for hobby usage and has an annual cost for commercial usage.
This also makes that distribution and installation is much more complicated than before (and other packages).
The Github repo doesn’t contain the old LGPL verions anymore (and not even the Python code!)

I think this is really bad. And others?

As the old versions are forked, it shouldn’t be too difficult to release an old version (maybe only the tkinter variant) under a different name. That might be also a good point to make the package more Pythonic and maintained by a group of contributors.

Anyone interested?

2 Likes
2

The code is still available (albeit slightly obfuscated). The license change does not apply to code previously published. See the linked YC thread. Not going to comment on the actions.

3

Really not a fan of people closing off projects, and unless someone steps forward to maintain a fork long term, it’s likely better to jump ship rather than try to cling to it.I started a parallel thread looking for people’s experiences with different GUI libraries (Python GUI library experiences) so maybe there’ll be something worth switching to?

1 Like
4

Blowing away all the old git commits isn’t very nice. It’s unfortunate that open source developers don’t get compensated for their work.

The original PySimpleGUI code is pretty horrid, though, the design is miserable, there are over 25,000 lines of Python code in a single 1.7M file, endless copying and recopying of parameters that would far better be dataclasses, one line of code that is 11k in size (not including all the single-line binary constants), and all sorts of massive duplication of code - and of course, no type hinting at all.

It would be better to figure out what the attraction of this project was and do a proper job of providing whatever those features are in some sort of maintainable, modern Python module than to continue to pour more resources into this white elephant. Of course, who bells the cat?

6 Likes
5

I don’t use the project, and would never consider using this project.

But we all have to make a living, and in my opinion, in the West, $99 a year for a commercial license is an absolute bargain. If your company uses this library in its software, bite their hand off now, and buy 10 years up front.

Good luck PySimpleSoft.

2 Likes
6

I have no problem with people selling software. I do, however, have a problem with someone releasing something under a well-known open source license, letting people get accustomed to using it, and then bam, relicensing for future versions so it isn’t redistributable any more.

Plus, the dichotomy of “hobby or commercial” doesn’t work. You say “company” there, but what about open source projects? Even with no monetary cost, forcing people to sign up after using something for thirty days is simply not acceptable for a huge number of projects.

As a result of both of these problems, I would not touch PySimpleGUI with a ten foot pole. There is a measure of broken trust here that means I would prefer pretty much anything else.

3 Likes
7

It’s not great, I agree. They’ve shot themselves in the foot too, if they expect anyone to use one of their open source projects in future.

But we don’t know what their circumstances are. I don’t know how much maintenance is required that their users expect for free (or that stems from the considerable technical debt).

letting people get accustomed to using it, and then bam, relicensing for future versions so it isn’t redistributable any more.

Yes indeed. It’s another Rich’ move. But they own it, and it’s their decision. And if the alternative is a widely used library becoming unmaintained, or ‘heroic’ bankruptcy from their dedication to unpaid voluntary work (I’ve witnessed this in another sphere), what should the maintainer do?

Re: the ‘dichotomy’. Users will have to read the T&Cs and make their own decision.

The possibility of rug pulling is something any company, and indeed anyone, should consider when picking a new dependency. And also the reason why they should create their own fork, and their own backups, while the deps are still open source licensed.

The previous license was LGPL3, so users should’ve made themselves aware of the implications of that. It would’ve been harsher and more burdensome, if PySimpleGUI was relicensed it as GPL3 with no commercial option.

My sympathies lie more with anyone who contributed to this, who is now squeezed out and not provided with a free license. But I don’t think that was likely:

While PySimpleGUI is currently licensed under an open-source license, the project itself is structured like a proprietary product. Pull Requests are not accepted.

But they’re not even Hashicorp let alone Oracle. They’re Mike and maybe 3 others, who’ve made a niche little project that a surprising number of people like. The team like working on it themselves, but need to bring in more money to justify their time working on it instead of work for other customers. And presumably buymeacoffee and Github sponsorship etc. just wasn’t cutting it. This is what they’ve chosen to do to change that.

I’ve been snubbing it due to the monolithic python file, but their readme was comprehensive to be fair to them: PySimpleGUI/readme.md at master · gabrielsroka/PySimpleGUI · GitHub

8

Do you maintain your own personal copy of Python and keep updating it? Or do you rely on the fact that the PSF isn’t going to suddenly pull the rug out from under you? Keeping a copy of the code isn’t sufficient. You have to maintain it.

9

I agree with your advice. It’d be easier to provide a proper Tkinter wrapper, than to maintain and update PySimpleGUI.

I think the attraction is

  1. building your layout with lists
  2. a very non-programmer easy-to-understand event loop.
  3. modal windows out-of-the-box
  4. built-in table data view

All these would be relatively straightforward to accomplish.

2 Likes
10

Well then at least all that damn time I’ve spent writing IronPython compatible code wouldn’t have been wasted :wink:

Seriously, The F in PSF stands for Foundation (which I like to think was inspired by Asimov). I don’t know the details, but the copyright to the vast majority of Python these days is owned by a non-profit or charity. With rules and governance, the primary purpose of which is to protect Python for the community. E.g. we all have to sign something before we contribute, so as contributors it’s difficult to rug pull.

If Python was owned (or ever becomes owned) by Microsoft then yes I would have to consider that. In particular because the project I’m mainly concerned about is owned by a customer.

And the owner of the code is something I would look into before deciding to invest time getting to grips with Mojo, for example.

11

They do indeed ship a 2.5MB .py file, but I don’t even think PySimpleGUI 5 can truly be described as source visible.

Towards the end of the huge file, the 10s of kB binary constants are b85 decoded, unzipped, b64 decoded, which is fine.

But then they’re loaded with marshall and run with exec!

My defence of PySimpleSoft was on the assumption that PySimpleGUI’s paid license is a source visible, free-as-in-freedom-to-modify license. It’s breakable. Easily so, to Python Byte code. But for a formerly open source project, decoding and execing binary constants in this way leads to code that could be doing anything.

If a user has to import dis or download specialist tools, before they can be sure PySimpleGUI isn’t doing anything nefarious, on the user’s own users’ machines, then PySimpleGUI is effectively closed source.

I do love the ascii art in it though. Shame that’s the best thing about the code base at first glance.

1 Like
12

I don’t know the details, but the copyright to the vast majority
of Python these days is owned by a non-profit or charity. With
rules and governance, the primary purpose of which is to protect
Python for the community. E.g. we all have to sign something
before we contribute, so as contributors it’s difficult to rug
pull.

The PSF doesn’t own the copyrights of others’ contributions to the
CPython codebase. To the contrary, the contributor license agreement
contributors sign explicitly states “Contributor retains copyright
in its Contributions.” Contributors license their contributions to
PSF, but that’s not quite the same thing as assignment of copyright.

If Python was owned (or ever becomes owned) by Microsoft then yes
I would have to consider that.

A quick grep indicates Microsoft owns copyright to code in 52
different files in CPython’s source tree at the moment. Other major
companies do likewise. And that’s fine, good actually. The more
distinct copyright holders there are contributing to the project,
the better it is for the project’s health and longevity. What allows
a situation like PySimpleGUI is when one organization or individual
owns the copyright to a vast majority of the code in a project
and also controls its registered trademarks. This is often termed
“single-vendor open source” and has been the dynamic behind most of
the bait-and-switch license changes in previously popular open
source projects that have gone proprietary/source-available.

1 Like
13

I am not advocating for it, but playing the devil’s advocate here - (setting aside disappearing commit etc etc) what is wrong with someone trying to capture some of the value s/he/they has created in the market?

1 Like
14

Nothing, as long as they do it honestly instead of via a rugpull. I don’t dispute the right of people to demand payment for their services, nor to request donations or any other monetization form. It’s just scummy to set out with something built on a copyleft license and then relicense it to try to grab some money from it. Bear in mind that part of the boast of PySimpleGUI 5 is that it’s completely compatible with PySimpleGUI 4, so this isn’t like “hey, I’m giving up on that old thing and here’s its spiritual successor”, it’s clearly a license change in an existing program.

That’s the part I dislike.

2 Likes
15

Urg!

I wasn’t even checking out the new version, I was looking at a fairly recent version of PySimpleGUI 4 that was in one of my virtualenvs, which would be similar to what any fork would start from.

It makes routine use of eval(), but not for obfuscation purposes, and there’s no marshall() at all. I’m not quite able to see why eval() is used at all, and I feel a bit… sullied reading it.

My theory is that they’d written this successful program using eval() and then thought, “Hey, I can use this to obfuscate my code so I can sell it!”

This is logical consequences of two things:

  • open source developers not being compensated, and
  • Python GUIs being obscure for beginners and inconsistent with each other
1 Like
16

Very good list!

(There’s one more feature that people might be using, which is that PySimpleGUI has multiple backends for other systems like Qt, but my theory is that beginners don’t care, and if there were a good abstraction, building the other backends would be easy.)

I don’t have the familiarity with Python GUIs to actually design and spearhead this, but I’d be up for throwing a few dozen hours of work into helping out by writing utilities, code reviewing and writing tests.

If anyone does this, I’m rec (Tom Ritchford) · GitHub, send me your reviews or tag me!

17

Thanks. That’s really useful.

18

I was about to release an open-source python application which would have been using V5 but I stopped short and retained V4… The reason is the sheer inconvenience of every person downloading and running my app from GitHub it having to register for a key in order to use it. It feels like a bait and switch operation and it’s just not the way open source works.

I emailed the new company about this scenario and, as yet, I have had no reply.

2 Likes
19

I fully agree with you.
I’m sure this is the end of PySimpleGUI.

In the meantime, I am working on a new GUI package, which is essentially a fork PySimpleGUI with some enhancements and focusses more on the GUI-functionality. So, no debugger, proper exception handling, etc.

20

For whatever it is worth, I am maintaining a fork, FreeSimpleGUI, started from the last available LGPL-licensed commit from PySimpleGUI. There’s not really anything compelling about PySimpleGUI v5 in particular, anyhow.

The owners of PySimpleGUI yanked the two latest v4 releases from PyPI, so if you want to use those, you’ll have to specify them explicitly. But even those releases were quite behind where the GitHub was at in the last LGPL-licensed commit. FreeSimpleGUI is released on PyPI has all the fixes and enhancements that never made it to an official PyPI release of PySimpleGUI 4.

The license terms of PySimpleGUI 5 also have some bizarre clauses, like this:

Licensee may not […] (i) incorporate PySimpleGUI or any portion thereof into any software that purports to subject it to open source software or similar license terms, including any prior version of PySimpleGUI (modified or unmodified) which was previously distributed under such licenses

I’m not sure if I’m reading that right, but it sounds like they want you to agree to not use the previous versions of PySimpleGUI that were released under an open source license? Patently unreasonable, if I’m understanding that correctly. Previous versions of PySimpleGUI were released under LGPL-3 and they can’t just retroactively revoke that license, right?

5 Likes