Software, data, and model weights can fall under different licences, and there is little legal precedent for resolving conflicts between them.
2
Inference engines are developing quickly, but teams still need to compare their ease of use and deployment trade-offs.
3
Cloud GPUs can help in the short term, while Casper expects on-premises hardware to become cheaper and more secure as infrastructure improves.
Summary
Casper da Costa-Luis discusses three parts of open source AI: licences, deployment software, and hardware. He explains why software licences do not answer what happens when code is trained on data under a different licence, especially when the resulting model weights are treated as a separate artefact. He also warns that the word "open" is used loosely and can mean open source or merely open licensed. On deployment, he briefly introduces inference engines and a comparison table from an open sourced book. On hardware, he describes the tension between GPU memory requirements, cloud rental, and on-premises systems. He expects distributed compute and smaller models to reduce pressure over time. His main software complaint is that code is still tied to target devices. He hopes WebGPU will make applications more portable by detecting local hardware and compiling for it.
Different parts of an AI system can have incompatible licences
Casper separates software licences from licences for data, images, and text. A project might use Apache 2 code while training on text under a Creative Commons licence. The resulting trained weights do not have an obvious licence, and Apache 2 discusses compatibility with other code licences rather than non-code licences. When licences are further apart, there is little legal precedent to guide teams. Casper says the practical answer can depend on how much a company can spend on lawyers.
The word open does not tell you enough about a product
Casper says marketing material often calls products open without explaining whether that means open source or simply open licensed. Open source normally includes an open licence, but the reverse is not always true. A team may only need commercial use to be allowed, but that does not necessarily meet the Open Source Initiative definition. He also describes a range from public domain and permissive licences to copyleft licences, which require modified versions to keep the same licence.
Choosing a licence depends on whether the artefact is code, data, or hardware
For software, Casper mentions eight popular licences and says his personal preference is the Mozilla Public License because it combines Apache 2-style permissiveness with a weak, file-level copyleft similar to the LGPL 3. For data, he would choose one of three Creative Commons licences. He also mentions a suite of open hardware licences. The choice still does not solve enforcement, since smaller projects may lack the resources to act when others ignore their licence terms.
Casper points out that fair use in the USA and fair dealing in the UK can affect whether a licence must be followed in a particular situation. International companies then face different legal conditions across the countries where they provide services. He says the usual practical response can be to stop serving some countries. He connects this problem with the lack of regulation and oversight around large companies that decide where AI services are available.
Open source licences commonly disclaim responsibility when software causes harm
Casper objects to the no-warranty clause found in all of the more than 100 Open Source Initiative-approved licences. In his view, this leaves people with little recourse even when software supports livelihoods and then breaks. He discusses proposed EU laws, the CRA and the PLA, which were still in consultation at the time of the talk. He says the proposals aim to address profiteering companies, while some objections misrepresent their purpose.
Inference engines are part of the deployment problem for language models
After moving past the licensing discussion, Casper turns to self-hosted inference engines and fine-tuning. He presents the start of a comparison table and says the ease-of-use column may be contentious. The material comes from a book with one chapter per topic, which he says has been open sourced and is free for people to read and contribute to. The talk gives only a short introduction to the comparison rather than a full evaluation of each engine.
GPU memory is a short-term constraint that may ease with smaller and distributed models
Casper says language models often need substantial GPU RAM. In the short term, renting cloud hardware is one option, and he points to resources for comparing GPU costs. Longer term, he expects compute to become more distributed and models to become smaller while using their available weights and memory more effectively. He thinks on-premises hardware may then be cheaper and more secure, while maintenance becomes less difficult as surrounding infrastructure improves.
Hardware portability still depends on software that targets each device
Casper says the current software problem is that compiled code is not portable, so developers need different code for different target devices. He hopes WebGPU will solve this by allowing a browser to detect local hardware and compile for it automatically. In his view, hardware manufacturers have historically coupled software and hardware partly to lock users in, but the same coupling is increasingly becoming a source of maintenance work.
