Re: Open vs proprietary LLMs

Lucas Nussbaum <[email protected]> Tue, 25 Aug 2026 08:30:44 +0200
Newsgroups	gmane.linux.debian.devel.general
Message-ID	<[email protected]>
Hi Wookey,

On 25/08/26 at 00:49 +0100, Wookey wrote:
> Because of the request to vote on the 'AI' GR I am having to think
> about this subject.
> 
> Having read the various options and some of the discussion on -vote I
> am surprised that none of the options we have to vote on seem to
> distinguish between LLMs where we have all the parts and can run them
> ourselves, and proprietary LLMs run remotely over which we have no
> control, reproducibility options, security/privacy insight, etc.
> 
> For me this is the major distinction about which tools are OK to use
> for free software work, and which are not. We have always made this
> distrinction about free vs proprietary tooling (for building, not
> necessarily code/image/document creation, admittedly), so why is there
> no option in the GR letting me express this view? Did the subject not
> come up?
> 
> I realise I am making this point too late to be useful, but them I'm
> not on -vote so didn't know any of this was being discussed until the
> vote mail arrived.
> 
> This seems like a rather major omission? But perhaps I am missing something?

There are actually three levels of freeness in the world of LLMs.

It's useful to see LLMs as input data (or very large configuration
files) for inference engines such as vLLM or SGLang. They are not
executable on their own. They are actually similar to DNS blacklists:
you need to plug them into a piece of software that will make use of
them to provide a service.

The three levels of freeness are:

# 1. Open Source models.

An example is Apertus (https://www.apertus-ai.org/). You get the
training data and recipes, so you can theoretically train it again
yourself. Those models are mostly created by academia at this point, and
I don't think that they are really comparable in terms of performance
with the other options.

# 2. Open Weight models.

You get the weights (the data files), so you can (1) run it on your own
infrastructure, provided you have enough computing resources; (2)
post-train it or fine-tune it, that is, use your own data to change the
LLM to be better at handling your data.
There are numerous models in that category, mostly from Chinese labs.
In terms of performance, many of them provide reasonable alternatives to
the closed models below.
The ability to do post-training yourself is not just theoretical. For
example Cursor (a company developing an IDE and providing an API
service) post-trained Kimi K2.5 (on their users' data?) to create Composer
2.

# 3. Closed models, only available through an API, mostly from the large
US companies.


Regarding ecosystems:
There's a lot of vendor lock-in in the world of closed models: their
providers try to control the full stack, from the model to the
user-facing applications (coding agents, integration into office suites
etc.)

In the world of open weight models, the situation is much better.  There
are the companies that provide the models themselves (and often API
services as well); there are many companies providing API services for
those models (without being the creators of those models); and also
companies/services that act as proxies to various providers (such as
OpenRouter, Opencode Go, Opencode Zen).  The stack to run the API
services is mostly free software with reasonable communities, and the
user-facing apps are also full of free software.



The GR discussion focused on the use of this technology for Debian
contributions. When discussing usage, the level of freeness sounds like
a more secondary concern than if the discussion was about inclusion of
LLMs in the Debian archive. And it looks like, for ballot options
proposers, the level of freeness was not that important compared to
other factors/axes.

There was a ballot option focused on this question, proposed by Charles
Plessy[1], but it did not gather enough seconds.

[1] https://lists.debian.org/debian-vote/2026/07/msg00193.html

Lucas
signature.asc (application/pgp-signature, 833 B)