I rather recommend torrents and download files named like “Rihanna.mp3.exe”. This is to my knowledge the most secure source.

these were dirt cheap on the darkweb circa 2014 and i hope that they still are

I don’t know how, but I’m sure Ai found a way to increase those prices too. lowkey joking here, but I’m actually scared by the idea this could be true. Edit: I mean so that Ai tools can access those videos as cheap as possible.

Yes, but does anyone actually use LGPL still? Anyway that is a different license and not really GPL anymore, as it does not force anything. I mean if the project is GPL licensed already, then you can’t turn it into LPGL, because that is no longer compatible. So the issue for programs and games being GPL remains. If they were LGPL from the start, yes, that probably would solve it.

One example is that GPL games cannot be published in Steam, with using Steams proprietary tools and features.

And in general I am not actually against for any company to use MIT licensed products without open sourcing their own proprietary tools. It would be nice if they open sourced it, but I am against in forcing companies to do so. Now I understand the risks involved here, but its not like MIT license is the devil, just like GPL can be problematic in some cases, MIT can too.

Thanks for providing a source. I will watch it at later time and put it on Watch Later list. Until then I can’t really say anything about it, just wanted to thank you.

I can’t speak for medical field… but a more serious topic, in example videogames. :D

I think sometimes GPL can be in the way, so it is a tradeoff. In example if you use proprietary Steam features in your game, then you cannot build the game with GPL libraries and code, because that is not compatible with proprietary code. For some that is exactly what the GPL is set to do, for others its hindering games and other software to be released on Steam with Steam features. That means, its impossible to sell GPL software on Steam, if you want to use any of those features (I think in example Achievements and online save files in example). MIT would solve this issue.

I don’t think Ai companies care about the license at all, or cannot be checked after the training. So that is not really an argument to me.

Why does it matter?

This is not about defending corporations. It doesn’t matter who does that, I don’t think writing new tools with a different license is bad. My opinion has nothing to do about who does that, if communities, or corporations. I think having tools in a different language than C, especially something like Rust, is a good thing. Anyone who writes Rust code can read, adapt and make changes to it.

And for licensing, GPL can be problematic in some cases that is not compatible with every license. Therefore having an alternative in MIT license is a good thing. Even if it ends up being in a proprietary program, its still better than not able to use the code. The old GPL code is still maintained independently.

It’s not even Ubuntu doing the new implementation. And no, having a new project that is compatible to an existing one does not make it a license laundering. The word “license laundering” doesn’t even make sense.

I don’t think so.

I don’t understand why Canonical is replacing the existing GNU tools. Unlike many others, I don’t think its “taking over GPL projects” or “license laundering” and I am also not against MIT license. My question is, why Canonical is doing this.

This is not a takeover of GPL project, this is a new project that is compatible to existing tools with GPL license. The old GPL projects are untouched and not controlled by Canonical.

How is this license laundering? These are complete new implementations and the original projects are not touched.

Every CPU is a definition. Even if there is only one. That’s not the point. I also said already that ARM is an implementation of the RISC idea. What makes ARM not being strictly defined is, that no one has to follow an existing ARM CPU definition. Its like saying that every CPU with a branding is strictly defined, yes obviously they are defined for themselves, otherwise it wouldn’t be possible to build one.

I feel like we’re talking past each other. I’m not saying you are wrong, at least in the sense what you are trying to say.

Yes, but they could have compatibility like x86. The difference is that every CPU creator can have different sets, not just a superset. That’s why ARM is not well defined, because its by nature cannot be. There is no definition of what an ARM or RISC CPU has to offer or be compatible to.

If backwards compatibility bothers you, then replace it with “a series of well defined ISAs”

This is exactly what I’m saying, its not well defined architecture. You never know if the next ARM CPU will be compatible or not to any existing variants.

which still does not define the RISC philosophy as a whole

What do you mean? ARM is a RISC CPU. The entire philosophy of RISC is that anyone can implement this RISC system, and no guarantees are made to be compatible with any prior CPU. We have RISC CPUs since the beginning of 80s.

The official Acorn RISC Machine (ARM) project started in October 1983.

Not really. Unlike x86, an ARM implementation doesn’t have to be compatible to any of the existing CPUs. That’s because of its nature being RISC it can be adapted and changed. There is no core ARM set that has to be implemented by every ARM CPU like x86 does, so that base compatibility is guaranteed. Just because a few CPUs in the family were compatible, doesn’t make the entire architecture design well defined… it cannot be by nature being a RISC implementation.

Just because ARM does not maintain backwards compatability does not invalidate my point.

It does. ARM is basically a set of RISC processors that each of them are different. There is no single ARM well defined instruction set, because every ARM CPU is incompatible and an implementation of the RISC idea. You cannot say ARM is well defined. But you can say x86 is well defined.

I mean 80s computers had ARM CPUs, that has nothing todo with todays ARM anymore. This is not what I would call “well-defined”.

ARM is a well-defined instruction set architecture (ISA), that in order to implement, must comply with that instruction set and be compatible with other implementations from other vendors.

But that’s not true. ARM isn’t well defined and a single standard, like x86 are. ARM devices are not compatible to each other necessarily. I just had the genius idea to lookup online, I should have done that instead wondering what it is. According to Wikipedia: https://en.wikipedia.org/wiki/ARM_architecture_family

ARM (stylised in lowercase as arm)[a] is a family of RISC instruction set architectures for computer processors.

The original Berkeley RISC designs were in some sense teaching systems, not designed specifically for outright performance. To the RISC’s basic register-heavy and load/store concepts, ARM added a number of the well-received design notes of the 6502.

So I was correct after all. Also ARM is around since 41 years.