Software Licences: Open Source and Proprietary

Source code is the human-readable program instructions written by a programmer. Having access to it allows someone with suitable programming skills to inspect how a program works and make changes to its behaviour.

An open-source licence provides access to the source code and permission to modify the software under its terms. This could allow a school to adapt a timetable program to suit its own lesson lengths, rather than waiting for the original developer to add that feature.

Open source does not mean that there are no rules. The licence may set conditions for redistribution, such as acknowledging the original creators or sharing modifications. Publishing source code does not remove its copyright: permission comes from the licence, not simply from being able to see the code.

For users, the ability to inspect and adapt software can reduce dependence on one supplier. Open-source software is often available without a licence fee, which can help an organisation with a limited budget. However, changing it requires expertise. A user who creates a customised version may also need to maintain it, and the availability of documentation, updates and support varies.

For developers, open source can attract users and contributions from other programmers. Community members might improve features or fix faults. In return, the developer may have less control over redistribution, and some ways of earning money from the software may become harder. These consequences depend on the licence and business model.

Proprietary: the owner controls the product

With proprietary software, users are not normally given access to the source code. The owner retains control over changes and distribution, while the licence grants users limited rights to use the product.

Proprietary software is commonly purchased as an off-the-shelf product: ready-made software intended for many customers, rather than a program built for one organisation. It may be supplied through a one-off purchase or a subscription. Users may be able to change settings, but this is different from modifying the underlying source code.

For a user, a ready-made product can provide an integrated set of features and access to supplier support. However, licence or subscription costs can be significant. If a required feature is missing, the user cannot normally add it by editing the source code and may have to wait for the supplier. This creates dependence on that supplier for future development and maintenance.

For a developer, proprietary licensing helps retain control over official releases and supports earning income from licence sales. However, the developer does not gain the same opportunity for a wider community to inspect and improve the source code.

Choosing a licence for a situation

A good recommendation starts with the needs in the scenario, not with the assumption that one licence type is always better.

Consider a council that wants schools to adapt a timetable tool for different local needs and has limited money for future development. Open source would be a suitable recommendation: schools could modify the code, and other developers could contribute improvements. The drawback is that schools would need programming expertise or suitable support to make and maintain those changes.

For a small game studio that depends on sales and wants to protect its original source code, proprietary licensing would be suitable. The studio could retain control over official releases and charge for licences. A drawback is that it would miss opportunities for community contributions to the source code and would need to organise development and support itself.

A research group that wants others to inspect an analysis method and contribute improvements could favour open source. Access to the code supports inspection and adaptation, although maintaining the project still requires time and expertise.

Price, support and security are not guaranteed by either label. Open-source software can have costs, including paid support or customisation; proprietary software is not automatically more secure or better supported. The best choice depends on the actual licence terms, the product and the organisation's priorities.

Neither type guarantees a particular price, level of support or security.

Recommend and justify

Choice → relevant feature → benefit for the scenario → drawback.

Prioritise open source where inspection, adaptation or collaborative development matters. Consider proprietary where controlled releases, licence sales or a suitable ready-made product matter.