Can You Use This Self-Hosted Application for Your Business? An Open-Source License Due-Diligence Checklist
Self-hosting can change how an application is operated, but it does not by itself answer licensing, redistribution, trademark or source-disclosure questions. Use this practical checklist to build evidence, define your intended use and know when to seek qualified legal advice.
Self-hosting does not answer every licensing question
“Open source” is not a single permission level, and access to a public source repository is not enough to settle whether a business may use, modify, host, brand or redistribute an application in the way it intends. The Open Source Initiative (OSI) makes this distinction directly: open source concerns distribution terms as well as source-code access.
If an application is genuinely under an OSI-conformant open-source license, that license cannot restrict use in a particular field of endeavour, including business use. That is useful, but it is not the end of the review. Your deployment may include separately licensed components, assets or plugins; your planned activity may involve distribution; and names, logos and domains can be governed by trademark rules rather than the software license.
Treat this article as an operational due-diligence framework, not legal advice. The aim is to replace assumptions with a reviewable record and to identify the situations that warrant qualified legal advice before deployment.
- Do not equate “source available” with “open source.”
- Do not equate internal hosting with permission to redistribute copies to customers or clients.
- Do not assume a top-level repository license covers every item in the deployment.
- Review trademark and naming rules separately from software-license terms.
Start with the intended use, not the application feature list
Before reading license text, write down what your organisation will actually do. License questions become clearer when tied to a concrete deployment and distribution model rather than a general wish to “use the software commercially.”
A tool used only by your own staff presents a different fact pattern from a customer-facing service, a customised client deployment, or a product that bundles the application for redistribution. The same distinction matters if you plan to provide a Docker image, an installer, a modified source tree or a managed instance to someone else.
Make this statement specific enough that a colleague could test it against the license. If the intended use changes later, reopen the review rather than relying on the old conclusion.
- Internal tool: Who can access it, and will the team modify it?
- Customer-facing service: Will outside users interact with the application remotely?
- Client deployment: Are you handing over a copy, an image, source code or a modified build?
- Redistributed product: Are you bundling the application or substantial components into your own offering?
- Branding: Will you use the project name, logo or a similar name in a product, service or domain?
- Integration: What plugins, libraries, models, fonts, themes, connectors and assets will be included?
Read the license scope before comparing applications
Do not select an application by feature set and treat the stated license as a footnote. Read the applicable text for the work you will use, especially provisions concerning modification, reproduction, distribution, notices, patents and trademarks.
For example, Apache License 2.0 includes explicit conditions when copies or derivative works are reproduced and distributed. These include providing a copy of the license, marking modified files, retaining relevant notices, and preserving applicable NOTICE-file attributions. Those requirements are tied to reproduction and distribution, so an accurate assessment depends on whether your proposed delivery model reaches those activities.
License labels are not a substitute for analysing a planned combination. The GNU GPL FAQ describes license compatibility in terms of whether the relevant licenses permit the intended combination, and notes that the form of combination can matter. When your offering combines components in a way that is not clearly documented, that is a reason to pause rather than guess.
- Identify the covered work: the application, a plugin, a library, a container image or another artifact.
- Identify your actions: run, modify, copy, distribute, package, provide to a client or expose remotely.
- Read conditions and exceptions in the complete license text, not a summary alone.
- List required notices, source offers or modification markings that could apply to your model.
- Flag uncertain component combinations for specialist review.
Check dependencies, plugins, models, fonts and bundled assets separately
A top-level application license file may not resolve rights for everything that reaches your users or is included in your build. Apache’s licensing guidance, for example, recognises that third-party works can be included in a project product and that their license text may appear in LICENSE or NOTICE files or be available separately.
Build an inventory of what is actually deployed, not merely what appears at the root of the repository. Include runtime dependencies, build dependencies that are shipped in an artifact, optional plugins you enable, themes, fonts, datasets, model files and other bundled assets. Do not assume all such items have the same terms as the main application.
SPDX is useful as a documentation vocabulary and an SBOM format. Its relationship concepts include dependencies, dependency manifests, build dependencies, development dependencies and runtime dependencies. You do not need a perfect automated inventory before making a decision, but you do need enough evidence to identify the components that materially affect your intended use.
- Create a component row for each material dependency or bundled item.
- Record component name, version, source, license evidence and how it enters the stack.
- Distinguish runtime items from build-only and development-only items.
- Check enabled plugins and extensions separately from unused options.
- Look for bundled notices, license texts and attribution requirements.
- Mark unknown or custom components as blockers if they will be shipped, modified or exposed to clients.
Keep trademark, branding and domain decisions separate
A software license is not a blanket permission to use project names, logos or branding in any manner. Trademark analysis has a different purpose: avoiding confusion about source, affiliation or endorsement.
Apache’s policy illustrates this separation. It identifies project names, product names and logos as trademarks while the software itself is distributed under its software-license terms. For Apache projects specifically, derivative works should not use confusingly similar project names or project logos, and confusing use of Apache marks in domain names requires written approval.
Use the project’s own trademark policy where available. If you will put the application name in a customer offering, alter a logo, publish a branded fork, or register a related domain, add that plan to the evidence register and seek advice when the policy does not clearly cover it.
- Will the public-facing service use the project’s name or logo?
- Will you describe the service as official, affiliated or endorsed?
- Will a modified fork retain, replace or supplement existing branding?
- Does the planned domain contain the project or organisation name?
- Does the project publish a trademark policy or brand-use guidance?
- Is the intended presentation potentially confusing to users?
Understand network-service and source-disclosure questions precisely
Do not assume that making software available over a network always has the same effect as distributing a copy. GPLv3 states that mere interaction with a user through a computer network, with no transfer of a copy, is not itself “conveying” under that license text.
AGPLv3 contains a different, conditional provision for a modified version that supports remote network interaction. Section 13 requires the modifier to offer remote users an opportunity to receive the Corresponding Source of that modified version. This is not a reason to make broad claims about every hosted deployment; it is a reason to identify the exact license, whether you modified the covered program, and whether it supports remote interaction.
If your service includes multiple components, analyse the relevant component license and the nature of the integration. The GNU GPL FAQ notes that the boundary between separate programs and one combined program is ultimately a legal question. A non-obvious architecture is not a place for a casual compliance conclusion.
- Identify whether any remotely accessible component is under terms with network-interaction provisions.
- Record whether your team modified that component and where the modifications reside.
- Determine whether users receive a copy, interact only with a service, or both.
- Document how source access, notices and modification records would be provided if required.
- Escalate uncertain combinations, forks and source-disclosure obligations before launch.
Build an evidence register before deployment
A concise evidence register turns licensing due diligence into an operational control. It should enable another person to understand what was reviewed, where the evidence came from, what the organisation plans to do and what remains unresolved.
Keep the register with the deployment record and update it when you change the application version, activate a new plugin, modify code, switch an image, add a client-delivery model or change public branding. This is more useful than a one-time yes-or-no statement because self-hosted stacks evolve.
Use standard identifiers and SBOM information where available, but do not allow a familiar identifier to replace a review of the applicable text, notices and delivery model.
- Application or component name.
- Version, release, image reference or commit reviewed.
- Source URL and location of license evidence.
- Declared license identifier and link to the full text.
- Copyright, NOTICE and attribution observations.
- Dependency and relationship notes, including runtime and build items.
- Modifications made, planned or inherited.
- Distribution, client handover and remote-service plan.<br>Trademark, logo and domain plan.<br>Open questions, owner, escalation decision and review date.
Frequently asked questions
Does self-hosting an application mean we can use it commercially?
Not by itself. An OSI-conformant open-source license cannot restrict use in a particular field of endeavour, including business use. However, you still need to verify that the exact application and components are under the stated terms, and separately assess distribution, modifications, notices, trademarks and your specific deployment plan.
Is a public Git repository enough proof that an application is open source?
No. The OSI explains that open source means more than access to source code; the distribution terms must meet the Open Source Definition. Review the authoritative license evidence for the version you plan to use.
Do we need to review dependencies if the application has a LICENSE file?
Yes. Third-party works may have separate license text or notices. Inventory material runtime dependencies, shipped build outputs, plugins, models, fonts, themes and bundled assets, then record their license evidence and role in the deployed stack.
Does hosting GPL software for users automatically count as distribution?
GPLv3 says that mere network interaction with no transfer of a copy is not conveying. The precise result depends on the applicable license, the component and what you actually provide. Do not generalise this statement to every license or architecture.
What is different about AGPLv3 for a hosted service?
AGPLv3 section 13 includes a conditional obligation for a modified version that supports remote network interaction: remote users must be prominently offered access to the modified version’s Corresponding Source. Identify whether you modified the covered program and obtain qualified advice if application of the obligation is unclear.
Can we use the project name and logo in our hosted service?
That is a trademark and branding question, separate from the software license. Review the project’s trademark policy, especially before using a logo, marketing a modified fork, claiming affiliation or registering a related domain.
Sources and further reading
- The Open Source Definition — Open Source Initiative
- Apache License, Version 2.0 — Apache Software Foundation
- Apache Licensing and Distribution FAQ — Apache Software Foundation
- SPDX Overview — SPDX
- SPDX Specification: Relationships Between SPDX Elements — SPDX
- GNU Affero General Public License v3 — GNU Project / Free Software Foundation
- GNU General Public License v3 — GNU Project / Free Software Foundation
- GNU GPL FAQ — GNU Project / Free Software Foundation
- Apache Software Foundation Trademark Policy — Apache Software Foundation
- Docker Compose documentation — Docker