Looks like you are correct, these projects are required to be AGPL: https://opensource.stackexchange.com/questions/2684/monetizing-and-licensing-with-agpl-libraries

When your program uses an AGPL library, then your whole program must be licensed under the AGPL.

I would simply create an issue in the relevant repositories and let them know.

File an issue in their repos, sometimes people (understandably) do not understand licencing very well — or it might be they were granted an exception.

If that fails you can contact the library author and the repositories who host the code.

Looks like wefwef just went AGPL: https://github.com/aeharding/wefwef/commit/ff7ee694edc8c7e5c47fc4c597e01aa123ce3ff0

They are loading this library via NPM AFAIK, so it is not included in the repo. Of course the final compiled release should be AGPL, but they are free to use a more liberal license in their own repo as long as it allows combining with AGPL software.

MIT for sure, but I think also Apache license (one way?) allows this so I think on license grounds this is ok. But IANAL.

Here's the relevant section of the GPL FAQ:

https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)

Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL. See also: What does it mean to say a license is “compatible with the GPL”?

I believe it's up to the license holder to enforce it.

So notifying the respective projects can't hurt, but if they refuse to comply, and the copyright owner of lemmy-js-client doesn't care, then the code is probably licensed incorrectly

The Free Software Foundation is a good place to learn about open source licensing and they can assist with enforcement if needed.

I'm just a bystander here, but I would recommend to take this very seriously. The free-software-writing community already gets a certain amount of license abuse from the corporate side (RHEL being a recent example). If we are being lax about license violations internally, that puts us in a much weaker position in the face of whatever is inevitably coming in the future.

E.g., maybe Meta grabs the MIT-licensed app, adds additional technology to it that makes life difficult for the existing Fediverse community, and deploys it, refuses to share their changes. They could do that anyway, and we might have to figure out how to respond to it, but it puts us on a lot firmer ground legally and PR-wise if we've been on point about our internal licensing up until that point vs. if no one's really been bothered about license violations in the past.

It doesn't mean that someone from the community who's just trying to contribute something good and doesn't share that viewpoint suddenly needs to become "the enemy." We can just have an open discussion about the technical details of licensing and why they're important. But I wouldn't take it lightly.