Open source can reduce the time and capital needed to build software, but it does not remove ownership, licence or governance obligations. A product may combine employee-created code with hundreds of external components, each carrying its own provenance and conditions. The business advantage therefore depends on an evidence architecture that connects assignments, authorship, component inventory, licence review, security maintenance and release decisions.

Widespread adoption changed the management question

On 5 June 2025, Forbes Russia examined the ownership and licensing risks surrounding open-source software. It reported one estimate that 83 percent of Russian companies used or planned to use OSS and another that open-source components appeared in about 98 percent of computer programs.

Those figures came from different estimates and should not be fused into one market statistic. Together, however, they describe a practical reality: external code is no longer an unusual exception handled by a specialist team. It is part of ordinary software production.

The old question was whether a company should permit open source. The more useful question is how it can use open components deliberately while preserving the right to distribute, support and monetise the result.

That change moves the issue out of a narrow legal review at the end of a project. Engineering, product, procurement, information security, human resources and finance all create evidence that determines whether the product is an asset or a bundle of unresolved claims.

Free access was not the same as unrestricted use

The word free causes avoidable confusion. A component may be available without an acquisition fee while remaining protected by copyright and governed by a licence. The licence grants permissions under stated conditions; it does not erase the author's rights.

Permissive licences may require preservation of copyright notices or licence text. Copyleft licences can require source availability or distribution of derivative work under compatible terms. Network-use provisions, patent clauses and attribution duties add further dimensions.

This does not mean that a copyleft component can never support a commercial product. Software can often be sold under open terms. The commercial constraint arises when a company expects exclusive proprietary distribution that conflicts with obligations attached to the incorporated code.

Management therefore needs a precise model of use. Running a tool internally, linking a library, modifying a component, embedding it in a device and delivering a hosted service can produce different obligations. A licence name alone is not a complete risk assessment.

Employee code required a chain of title

The source highlighted a second misconception: code created during working time does not automatically settle ownership. In Russia, the employer's position depends on whether the work falls within documented employment duties and whether the company can prove the assignment and acceptance process.

A repository commit shows that a person changed a file. It does not by itself show why the work was commissioned, which legal entity employed the author, whether the task belonged to that role, or whether compensation requirements were met.

The evidence chain begins before coding. Employment contracts and job descriptions define the field of work. Internal policies define how service assignments are issued. Task records connect a specific feature to that framework. Acceptance records show that the result entered the company's product.

Separate author remuneration may also need to be documented. The operational lesson is not that every commit needs a paper ceremony. It is that the organisation must design a repeatable process whose digital records can demonstrate title without reconstructing events years later.

A repository was only one part of the evidence system

Version control is indispensable, but legal provenance cannot be delegated entirely to it. Repositories show history at file and commit level; employment systems, contractor agreements, procurement records and release approvals supply different parts of the story.

The company should be able to move from a shipped binary back to its build manifest, source revision, contributors, assignments and external dependencies. That relationship is closer to product traceability in manufacturing than to simple document storage.

When records use inconsistent project names or sit under different subsidiaries, the chain breaks. A parent company may fund development while another entity signs employees and a third entity sells the product. Without explicit transfers or licences, the commercial entity may not control what it markets.

Acquisitions create the same problem at larger scale. Due diligence should test whether historic contributor agreements, contractor assignments and component records support the rights represented in the transaction price.

The component inventory became a commercial control

A software bill of materials, or SBOM, is often discussed as a cybersecurity artefact. It also supports licence compliance and commercial diligence by identifying components, versions, origins and relationships in a release.

An inventory should not be a spreadsheet created once for an audit. Modern builds resolve nested dependencies automatically, and the dependency graph changes as maintainers publish updates. Evidence must be generated from the build and retained with the release.

Useful records connect each component to its source, version, licence, modifications, notices, approval status and responsible owner. They also record whether the dependency is present in development only or distributed to customers.

Completeness matters more than visual polish. A beautifully formatted list that omits transitive libraries gives false confidence. Automated discovery can find most dependencies, while human review resolves ambiguous metadata, unusual linking patterns and conflicting terms.

A drawn cutaway shows a software product assembled from modular components above a provenance trail, with one incompatible module isolated from the release
Commercial readiness depends on the evidence below the product as much as on the modules visible inside it.

Compatibility had to be tested as an architecture

Teams sometimes classify licences as green, amber or red. That is useful for triage but too crude for final decisions. Compatibility depends on how components interact, what is distributed, what has been modified and what obligations the company can fulfil.

A permissive library may be easy to approve but still contain a notice requirement. Two individually acceptable components may create a conflict when combined. A tool used only during compilation may have a different impact from code copied into the shipped product.

The architecture review should therefore map legal boundaries alongside technical ones. Process separation, dynamic linking, service interfaces, plug-in models and independent programs can matter, but none should be adopted as a superficial workaround without qualified analysis.

The desired output is not a declaration that open source is safe. It is a documented explanation of why this particular release, in this distribution model, satisfies its obligations.

Substantial modification was not a universal percentage test

The Forbes article described significant functional change and mentioned 20 to 30 percent new code as one possible quantitative illustration. That should not become an automatic safe harbour. Copyright originality and registry eligibility cannot be reduced to a universal line-count ratio.

Ten percent of strategically original orchestration can matter more than half a codebase of routine adaptation. Conversely, large mechanical rewrites may create little independent creative value. File counts also vary with generated code, vendored libraries and formatting changes.

A company seeking exclusive rights in its additions should document the new functions, architecture, modules and engineering choices it contributed. Comparative technical descriptions, design records and commit history can show the nature of the work more convincingly than one percentage.

Open components do not prevent a company from owning its original layers. The discipline lies in drawing the boundary accurately and not claiming exclusivity over material that remains governed by its original licence.

Registry eligibility was a separate design constraint

The Russian software registry can influence tax treatment, public procurement and access to support measures. The source noted two core conditions: a resident company must hold exclusive rights to the product, and open-licence restrictions must not block its distribution in Russia.

Registry readiness should be designed before submission. If ownership gaps and incompatible terms appear only during the application, rewriting the product or renegotiating contributor rights can delay market access.

The dossier must align legal claims with technical reality. The named right holder, development records, architecture description, component inventory and distribution model should tell the same story.

Inclusion is not a permanent substitute for compliance. Components change, licences can differ between versions, and a later release can introduce obligations absent from the reviewed edition. Product governance continues after registration.

Export and sanctions clauses needed current review

The source also warned that some licence texts or supplier policies may carry territorial or sanctions-related restrictions. This is not a reason to assume that every foreign-origin component is unusable. It is a reason to record jurisdiction, obtain current advice and avoid relying on an outdated download page.

Open-source projects can have several relevant actors: individual authors, a foundation, a commercial steward, package hosts and infrastructure providers. The source-code licence may remain available while paid updates, binary repositories, cloud access or support are restricted.

Business continuity planning should distinguish those layers. A company may have the legal permission to use code but lack reliable access to patches or build infrastructure. A mirror without a maintenance capability preserves files, not necessarily a sustainable product.

Critical components therefore need replacement options, internal build reproducibility and named maintainers. Jurisdiction risk becomes an engineering and supply-chain issue as well as a legal one.

Security and licensing shared data but not decisions

The same component inventory can support vulnerability scanning and licence review, yet the two controls answer different questions. A permissively licensed library can contain a critical vulnerability. A secure, actively maintained library can still conflict with the intended distribution model.

Combining the workflows is efficient when their conclusions remain separate. Security teams track vulnerabilities, exploitability and remediation. Legal reviewers track rights, notices and reciprocal obligations. Product owners decide whether the residual risk fits the release.

A component with no known vulnerability is not automatically safe if it is abandoned. Maintenance cadence, contributor concentration, release signing and response history help estimate future exposure.

Likewise, replacing a licence-risk component can introduce technical instability. A controlled change needs regression testing, performance review and a fresh inventory rather than a last-minute file substitution.

The approval path belonged inside delivery

End-of-project review is slow because it discovers decisions after they have become expensive. Controls work better when they meet developers at the moments dependencies enter, change and ship.

A practical release gate

A proportionate workflow can be implemented through a small number of repeatable checks:

  1. Declare a new dependency through the normal package or architecture review and capture its source and intended use.
  2. Generate a machine-readable component inventory from reproducible builds, including transitive dependencies.
  3. Apply automated policy rules, then route ambiguous licences and unusual combinations to human review.
  4. Confirm employee and contractor title for original modules and preserve assignments, acceptance and transfers.
  5. Produce required notices and source-delivery materials as build artefacts rather than manual afterthoughts.
  6. Block release when a critical ownership, licence or vulnerability issue has no accepted resolution.

The gate should vary by exposure. An internal experiment needs less ceremony than firmware distributed to thousands of customers. Proportionality keeps controls usable without making high-risk distribution invisible.

Exceptions needed owners, dates and exit paths

A mature policy does not pretend that every dependency will match a preferred list. Exceptions are sometimes rational when a component is uniquely capable, replacement would create greater risk, or a temporary bridge is necessary.

An exception should identify the approving owner, affected releases, reason, compensating controls, review date and exit condition. “Known issue” is not a decision record.

Time limits prevent temporary compromises from becoming permanent architecture. The product roadmap should include replacement, relicensing or contribution upstream where appropriate.

Metrics should expose the backlog: unresolved components, expired exceptions, releases without complete inventories, time to remediate and concentration in unsupported dependencies. Counting approved packages alone rewards paperwork rather than risk reduction.

Governance had to preserve developer speed

A policy that requires a legal ticket for every common library will be bypassed. The objective is to make the compliant path the easiest path through pre-approved components, clear guidance, automated scanning and rapid escalation.

Developers need to know why a component is restricted and what alternatives exist. Legal teams need technical context about linking, modification and distribution. Product managers need visibility into schedule and commercial consequences.

Training should use real decisions rather than abstract licence taxonomy. A short scenario about adding a library to a customer-delivered appliance is more useful than memorising dozens of licence names.

Contributing fixes upstream can also reduce private maintenance and demonstrate responsible participation. Contribution rules must still protect confidential information and confirm that employees are authorised to submit company-created work.

Due diligence converted records into enterprise value

Investors, acquirers and enterprise customers increasingly ask how software was built. A complete answer can shorten diligence, support representations about intellectual property and reduce the discount applied to unresolved ownership.

The absence of a claim today does not remove latent risk. A former employee, contractor or component owner may challenge rights after a product becomes valuable. Contemporary records are stronger than retrospective declarations.

Good provenance also improves operational resilience. Teams can identify where a component is used, which customer releases contain it and who can approve remediation. The same traceability supports incident response and product lifecycle management.

Compliance spending therefore should not be measured only against avoided litigation. It creates faster releases, clearer acquisitions, more credible customer assurance and optionality across distribution models.

Open source became an operating capability

The strategic choice is not between proprietary purity and unmanaged reuse. Most valuable software combines original engineering, external components, commercial services and internal know-how.

A defensible organisation can answer six questions for every material release: who created the original layers, under what assignment, which external components are present, what permissions apply, which obligations were fulfilled, and who accepted the residual risk.

When those answers are generated by the delivery system, open source remains an accelerator. When they depend on memory and scattered documents, apparent development savings can reappear as delayed sales, failed registry applications, expensive remediation or contested ownership.

The real asset is therefore larger than the code. It is the code plus the evidence, processes and maintenance capacity that allow the company to use it lawfully, change it confidently and commercialise it on terms the business understands.