Replying to
@sloanlance @eff There is more info in the link. Basically, the X algorithm makes it hard to get visibility so it is no longer worth the effort.
Remote
wsha
@wsha@fosstodon.org
mastodon 4.7.33 Followers
81 Following
21 Posts
Joined November 05, 2023
Replying to
@mkennedy @pythonbytes @brianokken
I had to break up my message but I thought the second part kind of answered your question any way 🙂 In my first messages, I was talking about traditional turn over of maintainership and copyright. This chardet AI rewrite situation is different. I would say the new maintainer owns the copyright of the rewritten code...probably? I think legally it is not totally clear.
Replying to
@pythonbytes @brianokken @mkennedy pytest makes all deprecation warnings visible which irks me because some warnings come from subdependencies and I can't avoid. I like to put something like this in my test setup though warnings.filterwarnings("error", module=r"mypackage\..*"). Then any deprecation warnings due to my package's direct use will lead to a test failure
Replying to
@brianokken @pythonbytes @mkennedy Hynek says it more forcefully than I did here: https://mastodon.social/@hynek/115741361280546913
Replying to
@brianokken @pythonbytes @mkennedy No problem! It is more convenient for me to post feedback here than the other options but the episode post isn't always there for me to comment on so I was curious
Replying to
@pythonbytes @brianokken @mkennedy
From one of the announcements:
We also mentioned in our update on our foundational work that MkDocs must be considered a supply chain risk, since it's unmaintained since August 2024. It has seen no releases in over a year and is accumulating unresolved issues and pull requests. These developments have forced us to cut our ties to MkDocs as a dependency.
Replying to
@pythonbytes @brianokken @mkennedy So I would hesitate to discuss mkdocs like it is a tool still worth using. There is a discussion on the mkdocs repo with some background:
https://github.com/mkdocs/mkdocs/discussions/4010
A couple tiny PRs have been merged since then so maybe maintenance will pick up again but it is not clear at the moment if that will happen
Replying to
@mkennedy @pythonbytes @brianokken
Also, I think you missed the concern regarding the risk associated with the new license. The point is that if the new version were found to be subject to the terms of the LGPL then anyone using that version assuming it were under an MIT license would find that they were unexpectedly subject to the terms of the LGPL.
Replying to
@mkennedy @pythonbytes @brianokken
All that said, I doubt this chardet issue would ever go to court and be adjudicated, so I don't think there is much risk to the license suddenly changing. It also seems like the courts are siding on AI being transformative and not subject to copyright any way. To me, it seems like for better or worse the end of restrictive software licenses in general.
Replying to
@mkennedy But outside copyright, I agree that Dan controls the project and can choose to throw out all the code for new code not based on the copy left code and keep using the same project name with a different license. The only question there is if the code really counts as not being derived from the old version.
Replying to
@andybalaam@mastodon.social @jezhiggins@mastodon.me.uk That is from the last LNL show notes 🙂
Replying to
@jorge Interesting. I thought sh vs go was one of the main differences between distrobox and toolbx, though I haven't tracked feature differences recently
Replying to
@pythonbytes @mkennedy @brianokken Nice episode as always, but the way you discussed software copyrights is not correct. The software creator holds the copyright and is able to let others copy and reuse the work by granting a license. Being a maintainer is separate from that. You can fork an open source project and maintain. That doesn't grant you the copyright to code.
Replying to
@pythonbytes @brianokken @mkennedy How come not all the episodes get announced here? Is there an integration that is failing?
Replying to
@andybalaam@mastodon.social @jezhiggins@mastodon.me.uk No, there will be a more painful option than there is now but one that doesn't require the command line:
https://android-developers.googleblog.com/2026/03/android-developer-verification.html?m=1
Replying to
@andybalaam@mastodon.social @jezhiggins@mastodon.me.uk Right. Since you already give up the masses by not publishing on the Play store, I would think you don't register with Google. Any user who waits 24 hours just to install one of your games would be a small win against the effort to lock down devices.