Contributing a bank fix under a DCO, a trade secret, and a pending patent
Priya, a platform engineer at Meridian Bank, fixes a race condition in Trellis, an Apache-2.0 project the bank runs in production. Trellis requires a Developer Certificate of Origin sign-off on every commit, publishes a CONTRIBUTING.md that forbids mixing refactors with behavior changes, and asks for a design proposal before public API changes. Priya's branch bundles a 400-line refactor, the race fix, and a new public API method. It also copies an algorithm from an internal Meridian library; Meridian treats that algorithm as a trade secret and has a pending patent application covering it. Priya's manager suggests pushing the patch from her personal GitHub account with a personal email so the contribution 'isn't a bank legal problem,' and notes the DCO is 'just a checkbox.' The Trellis maintainer has commented that the PR mixes concerns and asks for a design discussion first.
1. Evaluate the manager's suggestion to contribute from a personal account.
Read the worked answer
The personal-account idea does not change the legal analysis and adds new problems.
- Ownership follows employment and policy, not the GitHub handle. Work created within Priya's scope of employment, using bank time, systems, or information, is generally the employer's under her employment agreement and IP policy. Contributing it from a personal account does not transfer title; it may amount to unauthorized disclosure of bank IP.
- The DCO is a representation, not a checkbox. Signing off certifies the right to submit the contribution under the project's license. If the bank owns the code and has not approved its release, the sign-off is inaccurate. That is a false certification to the project and a compliance event for Meridian regardless of which email is used.
- Apache-2.0 carries a patent grant. Contributing code covered by a pending Meridian application would grant downstream users a patent license. That is a commercial decision for the bank, not for Priya or her manager.
- Audit and reputation risk: a pseudonymous contribution later traced to the bank looks like deliberate circumvention, which is worse than a disclosed, approved contribution.
Correct route: file an IP-clearance request with the open-source program office or legal, obtain written approval, confirm the contribution is within policy, and submit under Priya's real identity with the corporate address the policy requires. The DCO sign-off then accurately represents the bank's approval.
2. What must Priya resolve about the copied algorithm, the patent application, and the DCO before anything is pushed?
Read the worked answer
Three blockers, cleared in order.
- Copied internal code. The algorithm cannot go upstream while it is a trade secret. Either rewrite the fix independently from the public bug report and Trellis's existing code so that no bank trade secret is included, or have Meridian approve open-sourcing that specific implementation, which requires IP review and possibly a patent-strategy decision. Renaming variables is not a rewrite.
- Pending patent application. If the contribution practices a claimed invention, the Apache-2.0 patent grant runs to all recipients. Legal must choose to contribute and accept the grant, contribute a design-around, or withhold the patent-related portion. This decision must precede the sign-off, because the sign-off is the representation that the right to submit exists.
- DCO. Priya signs off with her real name and email, certifying she has the right to submit under Apache-2.0 and that the contribution is hers or properly attributed. The certification must be true when made, so clearance comes before the commit, not before the merge.
Practical sequence: open an internal contribution request naming project, license, files, and patent status; obtain written approval; remove the copied algorithm; add Signed-off-by to every commit with git commit -s; keep identity consistent with policy. If approval is refused, do not contribute; the fix can still live as a private patch under the project's license.
3. How should Priya respond to the maintainer's scope objection and sequence the work?
Read the worked answer
Engage on the maintainer's terms; the technical content is not the only thing under review.
- Acknowledge the scope problem in the PR and split the work: the race fix as a minimal diff with a regression test that fails before and passes after; the 400-line refactor as a separate PR only if the maintainer wants it; the new public API as a design proposal first.
- Write the design proposal covering the problem, proposed signature, alternatives, compatibility impact, and a deprecation and migration path. CONTRIBUTING requires this before API changes, and the maintainer has already signalled that the API needs a cycle. The race fix should not wait for the API.
- Follow project conventions: commit message format, sign-off trailer, tests, changelog entry, and documentation. A refactor bundled with a bug fix is unreviewable and, per CONTRIBUTING, likely to be closed.
- Keep the discussion public and technical. Do not explain the bank's internal constraints beyond noting corporate approval; if the patent position limits what can be contributed, contribute the reduced patch rather than narrating why.
- Track the outcome: if the race fix is accepted, plan to drop the internal patch at the next release; if it is rejected, record the reason and keep the patch maintained internally with a note to revisit.