Much of modern software is built on open source.
Frameworks, libraries, infrastructure tools, runtimes and models depend, directly or indirectly, on the work of communities and organisations that publish technology under different licences.
Using open source, however, does not mean that software comes without conditions.
Each licence defines rights and obligations.
And when a project starts to grow, managing those dependencies properly stops being only a development matter.
It becomes part of the company’s technology governance.
What OpenChain ISO/IEC 5230 is
OpenChain ISO/IEC 5230 defines the requirements of an open source licence compliance programme.
Its goal is to establish processes within an organisation that allow it to consistently identify and manage the obligations associated with the open software it uses.
The standard does not determine which technologies a company should choose.
Nor does it certify the security or quality of a product.
It focuses specifically on the compliance process associated with open source licences.
Why this matters in artificial intelligence
In AI, dependencies have become especially complex.
An application can incorporate at the same time traditional libraries, machine learning frameworks, runtimes, datasets, model weights and other training artefacts.
And not everything publicly called “open source” uses the same licence or grants the same rights.
Some components allow modification and commercial use with few obligations.
Others require keeping notices, publishing certain modifications or meeting specific distribution conditions.
In the case of artificial intelligence models, moreover, there are weight licences that do not always coincide with the traditional open source licences used in software.
For a company that investigates different models and architectures, knowing those differences is essential.
Compliance from the early stages
It is common for matters such as dependency documentation, attributions or licence review to be left for a later stage of the company.
The problem is that reconstructing years later which component went into a product, which version was used and under what conditions can be considerably harder.
Our approach is different.
We prefer to introduce these practices while the architecture is still growing.
This means technical decisions incorporate questions from the outset such as:
- what licence a dependency has;
- what obligations it introduces;
- whether it allows the intended use;
- what notices must be kept;
- and what implications distributing or modifying that component would have.
Open source does not mean absence of responsibility
We think it is especially important to communicate this distinction because there is some confusion around the term.
A project publishing its code or its weights does not automatically mean it can be used without restrictions.
Nor does it mean that all open licences are equivalent.
Open-source-based innovation works precisely because there are rules that allow technology to be reused while respecting the conditions chosen by its authors.
Managing them properly is part of building professional software.
One more layer of technology governance
For Myukura, working in line with OpenChain is part of a broader principle.
Trust in a technology product does not depend only on what the user can see in the interface.
It also depends on how it is built.
Architecture, security, privacy, dependency management, licences and oversight of artificial intelligence systems are part of that invisible infrastructure.
As Myukura evolves, our intention is for these practices to grow alongside the product and not after it.
Because developing responsible artificial intelligence is not only about controlling what a model answers.
It also means knowing what the system is built with, under what conditions it can be used and what responsibilities we take on in doing so.