4. Platform Independence

When the digital public good has mandatory dependencies that create more restrictions than the original license, proving independence from the closed component(s) and/or indicating the existence of functional, open alternatives that can be used without significant changes to the core product is required.

Source: https://digitalpublicgoods.net/standard/

If your software is released using an open source license but depends on closed source proprietary components and/or services, you have a problem. Your dependencies are creating more restrictions than the license you chose. This applies to all closed but “free” services and components.

Examples of platform independence issues 🔗

Google Firebase 🔗

You’re creating a mobile app and chose GPL-3.0 as the license for your product. You also decided to use Google Firebase for handling user’s data, authentication and analytics. Even if your application is open source, it cannot work without Google’s proprietary components.

Google makes it really easy to start using Firebase using their SDK, locking yourself to work with their services. They give you a generous entry level tier that makes it feel it’s “free”.

In this scenario you need to provide an open alternative to the data storage, authentication and analytics components of your application, away from Google.

AWS Lambda 🔗

You’re creating a service that ingests data (e.g. CSV files) and stores it in a database. You decide to use AWS Lambda to react to new files in AWS S3.

If you architect your solution around the proprietary services of a particular Cloud vendor, your solution is not Platform Independent.

AWS Simple Storage Service (S3) - An exception 🔗

Amazon Simple Storage Service (S3) is a proprietary service by Amazon Web Services (AWS), it was launched in 2006 and has become a de-facto standard on how to handle object storage (binary files).

Over the years several implementations have emerged. All the major Cloud vendors support S3 API, and you have access to open source implementations like MinIO, Ceph, OpenStack Object Storage and others.

If your application uses AWS S3, you can claim that there are open alternatives that support those API calls without major code changes.

Large Language Models (LLMs) 🔗

Most projects release their models (weights) under a non-OSI approved licenses, e.g. just for academic purposes or preventing any commercial activity. Other expose their models via a closed source and propietary API.

If your project depends directly on any of this components or services, your project is not platform independent.

Business Source License (BUSL) and Server Side Public License (SSPL) 🔗

The Business Source License BUSL, and Server Side Public License SSPL are recent “source available” licenses that are not OSI approved.

The main idea of users of this licenses, is to try to block the commercial hosting of their software by other companies¹.

Using a database like MariaDB Enterprise² released under BSL 1.1 or Elastic Search and MongoDB under SSPL, will make your system not platform independent.

Use Open Source components, delegate the hosting and maintenance 🔗

A strategy to achieve Platform Independence easily, is to always use open source components and delegate the hosting/maintenance of those components/services to your hosting provider.

As example, you can use PostgreSQL database for your data and any of the major cloud providers for hosting it: AWS RDS, GCP Cloud SQL, Azure Database for PostgreSQL.

If you are using a MERN³ stack, your database can be hosted in AWS DocumentDB, MongoDB Atlas in GCP, Azure Cosmos DB for MongoDB.

Notes 🔗