docs: clarify Computer's contribution, review, and licensing model

Summary

Computer is an incredibly useful project, and I would be happy to contribute to it. I recently reported a Gemini tool-calling bug in #224, including a reproduced failure, implementation guidance, and regression cases. While preparing that contribution, however, I could not determine the intended path for outside code contributions or how changes are reviewed.

That is especially important for this project because, by its own security model, an authenticated Computer user has access equivalent to SSH: full filesystem and shell access with no path sandboxing or per-user isolation.

To be explicit, this is not an accusation of misconduct, a claim that uncredited work is being used, or an assumption that private review does not happen. I am pursuing clarification because I would like to understand how to contribute responsibly and how to evaluate updates to software with this level of host access. The answers may be entirely straightforward; they simply do not appear to be documented publicly today.

Snapshot below is as of 2026-08-17, with main at 9c54711.

What I could verify publicly

One visible upstream author to date

GitHub's contributor endpoint reports one contributor with 647 commits:

$ gh api repos/open-webui/computer/contributors?per_page=100 \
    --jq 'map({login, contributions})'
[{"contributions":647,"login":"tjbck"}]

The local Git history resolves every commit to variants of the same name and email:

$ git log origin/main --format='%aN <%aE>' | sort | uniq -c
   1 Tim Baek <tim@openwebui.com>
   1 Tim J. Baek <tim@openwebui.com>
 645 Timothy Jaeryang Baek <tim@openwebui.com>

Contributor graph: https://github.com/open-webui/computer/graphs/contributors

Visible pull requests appear to be release promotions

There have been 82 pull requests. All 82 were authored by tjbck, with head main and base release:

$ gh api 'repos/open-webui/computer/pulls?state=all&per_page=100' \
    --jq 'group_by(.user.login)|map({author:.[0].user.login,count:length})'
[{"author":"tjbck","count":82}]

$ gh api 'repos/open-webui/computer/pulls?state=all&per_page=100' \
    --jq 'group_by(.base.ref)|map({base:.[0].base.ref,count:length})'
[{"base":"release","count":82}]

$ gh api 'repos/open-webui/computer/pulls?state=all&per_page=100' \
    --jq 'group_by(.head.ref)|map({head:.[0].head.ref,count:length})'
[{"head":"main","count":82}]

For example, #214 promotes main to release, has no description or review, and was merged about 16 seconds after creation: https://github.com/open-webui/computer/pull/214

This appears to mean that the repository's pull-request count and merge rate describe its release workflow rather than its outside-contribution or code-review process. If review occurs elsewhere, documenting that would resolve the ambiguity.

Contributors have reported difficulty opening PRs

• In #96, a contributor linked a complete branch and compare view and reported GitHub's CreatePullRequest permission error. The issue was later fixed, but the PR failure was not explained: https://github.com/open-webui/computer/issues/96
• In #201, another contributor linked a complete, tested branch and said they could not open a PR from their fork. The maintainer replied Addressed!, but again did not clarify the supported contribution path: https://github.com/open-webui/computer/issues/201
• In #196, a third contributor supplied a detailed implementation and offered to open a PR; the issue was subsequently addressed without a public external PR: https://github.com/open-webui/computer/issues/196

These examples show that issue-based contributions can influence the product, which is encouraging. They do not establish whether external PRs are accepted or explain why fork PR creation failed in those cases.

Questions not answered by the current documentation

At the referenced commit, the repository has:

• no CONTRIBUTING.md describing the supported contribution path;
• no CODEOWNERS or documented reviewer roster;
• no Computer-specific SECURITY.md or documented inheritance of the parent project's policy;
• no pull-request-triggered test or lint workflow—the existing workflows publish Docker/PyPI/releases on pushes to main or release;
• a PR template requiring acceptance of a broad CLA, despite there being no visible external PR precedent.

Relevant files:

• PR template: https://github.com/open-webui/computer/blob/main/.github/pull_request_template.md
• CLA: https://github.com/open-webui/computer/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT
• Workflows: https://github.com/open-webui/computer/tree/main/.github/workflows
• Security model and source-available license statement: https://github.com/open-webui/computer/blob/main/README.md#security-model

Contribution licensing is also unclear

Computer is distributed under the Open Use License and describes itself as “source available” with “all rights reserved,” rather than under an OSI-approved open-source license. Its CLA grants Open WebUI Inc. broad, perpetual rights to use, modify, sublicense, and commercialize contributions.

That arrangement is not inherently improper, and this issue is not challenging the project's choice of license. It does make a clearly documented contribution process particularly helpful: prospective contributors should be able to understand what rights they retain, how authorship is recorded, and how acceptance of the CLA works.

This is unclear when someone cannot open a PR and instead provides patches, code snippets, or links to branches in an issue. The CLA says it applies to contributions submitted “to this repository in any form,” while the PR template's checkbox appears to be the documented mechanism for confirming agreement. It is not clear whether issue comments or linked branches are treated as CLA-covered submissions, or how affirmative acceptance is recorded in that workflow.

References:

• License: https://github.com/open-webui/computer/blob/main/LICENSE
• License description: https://github.com/open-webui/computer/blob/main/README.md#license
• CLA: https://github.com/open-webui/computer/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT

Questions for the maintainers

1. Are pull requests from external forks currently accepted? If so, what exact workflow should contributors use, and why did the attempts in #96 and #201 fail?
2. Are changes on main reviewed by anyone other than their author before release? If review happens privately, can the review and release policy be documented?
3. Are outside patches rewritten or squash-applied under the maintainer's authorship? If so, how is contribution attribution preserved?
4. Does Computer inherit Open WebUI's security-reporting policy, and who can release a fix if the primary maintainer is unavailable?
5. Is this single-maintainer structure temporary while Computer is young, or is it the intended long-term governance model?
6. Does the CLA apply to code snippets, patches, or branches submitted through issues? If so, how is informed acceptance recorded when the contributor cannot use the PR checkbox?

Possible documentation and process improvements

Depending on the answers above, it may help to consider:

1. adding a CONTRIBUTING.md that states whether fork PRs are supported and how to submit one;
2. documenting the maintainers/reviewers, release process, and security-reporting route;
3. correcting any repository or organization setting that prevents legitimate fork PRs, if that is unintended;
4. adding pull-request CI for at least formatting, linting, and focused tests;
5. preserving external authorship through normal merges, co-author trailers, or an explicit attribution policy;
6. explaining that the existing main → release PRs are release promotions rather than independent code review;
7. documenting the license and attribution treatment of issue-submitted patches and linked branches, including when the CLA applies and how contributors affirm acceptance.

The project can reasonably choose a centralized, source-available model. The concern is not centralization by itself; it is that interested users and contributors currently have to infer the model from Git history, contribution attempts, and repository settings. A short, explicit document would materially improve confidence and make it easier for people who value Computer to contribute constructively.

Start with README.md, .github/pull_request_template.md, CONTRIBUTOR_LICENSE_AGREEMENT, and .github/workflows, then compare them with the contribution examples in #96, #196, and #201. Done means documenting the supported contribution path, review and release model, security-reporting route, and how the CLA and attribution apply to issue and pull-request contributions.