What Is Open Source Software? Benefits, Licences and Business Risk

01

Open source means more than visible code

The Open Source Initiative definition begins with an important point: access to source code alone is not enough. The software must be distributed under terms that allow people to use it, obtain the preferred form of the source, modify it and redistribute it.

Those permissions come from the licence. Copyright applies to code even when a repository is public. If the project has no licence, other people do not automatically gain the right to copy it into a commercial application, change it or distribute their version.

Source available software deserves particular care. A vendor may publish the code while restricting commercial use, particular industries or competing hosted services. That transparency can still be useful, but the restrictions may mean it does not meet the recognised open source definition.

The word free can also confuse the discussion. Open source software may be available without a licence fee, but the licence does not promise that hosting, implementation, support, training or maintenance will cost nothing. Free access to code and zero cost of ownership are not the same thing.

02

Why businesses build on open source

The first advantage is not philosophical. It is practical reuse. A team can build the part that makes the business different without writing its own operating system, database, web framework and testing tools.

Imagine a customer portal using Linux on the server, PostgreSQL for data, Laravel for the application and Vue for the interface. The valuable work may be the company's unusual onboarding process, document checks, pricing rules and customer communication. Rebuilding database transactions or password hashing from the beginning would consume budget without making that service more distinctive.

Open source also creates visibility. A capable team can inspect how an important component works, review a change, diagnose an awkward interaction or commission a fix. The organisation is not limited to whatever a vendor chooses to expose through a support ticket.

That visibility can reduce supplier lock-in, but it does not remove it automatically. A business may still depend on one hosting platform, one implementation partner or a difficult configuration known by only one person. The code being available creates options. Documentation, transferable access and internal understanding are what make those options usable.

Open formats and widely adopted tools can make recruitment and integration easier as well. A developer with Laravel or PostgreSQL experience arrives with useful knowledge that is not tied to one customer's private platform. Common technology does not guarantee an easy handover, but it gives the next person a familiar place to start.

03

Open source businesses still make money

Open source and commercial software are not opposites. Companies earn money around open source projects through hosted services, support, consulting, training, enterprise features, dual licensing and managed infrastructure.

A business might run the community edition itself or pay the vendor to operate it. The hosted option can be the better commercial decision when it removes patching, backups, upgrades and on-call responsibility. Access to the source does not mean every organisation should become its own hosting company.

The same applies to development. A framework may be available without a licence fee, while the work required to design, build, test and support a dependable application still has real value. The customer is paying for a working business result and accountable delivery, not for somebody to own the underlying framework.

This is why cost comparisons need to include the whole operating model. Compare licence or subscription fees, implementation, infrastructure, upgrades, support, specialist skills and the cost of changing direction later. A free download can be expensive to run badly. A paid managed service can be good value when it removes work the team is not equipped to own.

04

The licence is part of the technical decision

Every open source licence grants permissions and sets conditions. The exact effect depends on how the software is used, modified and distributed, so important commercial cases deserve proper legal advice. A developer should still recognise the main families well enough to spot when a review is needed.

Permissive licences such as MIT, BSD and Apache 2.0 generally allow broad use, modification and redistribution while requiring notices or other stated conditions to be preserved. Apache 2.0 also includes an express patent grant.

Copyleft licences require shared versions or derivative works to remain available under compatible terms in particular circumstances. GPL is the familiar example. LGPL has narrower conditions designed for libraries, while AGPL includes network use provisions that can matter to hosted software.

This does not mean a copyleft licence is hostile to business. It protects a different set of goals. The mistake is discovering those goals after the code has become central to a proprietary product.

Keep an inventory of important components and their licences. Preserve required copyright and licence notices. Review compatibility before distribution, acquisition or a major product change. Images, fonts, data and documentation can have separate licences even when the application code is open source.

A public repository with no licence is not a convenient shortcut. Ask the maintainer to add a clear licence or choose another component. Ambiguity is not permission.

05

Visible code is not automatically secure code

Open source makes independent review possible. It does not guarantee that somebody has performed that review, found every problem or produced a fix.

A popular project may have experienced maintainers, professional security processes and many organisations testing it in demanding environments. A small package may be maintained by one person in their spare time. Both can be useful. They create different continuity and response risks.

Security therefore begins with selection. Check who maintains the project, how releases are made, whether supported versions are clear, how security reports are handled and how quickly important issues receive a response. Look for meaningful activity rather than assuming that a release every week is healthy or that a mature project with few changes is abandoned.

Once selected, track what the application actually uses. Lock dependency versions so builds are repeatable. Monitor security advisories. Test updates before release. Remove packages that are no longer needed. Know which applications are affected when a serious vulnerability appears.

The Open Source Security Foundation encourages organisations to treat secure consumption as an ongoing process. That includes an inventory, policy based checks, supported releases and the ability to respond when a component needs to be updated or recalled.

The uncomfortable truth is that open source risk is often an ownership problem. The warning exists, but nobody knows who should act. The package is old, but upgrades are repeatedly delayed. The application depends on a project, but the organisation cannot identify which deployed version it uses. Better tools help, but somebody still needs responsibility.

06

Community is useful evidence, not a warranty

Healthy open source projects often have more than code. They have documentation, release notes, issue discussions, contribution rules and people who can explain where the project is heading.

That community can improve the software and make knowledge easier to find. A strange error may already have a documented fix. A proposed change may be reviewed by people who understand several real-world uses. Competing ideas can be tested in public instead of remaining inside one supplier.

Community size is not the only signal. A focused library with two dependable maintainers can be a safer choice than a fashionable project with many unanswered issues. Look at governance, the number of people able to release, the clarity of the roadmap and the project response to difficult changes.

Then assess your own dependence. If the project stopped tomorrow, could the business remain on the current version while planning a move? Could it fund a fix, maintain a fork or replace the component? The more central the software is to revenue, safety or compliance, the stronger that continuity answer needs to be.

Open source gives the organisation more routes than a closed product that simply disappears. Those routes still need skills, time and money.

07

Open source and bespoke software work together

Bespoke software does not mean every line must be invented for one customer. It means the system is designed around that customer's users, workflow, data and commercial requirements.

A bespoke portal built with Laravel, Vue and PostgreSQL is still bespoke because the valuable application logic belongs to the business problem. The open source foundation provides proven building blocks. The development team remains responsible for architecture, configuration, tests, security, deployment and support.

That separation should be clear in contracts and handovers. The customer may own the custom source code created for the project while third party components remain governed by their existing licences. Paid services, fonts, stock assets and APIs may have their own continuing terms and costs.

The application also needs a dependency record. Another developer should be able to see what major components are used, which versions are supported, how to reproduce the build and what must be checked during an upgrade. A folder full of source code without that operational context is not a complete handover.

Open source can make a custom system easier to take over because the technology and documentation are publicly available. Poorly structured code, missing deployment access and an unmaintained dependency tree can remove that advantage very quickly.

08

Should a business publish its own code?

Using open source does not require a company to publish all of its own software. A business can build proprietary applications using appropriately licensed open source components.

Publishing some internal work can still make sense. A general library may attract improvements, help recruitment or prevent several teams from maintaining private copies of the same tool. A company can contribute fixes upstream instead of carrying a permanent private patch.

The decision needs preparation. Remove credentials, customer data, private infrastructure details and anything the company does not own. Choose a licence that matches the intended use. Add a clear README, contribution guidance, security reporting route and named maintainers. Check employee and third party intellectual property before publishing.

Do not open source a neglected repository and call it community building. Once other people depend on the project, unclear ownership and silent abandonment create real costs. Publishing code is a small governance commitment, even when the organisation makes no promise of commercial support.

Sometimes the right contribution is smaller. Report a useful issue, improve documentation, fund maintenance or submit a focused fix to a project the business relies on. Open source participation does not need to begin with releasing an entire product.

09

Choose open source deliberately

Open source software gives people legal permission to inspect, use, modify and share code under stated conditions. That is different from code merely being visible and different again from software having no purchase price.

For a business, the real benefit is choice. It can build on established tools, inspect important behaviour, draw from shared knowledge and avoid recreating every layer of a system. The real responsibility is ownership. Licences must be understood, dependencies tracked, security updates handled and continuity planned.

Open source is not somebody else's free engineering team. It is a way of sharing software that creates useful freedoms. A dependable business takes those freedoms seriously enough to manage the code it chooses.