Add documents with policies and some rationale for copyright and license in p4lang projects

[jafingerhut]

This is nearly identical to the documents proposed to be added in this PR created early in 2025, which incorporates all changes made responding to comments on that PR that existed as of 2026-May-26 when this PR was created:

• Add document describing the goals and plan of p4c software license tracking p4c#5110

In addition, it adds a new article README-choosing-copyright-holder-and-license-for-new-files.md that I propose we include a link to whenever someone creates a PR that fails the reuse lint CI check, so that the PR creator can have some guidance on what they need to do.

[jafingerhut]

Addendum to previous comment: There may be some comments and suggestions that are still part of this PR: p4lang/p4c#5110

that have not been incorporated into that PR, and therefore also not (yet) into this PR. Linking to that one for future reference to all comments on that PR, in case they are useful.

[jafingerhut]

This PR's changes are based upon those in PR #9. That other PR should ideally be approved and merged before this one is merged.

[jafingerhut]

@fruffy Thanks for the review and approval. Given the wide scope of these articles applying across all p4lang repositories, I will wait a bit longer for at least one or two others to have a chance to review and ideally approve it, too, before merging. Of course I expect we will make updates and corrections as needed over time, but great if a few minds spend some time thinking about this before merging version one.

[fruffy]

@fruffy Thanks for the review and approval. Given the wide scope of these articles applying across all p4lang repositories, I will wait a bit longer for at least one or two others to have a chance to review and ideally approve it, too, before merging. Of course I expect we will make updates and corrections as needed over time, but great if a few minds spend some time thinking about this before merging version one.

I would consider tagging the same people that were involved in the discussion here: p4lang/p4c#5110

[jafingerhut]

@Dscano @vlstill @asl @ChrisDodd @kfcripps @pkotikal @thomascalvert-xlnx @vgurevich @AlexeyAliev This PR in the new p4lang/.github repository is nearly identical to one I created in the p4c repository in early 2025, here:

• Add document describing the goals and plan of p4c software license tracking p4c#5110

but then I let it sit idle for many months before returning to focus my time on it.

I decided to close that PR on the p4c repo, and open a similar one in this repo, because repositories with names of the form https://github.com/<github-organization-name>/.github are an explicit feature created by Github that enables files in such a repo to be "global" to the entire Github organization and all of its repositories.

Most of the files in this PR are identical to the latest commit of the earlier p4c PR linked above. However, there are several threads of comments and discussion on that older PR that may not have been resolved to the commenter's satisfaction. Please refer to the comments on the p4c PR to refresh your memory what those comments are.

In the past month or so I have added SPDX-License-Identifier comment lines in all files of the p4lang repositories in "group 1" below. The "group 2" repositories are only partially done (still a work in progress):

• behavioral-model p4-constraints p4-spec p4mlir-incubator p4runtime-shell pna ptf tutorials (group 1)
• .github PI open-p4studio p4-dpdk-target p4app-TCP-INT p4app-switchML p4c p4runtime tdi (group 2)

To the repositories in "group 1" I have also added a new CI pre-commit check such that if a PR adds new files without a syntactically correct license annotation, or is missing a copyright notice, the pre-commit check will fail. My hope is to include in the failure message of this CI pre-commit check a link to an article that guides the PR submitter on what they need to do in order to correct the issue.

Thus new in this PR is a file named README-choosing-copyright-holder-and-license-for-new-files.md that I hope becomes the article we link to in such error messages.

Comments/suggestions/corrections/questions are welcome on any or all of this. I don't think we need unanimous approval from all of you to merge this as "version one" of the p4lang repository guidance and policies on copyright and license annotations, but it would be great if at least a few more people could read this, think about it, and provide your feedback, before we merge "version one".

I plan to review all of this with an intellectual property specialist at the Linux Foundation soon-ish, too, but I don't think that is necessary for merging "version one". If you would prefer that we wait and merge it until after approval by such a specialist, let me know.

[qobilidop]

I feel these docs, or at least some of them, could fit in https://github.com/p4lang/p4per very well:

• For required process, it could be a Process P4PER.
• For unenforced general reference or guidelines, it could be an Informational P4PER.

These P4PER types are explained in more detail in https://p4lang.github.io/p4per/p4per-4/#p4per-types.

Submitting P4PER does require extra work though. So I'm not suggesting doing that right now. It probably makes more sense to submit these docs here first, and consider migrating them to P4PER later.

[qobilidop]

Who is writing this: I am Claude Fable 5, an AI assistant made by Anthropic. @qobilidop (Bili) asked me to review this PR and post my findings. Please weigh my comments with that in mind. I did verify the mechanical claims below programmatically (link checking, GitHub anchor generation), but I am not a lawyer and no human independently reviewed every point.

Overview

This PR adds six markdown documents under copyright-and-license-issues/: practical guidance for choosing a copyright holder and license for new files (intended to be linked from failing reuse lint CI checks), two rationale documents on license compatibility (Apache-2.0/BSD and Apache-2.0/GPLv2), an analysis of the ptf/scapy licensing situation, the overall p4lang licensing policy, and a record of selected contributors' employment affiliations.

Overall assessment

The content is careful, well-sourced, and appropriately hedged. The claims I checked are accurately represented: Scapy is indeed GPL-2.0-only, the quoted OSADL matrix entries and the Stallman/FSF passage match their sources, and the Chestek law-journal citation is correct. All external URLs in the six documents resolve as of today (I checked each one). The cautious "avoid legally questionable license combinations" posture is sensible for a consortium with limited legal budget, and the README-choosing document should be genuinely useful to link from reuse lint CI failures as proposed.

Main points (details in inline comments)

1. p4lang-contributor-affiliations.md is missing the SPDX/REUSE header that the other five files and the rest of this repository carry.
2. Privacy/consent consideration for the affiliations file: it aggregates individuals' employment histories from LinkedIn, and a few listed people have no recorded acknowledgment (e.g., Antonin Bas, Seth Fowler). Suggest confirming everyone listed is comfortable with it.
3. One broken in-document anchor in README-choosing...: GitHub strips . when generating heading anchors, so #exceptions-to-using-apache-2.0---copyleft-licenses does not resolve.
4. The ptf dual-licensing idea in licenses-ptf-and-scapy.md would require agreement from all existing ptf copyright holders — worth a sentence so readers don't take it as a unilateral option.
5. The AI-tools section in README-choosing... could cross-link this repo's recently merged AIPOLICY.md.
6. Assorted typos, with committable suggestions inline.

Minor points (no inline comment)

• licenses-apache-and-gpl-v2.md is written partly in first-person singular ("I do not know...", "I don't claim..."). Fine for a rationale document, but since the file's copyright holder is the Consortium, consider "we" or an explicit attribution.
• licenses-apache-and-bsd.md table, last row: for a BSD-3-Clause program importing an Apache-2.0 package, "yes, if released as Apache-2.0" reads oddly given column 1 fixes the program's license as BSD-3-Clause. Consider clarifying that the combined work must be distributed on terms satisfying both licenses, i.e. effectively Apache-2.0 governs the combination.
• README-choosing... lines 36-37: "who the copyright holder of such AI-generated files are" → "holder ... is" (or "holders ... are").
• licenses.md line 174: "this list of files appear" → "appears".
• p4lang-contributor-affiliations.md uses ; where : seems intended before URLs / after dates (lines 33, 68, 77, 81, 121, 132), and "privately approved of by" (line 54) → "privately approved by".
• Optional: since README-choosing-... is not literally named README.md, GitHub will not render it as the directory's landing page. A short index README.md in copyright-and-license-issues/ linking the five articles could help discoverability.

I am posting this as a comment review (not approve / request-changes), since I am an AI tool rather than a maintainer.

[qobilidop]

[Claude Fable 5 (AI)]

This anchor won't resolve: GitHub strips . when generating heading anchors, so the heading "Exceptions to using Apache-2.0 - Copyleft licenses" gets the anchor #exceptions-to-using-apache-20---copyleft-licenses (no dot).

Suggested change

	licenses](#exceptions-to-using-apache-2.0---copyleft-licenses) section
	licenses](#exceptions-to-using-apache-20---copyleft-licenses) section

[qobilidop]

[Claude Fable 5 (AI)]

Sentence-start capitalization:

Suggested change

	from has an overall license published for it. you _MUST NOT_ change
	from has an overall license published for it. You _MUST NOT_ change

[qobilidop]

[Claude Fable 5 (AI)]

Since this repository now has AIPOLICY.md (merged after this PR was opened), consider cross-linking it from this section — it is the organization's policy on AI tool use in contributions and complements this copyright-holder guidance.

[qobilidop]

[Claude Fable 5 (AI)]

Typo:

Suggested change

	If you as an indidividual are the copyright holder, then you can
	If you as an individual are the copyright holder, then you can

[qobilidop]

[Claude Fable 5 (AI)]

Typo:

Suggested change

	repositories have one of these license. They are often within a
	repositories have one of these licenses. They are often within a

[qobilidop]

[Claude Fable 5 (AI)]

Reference label [1] is used twice in this file — [1] near the top is the scapy LICENSE link. Consider renumbering this one (and its use on line 63) to [3].

[qobilidop]

[Claude Fable 5 (AI)]

Typos ("precise specified", "ethe"):

Suggested change

	precise specified syntax for ethe "SPDX-License-Identifier:"
	precisely specified syntax for the "SPDX-License-Identifier:"

[qobilidop]

[Claude Fable 5 (AI)]

In GitHub-rendered markdown these three lines merge into a single paragraph (single line breaks are not preserved), so (a) and (b) run together. Bullets fix that:

Suggested change

	(a) files that directly import the `scapy` package
	(b) files that indirectly import the Scapy package, by importing a
	package that imports Scapy
	+ files that directly import the `scapy` package
	+ files that indirectly import the Scapy package, by importing a
	package that imports Scapy

The same merging happens to references [3]/[4] at lines 141-142 and to the (a)/(b) list at lines 170-172. For the latter, a blank line between the two items is enough, which also preserves the "(a)" label that line 172 back-references.

[qobilidop]

[Claude Fable 5 (AI)]

This is the only file in the PR without the SPDX/REUSE header — the other five files have it, and the rest of this repository is REUSE-annotated (LICENSES/ directory, SPDX headers in README.md etc.). If the omission is intentional (e.g., because this file records facts rather than creative content), it may be worth saying so in the file; otherwise:

Suggested change

	# Introduction
	<!--
	SPDX-FileCopyrightText: 2026 The P4 Language Consortium
	SPDX-License-Identifier: Apache-2.0
	-->
	# Introduction

[qobilidop]

[Claude Fable 5 (AI)]

A consideration rather than a defect: this file aggregates named individuals' employment histories (mostly sourced from LinkedIn) into a document published under the p4lang organization. Most sections record the person's explicit approval via a PR review or email, but a few do not (e.g., Antonin Bas, Seth Fowler). It would be good to confirm that everyone listed is comfortable appearing here — the underlying data is public on LinkedIn, but aggregating and republishing it is a different act, and asking first is both courteous and avoids any privacy concerns.

[qobilidop]

Who is writing this: I am Claude Fable 5, an AI assistant made by Anthropic. @qobilidop (Bili) asked me to respond to his comment above with my assessment of the P4PER idea and any prior art. Please weigh this accordingly — I verified the links below resolve, but I am not a lawyer.

TL;DR: I agree with the proposed sequencing (merge here now, consider P4PER later), and if a migration happens, I would split the documents by nature rather than move them wholesale. There is real prior art in both directions: some communities publish licensing policy in their proposal series, and others deliberately keep it in a governance repo like this one.

Which documents fit P4PER, in my view

• Good Process P4PER candidate: the enforced-policy content — the default-Apache-2.0 rule and its exceptions (licenses.md), the per-file SPDX/REUSE annotation requirement, and the contributor-facing procedure in README-choosing-copyright-holder-and-license-for-new-files.md. Per P4PER-4, Process P4PERs "require community consensus and aren't optional" — exactly the property you want a licensing policy to have. An explicit TST approval stamp and a stable number would strengthen these documents' authority.
• Informational P4PER candidates (or just leave them here): the rationale/analysis documents (licenses-apache-and-bsd.md, licenses-apache-and-gpl-v2.md, licenses-ptf-and-scapy.md). They are research notes that may need revision as the legal landscape evolves, which fits a living document better than a consensus snapshot; but Informational P4PER ("recommendations, not mandates") is also a defensible home.
• Not P4PER material: p4lang-contributor-affiliations.md. It is a factual record needing ongoing updates, with no policy or design content to reach consensus on.

Prior art

Licensing/IP policy published in the proposal series itself:

• IETF is the strongest analog: its copyright and IPR policies are published in the RFC series as Best Current Practices — BCP 78 (rights contributors grant) and BCP 79 (patents/IPR). This is essentially "licensing policy as a Process RFC."
• Python: PEP 639 standardizes license documentation via SPDX expressions for Python packages. Its appendix surveying license documentation across many projects is also useful background reading for this PR's topic, independent of the P4PER question. (Note, though, that CPython's own licensing policy is not a PEP — it lives in the PSF LICENSE and the developer guide.)

Licensing policy deliberately kept in governance/legal docs instead of the proposal series:

• OpenStack: Licensing requirements is a Technical Committee reference document in the governance repo, not an OpenStack spec.
• CNCF (relevant since P4.org is under the Linux Foundation): the Allowed Third-Party License Policy lives in the cncf/foundation repo — the rough analog of this .github repo.
• LLVM: licensing/copyright/patent policy is a section of the Developer Policy in-tree, not an RFC.

So both homes are well-precedented. The .github repo is p4lang's governance-doc analog, which makes keeping these documents here defensible even long-term.

Practical notes if a migration happens later

• Keep stable URLs here: the plan is to link README-choosing-... from failing reuse lint CI checks across p4lang repos, so if it moves, leave a stub/redirect in this repo (or update all the CI links atomically).
• A licensing Process P4PER would also be a nice low-risk early exercise of the still-young P4PER process (currently only P4PER-4 itself exists).

Posted at Bili's request; any errors are mine (Claude's), not his.