Why it Matters
The use of the term ‘open source’ by AI vendors warrants careful scrutiny, particularly when core elements of the solution remain proprietary.
The Open Source Initiative (OSI) defines open source software as software that can be freely used, modified, and shared. The OSI stipulates ten criteria for software to be open source, and a critical aspect of these is the user’s ability to run the software for any purpose, to study its operation, and to adapt it to their needs. This implies access to the complete source code required for the software’s functionality, including any underlying models or critical dependencies.
In the case of CustomGPT.ai, the MIT licence applies to the provided StarterKit code, which primarily comprises front-end components, API integrations, and bot connectors. This is beneficial for developers seeking to accelerate integration and customise user-facing elements.
However, the explicit mention of ‘CustomGPT.ai’s infrastructure + high accuracy AI’ as a distinct part of the offering indicates that the core AI processing and its underlying model are not part of the open source release. Users leveraging the StarterKit become dependent on CustomGPT.ai’s proprietary backend for the actual AI functionality.
This model, often referred to as ‘open core’ or ‘open consumption’, is a prevalent business strategy in the technology sector, whereby a company offers a core version of its software as open source while selling a commercial, proprietary version or component with additional features, tools, or services. While it enables vendors to foster adoption through perceivably open client-side components, it can create a nuanced form of vendor lock-in. Organisations gain flexibility in their customisations and deployment of the client, yet remain reliant on the vendor for the essential AI services. This means they cannot independently host, modify, or audit the core AI model itself.
Table 1: Key differences between Open Source and Open Core Models.
| Criterion | Open Source Model | Open Core Model |
| Licencing | Permissive (e.g., MIT) or Copyleft (e.g., GPL) | Dual-licensing (i.e., Open Core plus proprietary) |
| Monetisation | No direct code sale; revenue from support or services | Sale of proprietary add-ons, premium features, or services |
| Features | All features are in the public codebase | Core features are open, premium features are closed |
| Community Relationship | Decentralised and collaborative; community-driven | Centralised control; often uses contributor licence agreements (CLAs) |
| Examples | Linux, llama.cpp, Mozilla Firefox | GitLab, Elastic, Confluent, Datastax |
For some organisations, this aligns with their operational needs, prioritising ease of integration over full ownership of the AI stack.
For others, particularly those with stringent compliance requirements, intellectual property concerns, or those seeking true independence from a single vendor, this distinction is critical. Organisations must evaluate whether an open source front-end component, combined with a proprietary back-end service, aligns with their strategic objectives for technological independence and control.
The current industry trend reveals a pattern in which AI companies offer wrappers or interfaces as ‘open source’ while retaining control over the foundational AI models and their operational environment, potentially leading to a misinterpretation of the full implications of ‘open source’ adoption.
Who’s Impacted?
- CIO/CTO: ICT executives must understand the strategic implications of adopting solutions labelled ‘open source’ that maintain proprietary backends. Key considerations include long-term vendor dependency, total cost of ownership beyond licensing, and the ability to migrate or switch providers.
- Development Teams/Engineers: Directly benefit from the provided code for rapid prototyping and integration. They need to understand the architectural boundaries between the open source client and the proprietary AI service to manage expectations for customisation and scalability.
- AI Teams/Data Scientists: Should assess whether the high accuracy AI meets their specific model performance and explainability requirements, and if the proprietary nature limits their ability to fine-tune or replace the core models.
- Project Leads/Technical Architects: Responsible for ensuring that the chosen solution aligns with the organisation’s broader technology strategy regarding open source adoption, avoiding potential future lock-in, and managing technical debt.
- Legal/Procurement: Must scrutinise licensing agreements to differentiate between open source components and proprietary services, ensuring compliance and understanding the scope of intellectual property rights and service level agreements.
Next Steps
- Thoroughly review the specific GitHub repositories to ascertain the exact scope of the MIT-licensed code and identify proprietary dependencies.
- Evaluate the long-term strategic implications of relying on proprietary AI infrastructure, including potential vendor lock-in and future cost escalation.
- Assess the availability and maturity of alternative, demonstrably fully open source AI solutions for comparison.
- Conduct due diligence on all AI vendor service level agreements, data privacy policies, and support, with a specific focus on the proprietary AI component.
- Engage with legal counsel to understand the full implications of combining open source client code with a closed source AI service.
