How to assess source-available security software

A readable repository does not give your team the rights or the operational independence that open source does. Before adopting source-available security software, treat the license, release process, and commercial boundary as parts of the security architecture. A restriction that looks harmless during a proof of concept can become the reason you cannot deploy a hotfix, serve a customer, or keep running after the vendor changes direction.

I have seen teams spend weeks on cryptographic design and half an hour on the license attached to the code that holds their secrets. That order is backwards. Your review should answer one concrete question: if this vendor, repository, and commercial relationship all change under you, what can your organization legally and technically continue to do?

This is an engineering review with legal input, not a request for engineers to practice law. Engineers must map how the software actually runs, who touches it, and what failure recovery requires. Counsel can then assess a real deployment instead of a vague statement that the source is visible.

How does the license classify the software?

Start by naming the license category correctly because "source-available" and "open source" grant different rights. Public code is a delivery fact. Open source is a licensing claim that includes the rights to use, modify, and redistribute software without discrimination against people, groups, or fields of endeavor.

The Open Source Initiative's Open Source Definition makes that distinction useful. Its criteria require access to source, but they also require derived works, free redistribution, and no restriction on a field of endeavor. A license that forbids production use, competing services, or a class of business may still publish every line. It does not meet that definition.

Do not use "open source" as a friendly synonym for "we can read the repository." Record the exact license name, version, and identifier. Then record whether the Open Source Initiative approves it. The SPDX License List helps identify license texts consistently, but presence on that list alone does not mean approval. The list has a separate OSI-approved field, and it includes licenses such as BUSL-1.1 and Elastic-2.0 without marking them as OSI approved.

This distinction affects more than vocabulary. Your dependency scanner may allow Apache-2.0 automatically while routing a custom source-available license to manual review. Your procurement policy may permit modification only when redistribution rights are clear. An incident responder may assume the team can patch and deploy a visible codebase, even though the license prohibits that production use.

Capture the result in one sentence that nobody can soften later: "The code is available under [exact license], which [is/is not] OSI approved, and our intended use depends on [specific grant or restriction]." If the team cannot fill in that sentence, it has not completed the first review.

What does the license allow in our real deployment?

Read the operative license text against a deployment diagram, not against the vendor's summary page. Terms such as "production," "managed service," "competitive offering," "internal business purpose," and "authorized user" only become meaningful when you attach them to processes, accounts, customers, and data flows.

Draw the boundary around every legal entity and every person who will use or receive the software's function. A parent company, subsidiary, contractor, managed service provider, and customer may sit in different positions under the same clause. If an agent makes an API call on behalf of a customer, ask whether the customer receives the source-available product as a service or merely receives the result of your own product. Do not settle that question with a sales chat message.

Business Source License 1.1 shows why the filled-in parameters matter. Its standard text grants copying, modification, derivative works, redistribution, and non-production use. A licensor may add a limited production grant, and each version later changes to a named open source license on a specified Change Date or by the license's outside deadline. The practical permission therefore lives partly in the license header for that product and version. Reading a generic BSL explainer without reading the Additional Use Grant and Change License leaves the important terms unknown.

Elastic License 2.0 takes a different shape. Elastic's own FAQ says the license allows use, modification, derivative works, and redistribution but restricts offering the products as a managed service, bypassing license-key functions, and removing notices. That does not tell your team whether its exact hosted architecture is permitted. It tells you which boundary needs a written answer.

Test at least these concrete states in prose: internal evaluation, production for your own staff, production supporting a paid customer, access by a contractor, redistribution in an appliance, disaster recovery in another entity, and a fork with local changes. For every state, record allowed, prohibited, or unresolved, followed by the controlling clause. "Free for most use" is not a result.

Ambiguous language is a deployment risk. Ask the vendor for a written interpretation tied to your diagram, then have counsel decide whether that answer is enough. If the vendor will grant an exception, put it in an executed agreement and state which versions it covers. A forum reply can disappear; your obligations will not.

Separate copyright permissions from the rest of the deal. A repository license may allow a use while a subscription agreement, terms of service, trademark policy, patent clause, export term, or support contract imposes other conditions. Collect every document incorporated by reference and establish which one controls if they conflict. The click-through accepted by the account owner belongs in the review alongside the LICENSE file.

Patent language deserves attention in security infrastructure because implementation often touches authentication, encryption, networking, and device management. Ask whether the license grants an express patent license, whether that grant ends after a patent claim, and whether contributors have authority to provide it. Source visibility alone grants no patent rights. Counsel should assess this point when the product sits in a distributed offering or when your planned fork changes how the software works.

Map dependencies separately from the main repository license. A permissive top-level license cannot cure an incompatible library, a nonredistributable model or ruleset, a font with packaging limits, or a binary-only helper required in production. Generate the dependency license inventory from the release you will ship, then investigate entries marked unknown, custom, or NOASSERTION. The word "optional" does not help when your deployment requires the component.

Keep contract promises out of the license column. Support response targets, security notification duties, source delivery dates, and price protections may make adoption acceptable, but they normally bind specific parties for a defined term. License rights may attach to each copy and survive longer. Your record should say which protection comes from which document and what happens when the contract expires.

This separation exposes a common bad recommendation: accept the license now because procurement can negotiate an exception later. It is popular because it lets a proof of concept move quickly. It is wrong once real data, customers, or automation depend on the software, because the vendor then knows your switching cost. Resolve required rights before the technical integration creates that pressure.

Can we inspect, build, patch, and ship the same thing?

Code visibility supports inspection, but security ownership requires a longer chain of rights and capabilities. Your team needs to know whether it can obtain the complete source, reproduce the relevant artifact, change it, test it, deploy the changed build, and distribute it wherever recovery demands.

Vendors often publish a useful core while omitting build infrastructure, signing steps, generated files, premium modules, or the packaging used for official releases. That repository can still help researchers understand a parser or check a cryptographic call. It cannot support an emergency fork if the released binary depends on unavailable pieces.

Run a clean-room build on a machine that has no developer's private cache. Pin the commit or tag, save the commands, and compare the resulting package with the vendor release. Exact byte reproduction is excellent when the project supports it, but a documented, explainable difference may be acceptable. An unexplained binary that contains files absent from the corresponding source is not acceptable for a component trusted with credentials or audit evidence.

Use a small evidence record rather than a screenshot of a successful build:

release: 4.2.1
source_ref: refs/tags/v4.2.1
source_commit: 8f2c...91a
build_command: ./scripts/build-release
artifact: dist/tool-4.2.1.pkg
artifact_sha256: 1c71...0be
vendor_sha256: 93a4...82d
comparison: differs
explained_differences: signing envelope, build timestamp
unexplained_files: none
patch_deploy_allowed_by: License section 2, counsel ticket LEG-184

The record forces two separate findings. "We managed to build it" is technical. "We may run and redistribute our build" is legal. Teams routinely blur them and discover the missing half during an incident.

Check the security update path too. Can you apply a one-line fix to the last version your organization is allowed to run? Can you sign or otherwise authorize the patched artifact in your fleet? Will plugins, agents, or servers reject a non-vendor build? If the software protects secrets, a fork that cannot receive credentials from your surrounding systems is not an exit path.

Finally, inspect contributor terms. A Contributor License Agreement may let the vendor relicense contributions while outside contributors cannot use future commercial code. That arrangement can be legitimate, but it changes who can carry the project after a split. Record whether contributions use a Developer Certificate of Origin, a copyright assignment, a broad CLA, or no stated process.

Do releases match the public repository?

A security review applies to a specific artifact, not to a repository in the abstract. Require a reliable mapping among the version you install, the source commit, the license text, the dependency set, and the security notices for that release.

Start with release history. Look for signed tags or another authenticated release mechanism, changelogs that identify security changes, maintained release branches, and a repeatable delay between a binary release and its source. One late source drop may be a mistake. A standing gap means the public repository is not the production source of truth.

Ask the maintainer to state the release schedule and support window in durable documentation. "Frequent updates" says nothing. You need to know which branches receive security fixes, how long old releases remain supported, whether fixes appear in source before or after customer binaries, and whether a disclosure embargo can leave self-builders exposed. Do not invent a service-level promise from past activity.

Compare three recent releases rather than inspecting only the newest tag. For each one, answer four questions:

1. Does the tag resolve to the source used for the shipped artifact?
2. Are build instructions and dependency locks present at that tag?
3. Did the license or commercial feature boundary change?
4. Can a fresh environment produce a runnable package?

Save the results in your engineering decision record. Re-run the comparison at renewal and before a major upgrade. Source availability can regress quietly when a vendor moves packaging to a private system or shifts a feature behind a commercial repository.

A software bill of materials helps, but do not accept it as proof of source parity. An SBOM describes components in an artifact. It does not prove that the published repository contains the code, build logic, or rights needed to recreate that artifact. Use both: the SBOM for dependency and vulnerability work, and the source-to-artifact mapping for independence.

Release cadence also tells you how much maintenance your team may inherit. A project with monthly feature releases and fixes only on the newest branch can force fast upgrades. A slower project with a documented backport policy may be easier to operate. Count the work imposed on your team, not the number of releases advertised by the vendor.

Where is the commercial boundary today and tomorrow?

Planned commercial features matter when they sit on your security path, even if they do not exist yet. Ask the vendor to divide the product into current open or source-available code, current paid code, and planned paid code, then connect each part to your required controls.

Avoid the vague question "Will the core stay free?" The answer can be yes while the features you need for safe team use move elsewhere. Ask about identity integration, centralized revocation, policy administration, audit export, retention, high availability, fleet management, incident support, and migration tooling. The relevant set depends on the product, but the method stays the same: map each operational requirement to a shipped component and its license.

Roadmaps are not contracts, and absence from a roadmap is not a promise. Record planned features as planning signals with an owner, expected delivery window, intended license, and fallback. If your adoption depends on a future enterprise control, price and approve the commercial path now or treat the control as unavailable. A team should not deploy a weaker design because a slide says the missing safeguard is coming.

Watch for license-key checks or remote entitlements in otherwise visible code. Determine what happens when the licensing service is unreachable, the subscription ends, the vendor closes, or your organization runs a patched fork. The desired behavior may be continued read access, export, and safe shutdown rather than indefinite paid functionality. Whatever your requirement is, test it.

Also ask who owns the protocol and data format. A commercial console is replaceable when agents can speak a documented protocol and export complete records in a stable format. It is much harder to replace when the visible core stores opaque state or when the paid service issues the credentials required to start. Public code around a private control plane may offer little operational independence.

Sallyport gives a clean comparison because its current macOS app is fully open source under Apache-2.0, while commercial Enterprise components are planned. That statement does not answer what future team features will cost or include, so an adopting team should assess the shipped app under its current license and treat planned components as unknown until their boundaries are published.

Can the project change the deal after adoption?

A licensor can usually release future versions under different terms if it controls the relevant copyrights. It cannot normally erase the license already granted for a version you possess, but staying on that version may leave you without fixes, compatibility work, or new protocol support.

This is where "they cannot take the code away" becomes a weak comfort. Your actual choice may be to accept new terms, freeze on a vulnerable branch, or fund a fork. Evaluate those costs before adoption, while declining the software is still cheap.

Inspect repository governance and copyright concentration. Who can merge? Who cuts a release? Can outside maintainers publish a compatible distribution? Does one company own nearly all copyrights through employment and contribution agreements? A company-led project can be well maintained, but concentrated control makes a future license change easier and a community continuation harder.

Review the project's history for license changes, moved modules, deleted tags, delayed source releases, and features transferred between repositories. Do not treat any change as automatic misconduct. Ask whether the pattern matches your tolerance and whether previous users received notice, a transition period, and a usable last version.

Then put monitoring around the inputs that can change:

• Hash and retain every accepted license text and product-specific parameter file.
• Alert when dependency metadata reports a new license expression.
• Review release notes for repository or entitlement changes.
• Reapprove major versions before production rollout.
• Keep the last approved source and build instructions in your own controlled storage.

These controls turn a licensing promise into something engineering can observe. They also stop a routine dependency update from importing new obligations without review.

Do not rely on a vendor's public promise that a license will never change unless your risk decision explicitly accepts that promise as nonbinding. If stable rights are essential, prefer a standard OSI-approved license for the needed code or negotiate terms that survive the commercial relationship. Good intentions are not a substitute for durable permission.

Is there a credible exit path?

A credible exit path lets you keep the security function running long enough to migrate without violating the license or depending on a service that may vanish. A public repository is only one ingredient.

Test the exit as an incident exercise. Assume the vendor publishes no more releases, disables its licensing endpoint, and stops answering support requests on the same day. Your team should identify the last permitted version, restore source and dependencies, build an artifact, load existing configuration, recover or migrate protected data, and operate it under your own signing and deployment process.

For security software, include secrets and audit records in the exercise. Can you export them in a documented format? Does export require a paid service or a still-valid entitlement? Can a locally built version decrypt existing state using keys your organization controls? Can you verify old audit records without the vendor? A design that protects data from the vendor may still trap data inside a proprietary format.

Forking also needs people. Name the team that would own the code, estimate the languages and platform knowledge required, and identify dependencies that could not be redistributed. If nobody can accept that work, write "migration only" instead of pretending the repository is a fallback.

Trademarks deserve a separate line in the plan. Software licenses commonly grant code rights without granting brand rights. Your fork may need a new name, package identifier, signing identity, update channel, and documentation. That is manageable when planned, and disruptive when discovered during a rushed release.

A delayed transition to open source can improve the long-term position, but inspect it per version. Under BSL 1.1, each version has its own Change Date and the license applies separately to each version. The old release that has converted may lack the security fixes present in a newer restricted release. "Eventually open source" does not mean the maintained version is open source when you need it.

Set an exit objective that can be tested: for example, "Within ten business days, we can rebuild the last approved release, deploy a local patch, export all organization data, and begin migration without vendor infrastructure." Choose a time that matches your risk, then run the exercise. If the test fails, either fund the missing capability or record vendor dependency as an accepted risk.

Who owns security response when source is visible?

Visible source does not assign responsibility for triage, disclosure, patching, or customer communication. Ask who receives vulnerability reports, which versions receive fixes, how embargoed issues reach licensed users, and whether your team may create and distribute an emergency patch.

Read the security policy in the repository and compare it with actual release practice. A useful policy names supported versions, a private reporting route, expected acknowledgements, and the disclosure process. If the policy says only "open an issue," sensitive reports may become public before a fix exists. If it promises response times, determine whether those are goals or contractual commitments.

Clarify what the vendor expects from self-builders. Some vendors support only their signed distribution even when the license permits modifications. That may be reasonable, but your runbook must show where vendor support ends after a local patch and how you return to a supported build. Otherwise an emergency fix creates an indefinite private branch that nobody owns.

Security claims should be traceable to code and tests. For a credential gateway, inspect where plaintext exists, which process performs an outbound action, how approval state is bound to a caller, and what the audit log proves. Source access makes those questions answerable; it does not make favorable answers automatic. Test the behavior at process boundaries, not just the function that encrypts a value.

Ask for threat models, architecture notes, dependency update practice, and external assessment reports if they exist. Do not reject a young project merely because it lacks a polished report, and do not award trust for a badge without scope. Record which claims your team verified, which rely on the vendor, and which remain untested.

Assign an internal owner before production. That owner watches security advisories, license changes, release drift, and the commercial boundary. Without an owner, public source creates the feeling that someone can inspect it while everyone assumes someone else has.

What should the adoption record contain?

The final decision should fit in a record that engineering, security, procurement, and counsel can each challenge. A long chat thread is not an adoption record because it loses version scope, assumptions, and unresolved questions.

Use this compact checklist for the approval meeting:

• Identity: exact product version, source commit, artifact digest, license text digest, SPDX expression, and OSI status.
• Rights: allowed and prohibited uses for evaluation, internal production, customer-facing production, modification, redistribution, contractors, and affiliates.
• Operability: clean build result, source-to-artifact differences, signing path, data export, dependency archive, and patch deployment test.
• Vendor path: supported branches, release and disclosure practice, current paid boundary, planned commercial dependencies, and written interpretations.
• Exit and ownership: migration objective, fork or migration owner, accepted residual risks, review trigger, and approval expiry.

Give every unresolved item an owner and a deadline. Mark assumptions plainly. If counsel is waiting for an answer about managed-service use, the decision is conditional, not approved. If a planned commercial feature controls audit retention, put its absence in the security exception instead of hiding it in roadmap notes.

Reject adoption when the license clearly prohibits the intended use, when the shipped artifact cannot be tied to available source, or when required data cannot leave vendor-controlled infrastructure. Pause when a material clause is ambiguous. Accept vendor dependence only when the organization understands its cost and has chosen it, not because the repository looked reassuring.

Reopen the record on a major version, license text change, ownership change, new commercial dependency, material architecture change, or failed exit test. Set a review date even if none of those events occur. Security software often becomes infrastructure quietly, and an easy replacement during evaluation can become a hard dependency after agents, credentials, and audit workflows grow around it.

The strongest outcome is not always adoption of the most permissively licensed product. A restricted product with clear terms, responsive maintenance, and a funded migration plan may fit your organization better than an abandoned open source project. The decision is sound when the team can state exactly which rights it has, which capabilities it depends on, and what it will do when either changes.