Open source AI: Red Hat's point-of-view(redhat.com) |
Open source AI: Red Hat's point-of-view(redhat.com) |
(1) Model weights are something like a bytecode blob. You can run it in a conformant interpreter, and be able to do inference.
(2) Things like llama.cpp are the "bytecode interpreter" part, something that can load the weights and run inference.
(3) The training setup is like a custom "compiler" which turns training data to the "bytecode" of the model weights.
(4) The actual training data is like the "source code" for the model, the input of the training "compiler".
Currently (2) is well-served by a number of open-source offerings. (1) is what is usually released when a new model is released. (1) + (2) give the ability to run inference independently.
AFAICT, Red Hat suggests that an "open-source ML model" must include (1), (2), and (3), so that the way the model has been trained is also open and reusable. I would say that it's great for scientific / applied progress, but I don't think it's "open source" proper. You get a binary blob and a compiler that can produce it and patch it, but you can't reproduce it the way the authors did.
Releasing the training set, the (4), to my mind, would be crucial for the model to be actually "open source" in the way an open-source C program is.
I understand that the training set is massive, may contain a lot of data that can't be easily released publicly but that were licensed for the training purposes, and that training from scratch may cost millions, so releasing the (4) is very often infeasible.
I still think than (1) + (2) + (3) should not be called "open-source", because the source is not open. We need a different term, like "open structure" or something. It's definitely more open than something that's only available via an API, or as just weights, but not completely open.
Can you update a bytecode blob as easily as finetuning and prompting models? It only takes a few input-output pairs and a few dollars worth of compute. They are more like an operating system and fine-tuning/prompting is like scripting on top. Similarly with Linux, you can download a LLM and run it locally.
Consider recent Mistral-Small release. The model training is almost totally closed-source. You can't replicate it. However, the model inference is fully open source: the code and weights are Apache licensed. Not only that, but Mistral released both the base model and the instruction-tuned model, so you have a good foundation to work from (the base model) should you prefer to do your own instruction tuning. In fact, Mistral has also open-sourced code to aid in the fine-tuning process as well. So you really have everything you need* to use and customize this inference system. And for most practical purposes, even if you had the original training data, it would be of no use to you.
It's also worth considering the inverse scenario. Suppose Meta were to release a big blob of pre-training data and scripts for Llama 405B, but no weights. This clearly qualifies as open source, but it is basically useless unless you have many millions of dollars to do something with it. It would do very little to democratize access to AI.
* Asterisk: There is one situation where having access to the original training data would be really, really useful -- model distillation. Nobody can match Meta's ability to distill Llama 405B into an 8B size, because that process works best when you can do it on identically distributed data.
That's not open source!
I'm going to call this "Wizard of Ozzing". You give away the spectacle of magic tricks, but none of the science and machinery to do it yourself. You're still hiding it all behind fake virtue signalling.
Open source in AI is open weights, open training scripts, open inference scripts, open training datasets, and associated helper utilities. Without the science lab, you cannot replicate the science.
Weights in a vacuum are not open. It's a trick.
If you actually go look at the open source or few software definitions, that's what they're about - being able to make modifications.
Just like an open source software project doesn't need a public record of the rationale for all architectural decisions in order to qualify.
The prevailing strategy for most companies is to publish some bullshit (like a cli or a model downloader) and call it open source, the bar is waaay low and we are just trying to raise it a couple of inches, it's not helpful to go for the throat and demand that it be raised to the sky!
This seems to conflate Red Hat and Linux, as well as try to equate Red Hat with open-source. Red Hat is Linux, but Linux is not Red Hat, especially now that Red Hat has decided to restrict access to the RHEL source (https://www.itworldcanada.com/article/red-hat-decision-turns...).
And a pet grammatical peeve of mine:
> ... in some respects they serve a similar function to code.
I see this everywhere now -- IMHO it should be "... serve a function similar to code." Doesn't the original grate on your ear?
Also this is a Turing-test bot detector -- bots don't use this weird grammatical construction, only humans do.
That fact that people continue to spread this trope is amazing.
I pay for RHEL and I have a developer subscription for personal usage and the SRPMs are right there on their download portal.
Just because CIQ err Rocky has to take extra steps and violate Red Hat’s EULA doesn’t mean they restricted access.
> The majority of improvements and enhancements to AI models now taking place in the community do not involve access to or manipulation of the original training data. Rather, they are the result of modifications to model weights or a process of fine tuning which can also serve to adjust model performance.
Well yes, because they have no access to anything more. With training source code and data they might do something different. If you don’t have all the things used to produce the final result, it’s not open source.
Where the concept is the exploitation of thousands of volunteers while repackaging their work. (I know that RedHat sponsors some people, sometimes to the detriment of projects, but a lot of it is not sponsored, especially when RedHat established itself.)
Glass houses.
??
https://docs.fedoraproject.org/en-US/reproducible-builds/
https://pagure.io/fedora-reproducible-builds/project/issues
https://fedoraproject.org/wiki/Releases/41/ChangeSet#Reprodu...
Good to see they are slowly closing some blockers every year or so, but fundamentally today they do builds and signing centrally. There is no way to readily get the same hash of a central fedora supplied rpm locally.
Supply chain integrity is simply not a priority. They just trust the central build farm, or the compilers it uses, or everyone with access to it will never be compromised.
The classical definition of open source (cited in this release as Stallman's GPL definition of the preferred way in which to modify code) kind of breaks for ML programs.
This is a good update on the definition of open source from a quite reputable and influential FOSS source.
Your presumption that this article isn't sufficiently pure because in addition to being a company that does Free Software, it needs to do so without doing anything that resembles an ad or in any way ensures profitability is pedantic. If we had it your way the only open source software we would have would be mom's basement projects with shoestring budgets.
Data isn't fungible in the same way: I can't just replace one dataset with another for research where the data generation and curation is the primary novel contribution and expect to replicate the results.
There's also a larger accountability picture: just like scientific papers that don't publish data are inherently harder to check for statistical errors or outright fraud, there's a lot of uncomfortable trust required for open-weight closed-data models. How much contamination is there for the major AI benchmarks? How much copyrighted data was used? How can we be sure that the training process was conducted as the authors say, whether from malfeasance or simple mistakes?
Yes, if Hardware is developed against standards shared by multiple manufacturers like amd64
You can e.g. give away a closed-source game engine with an editor, where you can modify the prebuilt levels, and create your own, to your heart's content. But you can't build it from scratch in a controlled environment, and can't audit it. You also can't do modifications where the level editor interface is not sufficient, e.g. in the renderer. That's not open source, that's freeware.
For ML models, the training set is a crucial part of their source.
I’m happy open weights exist, but it is not truly open source.
- Pretrain
- Fine tune
- Catastrophic forgetting
- Learning rate
- Adapter layer
If you understand these terms, then you understand why "open weights" are not the same as "open source".
"Open weights" are obfuscated and minified freeware.
This definition of "open source" for AI must not be allowed to take hold. It's pernicious.
Weights are a compiled binary. Encumbered freeware.
If only there was a catchy name for it. Something like bit-torrent perhaps?
Also, it takes a ton of work and testing and bug fixes and patches to get software reproducible. Assume most packages are not reproducible until proven otherwise. Arch, debian, nix, guix, all do that work and publish the proof, for several years, with far less resources than redhat or fedora. Stagex even has 100% (shameless plug)
Easy user hash for hash reproducibility with published reproduction testing proofs is the standard baseline for years now, and even that is nowhere near good enough.
Multiple independently signed reproduction proofs with full source bootstrapping is IMO a bare minimum for any distro that expects other people to be able to trust it for more than hobby use cases.
Supply chain attacks are becoming very common, and no one should have to trust a single engineer somewhere with a god signing key for a major distro.
Also just to spot check a popular package in Fedora, rust, I just confirmed it still downloads a non-reproducible binary rust compiler to build its own rust package, so it is certainly not reproducible from source even putting aside the rpm signing format problems. Fedora blindly trusts whoever builds the binaries on the rust team. I can only assume RHEL does the same.
https://src.fedoraproject.org/rpms/rust/blob/8e04e725bbf4eb9...
Vanguard has an odd corporate structure where it’s owned by the funds that it manages, so it’s effectively a co-op owned by its customers.
Think of these huge funds as proxies. It's like someone with little finance trading saying most of the internet is owned by cloudflare or RIPE or ARIN.
You are much better off sticking with Debian anyway, or looking at Guix for a significant improvement.
Vanguard and other large institutions own a huge chunk of everything because most investors don't buy stocks directly, they buy them through mutual funds, ETFs, etc...
https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
tl;dr: They no longer publish source packages except to paying customers. If the paying customers republish the source, then RedHat closes the account.
I'm surprised none of the upstream developers have sued them for violating the license. There's no way I'd trust an organization that was behaving so unethically with control over my machine's package manager.
Anyway, I've been pretty happy with Devuan (Debian without SystemD). I find it much more stable than Ubuntu, Arch, Debian, etc., and all the userspace stuff I care about works great.
>If the paying customers republish the source, then RedHat closes the account.
Even if you ignore the above and think only about the official sources provided direct from the customer portal, it's still not a violation IMO.
Because that's not a restriction on how you can use the software you've been provided, it's a restriction on which services you can expect Red Hat to continue providing you, i.e. providing new software in the form of updates. The software you have already been provided continues functioning, it's not like the system gets bricked if your account is closed. GPL only specifies "what are you allowed you do with this piece of software you have been provided with", it doesn't guarantee a future relationship between the provider and receiver.
At worst it's a murky area, not a "systematic violation" as you claimed.
Also, like, it's a hypothetical thing the user agreement claims could be done, not something that necessarily is done. I don't think there has ever been an actual demonstrated instance of an account being closed because of that.
IIRC thats incorrect, RHEL gets some fixes before CentOS Stream.
Sounds like that implies that they probably actually aren't.
I think it probably doesn't apply to other majority holders like BlackRock though.