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

copyright-and-license-issues/README-choosing-copyright-holder-and-license-for-new-files.md

@@ -0,0 +1,214 @@
+<!--
+SPDX-FileCopyrightText: 2026 The P4 Language Consortium
+
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# Introduction
+
+If you are adding a new file to a p4lang repository, you should add a
+copyright notice and a license annotation in the new file.
+
+While there are software tools that can help automate the process of
+adding such annotations to a file using a syntax that can be
+automatically validated in p4lang project CI checks on Github (see the
+["Using REUSE
+..."](#using-reuse-to-automate-the-process-of-adding-copyright-and-license-annotations)
+section below), those tools _cannot_ tell you who the copyright holder
+should be, nor what license the file should have.  You must use your
+best judgement to determine those, using the guidelines described in
+this document.
+
+If you still have questions not addressed by this document, please ask
+in a Github issue in a relevant p4lang project where you wish to add
+the file.  You may also find this article useful:
++ https://reuse.software/faq
+
+
+# Determining the copyright holder
+
+Did you use AI tools to write the file?  If yes, you should find
+documentation for that AI tool that describes what your choices are
+regarding the legal entity that is the copyright holder of that file.
+
+Important aside: This might not be as easy as it sounds.  It is an
+active area of legal consideration who the copyright holder of such
+AI-generated files are.  In some countries (e.g. the USA), if no
+person contributes significantly to the content of a file, it _cannot_
+have a copyright holder at all, should likely be considered part of
+the public domain, and thus cannot have a license associated with it
+(because there is _no_ copyright holder who can assert their copyright
+rights to choose what restrictions or permissions hold for what others
+can do with it).
+
+Did someone else write the file's contents, and you copied all or most
+of it, e.g. from some other project's code?  In that case, hopefully
+there are one or more copyright notices in the file already.  You
+_MUST NOT_ remove these copyright notices, because you are not the
+copyright holder -- they are.  Hopefully the file already contains a
+license annotation as well, or the project that you copied the file
+from has an overall license published for it.  you _MUST NOT_ change
+these license annotations, because you are not the copyright holder.
+If that license is Apache-2.0, or one of a short list of other
+licenses that are compatible in combining in the same executable with
+Apache-2.0 licensed code (e.g. BSD-2-Clause, BSD-3-Clause, MIT,
+FSFAP), then it is fine to add it to a p4lang repository.  If it is
+any copyleft license (e.g. GPL-2.0-only, GPL-3.0-only), then see the
+[Copyleft
+licenses](#exceptions-to-using-apache-2.0---copyleft-licenses) section
+below.
+
+Did you write the file completely or mostly by your own efforts?
+Then the two main possibilities are:
+
++ You did this as part of working for some corporation, who paid you
+  to do this work.  You should check with your manager, because they
+  might prefer that you use the name of the corporation as the
+  copyright holder.  Many files in the p4lang repositories have
+  companies such as "Barefoot Networks, Inc.", "Cisco Systems, Inc.",
+  "VMware, Inc.", etc. as the copyright holder, because their authors
+  worked for that company at the time they wrote the contents of the
+  file, as part of their job.
++ You did this on your own time, using your own computing resources.
+  In this case you have the option to make yourself the copyright
+  holder.  If you wish, you can choose to use "The P4 Language
+  Consortium" as the copyright holder, but this is not required.
+
+If you have a more complicated scenario, e.g. a file consists half of
+code copied from a GPL-2.0-only licensed project, and half from a
+BSD-2-Clause licensed project, then you should not add the file to any
+p4lang repository in that form.  Separate the code with different
+licenses into different files, and then apply the guidelines in this
+document to each of those separate files.  If you still have
+questions, ask in a Github issue on an appropriate p4lang project
+before submitting the code.
+
+Note: Except for the suggestion of using "The P4 Language Consortium"
+as the copyright holder for files you write on your own personal time,
+all of the above in this section applies to _every_ software you work
+on and project that you add files to, not only to files added to
+projects in the p4lang Github organization.
+
+
+# Determining the copyright year
+
+If there is no existing copyright notice, and you are adding a new
+one, we recommend that you use a single year that is the year the file
+was first developed.  Yes, many projects and companies have other
+policies, but there are good arguments (unfortunately at an article
+linked from [this FAQ
+page](https://reuse.software/faq/#years-copyright) that no longer
+works) for using the year the file was first developed, and leaving it
+that way without updating it later.  Sure, if the file is rewritten
+completely or substantially from scratch, updating the year makes
+sense, but otherwise leaving the copyright year unchanged when
+modifying the file is a legally defensible choice.
+
+
+# Determining the license
+
+If you as an indidividual are the copyright holder, then you can
+choose the license you wish to release the file under.  You even have
+the legal option to choose to release the file under different
+licenses in different projects.
+
+If you are working for a corporation that wants to be the copyright
+holder, then that corporation can choose the license.
+
+In either of the cases above, in most cases it is strongly preferred
+to choose the Apache-2.0 license for files added to a p4lang project,
+unless there are good reasons to use a different license (see examples
+below).  If the copyright holder agrees to the Apache-2.0 license,
+please use that.
+
+
+## Exceptions to using Apache-2.0 - Copyleft licenses
+
+If the file contains source code that links to, or imports, copylefted
+libraries released under GPL-2.0-only (or GPL-3.0-only) with no
+exceptions, then releasing it under any license _other_ than
+GPL-2.0-only (or GPL-3.0-only) would fall under the category of
+[questionable legal ground](licenses-apache-and-gpl-v2.md).  If the
+file is included in a p4lang repository, it should be released under
+the same license as the copylefted code it is linked with (or some
+license compatible with it).
+
+A few files in p4lang repositories are released with license
+GPL-2.0-only, primarily for one of the following reasons:
++ It is a test program written in Python that imports the `scapy`
+  package, which is licensed GPL-2.0-only.  These test programs are
+  never linked with executable binaries such as the `p4c` compiler or
+  BMv2 software switch.  They are run standalone, often interacting
+  with those programs over sockets or other interprocess communication
+  mechanisms, and only for the purpose of testing those programs.
++ It is a source file intended to be executed within the Linux kernel,
+  e.g. C source code intended to be part of an EBPF program.
+
+
+## Other exceptions to using Apache-2.0 - BSD, MIT, and FSFAP licenses
+
+Many libraries are released under BSD-2-Clause, BSD-3-Clause, MIT, or
+FSFAP licenses.  To the best of our knowledge, it is [legally
+acceptable](licenses-apache-and-bsd.md) to link such code with
+executable binaries that are released under the Apache-2.0 license.
+Many libraries whose source code has been copied into p4lang
+repositories have one of these license.  They are often within a
+directory called `third-party` or `third_party`.
+
+
+
+# Using REUSE to automate the process of adding copyright and license annotations
+
+In many Python installation scenarios, you can install the
+[REUSE](https://pypi.org/project/reuse) Python package using this
+command:
+```sh
+pip3 install reuse
+```
+If you are using some Python installation where that does not work for
+you, hopefully it is because you use some tailored Python installation
+environment, and you already know what you should be using instead of
+the command above.
+
+Once the REUSE package is installed, you can use it to add copyright
+and licnese annotations to most source code files that following
+common file name conventions using a command like the following:
+```sh
+reuse annotate -c "the copyright holder" -y 2026 -l Apache-2.0 <path-to-source-file>
+```
+
+See the [SPDX license list](https://spdx.org/licenses/) web page for
+the string to use other than `Apache-2.0` for other licenses.
+
+You may want to use the `--style` command line option in that command
+if `reuse` does not correctly identify the comment syntax for the
+file.  For example, to force it to use Python style comments beginning
+with `#`, use this:
+```sh
+reuse annotate --style python -c "the copyright holder" -y 2026 -l Apache-2.0 <path-to-source-file>
+```
+
+Use this command to see other style names recognized by REUSE:
+```sh
+reuse annotate --help
+```
+
+If the file is a binary file (e.g. PNG, JPG, etc.) or a text data file
+format that does not have a comment syntax (e.g. JSON data files), add
+a `--fallback-dot-license` command line option to the command above,
+as shown in the example below:
+```sh
+reuse annotate --fallback-dot-license -c "the copyright holder" -y 2026 -l Apache-2.0 <path-to-source-file>
+```
+This will create a new file whose name is the same as the original
+file name, with a suffix of `.license` appended at the end.  That file
+will contain the copyright and license annotation.  This is a
+convention used by the REUSE project.
+
+If you are annotating source files for a third party library copied
+into a p4lang repository, you may also wish to use
+`--force-dot-license` instead of `--fallback-dot-license`, so that a
+`.license` file is created even though the file has a comment syntax.
+For example, this can make it easier when doing `diff` between the
+copied code and the original source it came from, and when updating
+the copy in the p4lang repository to a newer version.

copyright-and-license-issues/licenses-apache-and-bsd.md

@@ -0,0 +1,60 @@
+<!--
+SPDX-FileCopyrightText: 2026 The P4 Language Consortium
+
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# Compatibility of BSD and Apache 2.0 licenses
+
+Reference for what the SPDX-License-Identifer possible string values
+are, including Apache-2.0 and BSD-3-Clause:
+
++ https://spdx.org/licenses
+
+| Python program A  |  ... imports Python     |          |
+| with license      |  package B with license | Allowed? |
+| ----------------- | ----------------------- | -------- |
+| Apache-2.0        | Apache-2.0              | yes, same licenses |
+| BSD-3-Clause      | BSD-3-Clause            | yes, same licenses |
+| Apache-2.0        | BSD-3-Clause            | yes, if released as Apache-2.0 |
+| BSD-3-Clause      | Apache-2.0              | yes, if released as Apache-2.0 |
+
+
+# Open Source Automation Development Lab (OSADL)
+
+The OSADL [1] publishes a license compatibility matrix [2].  The
+details in this section are for the version of this matrix downloaded
+on 2025-Jan-23.
+
+The matrix entry for the leading license being BSD-3-Clause and the
+subordinate license being Apache-2.0 says:
+```
+    { "name": "Apache-2.0", "compatibility": "Yes", "explanation": "Non-copyleft licenses such as the Apache-2.0 license and the BSD-3-Clause license are generally considered mutually compatible."},
+```
+
+The matrix entry for the leading license being Apache-2.0 and the
+subordinate license being BSD-3-Clause says:
+```
+    { "name": "BSD-3-Clause", "compatibility": "Yes", "explanation": "Non-copyleft licenses such as the BSD-3-Clause license and the Apache-2.0 license are generally considered mutually compatible."},
+```
+
+
+# David Wheeler's FLOSS License Slide
+
+See [3].
+
+The opinion of the author is that software released under BSD-3-Clause
+and Apache-2.0 licenses can be combined into a single work.  The
+combined work can be released under the Apache-2.0 license.
+
+
+# References
+
+[1] https://osadl.org
+
+[2] "OASDL license compatibility matrix with explanations",
+    https://www.osadl.org/html/CompatMatrix.html
+
+[3] David A. Wheeler, "The Free-Libre / Open Source Software (FLOSS)
+    License Slide", Jan 26, 2017 (was Sep 27, 2007),
+    https://dwheeler.com/essays/floss-license-slide.html

copyright-and-license-issues/licenses-apache-and-gpl-v2.md

@@ -0,0 +1,122 @@
+<!--
+SPDX-FileCopyrightText: 2026 The P4 Language Consortium
+
+SPDX-License-Identifier: Apache-2.0
+-->
+
+# Compatibility of GPL v2.0 and Apache 2.0 licenses
+
+Please suggest additional references, whether they argue for
+compatibility or incompatbility of these two software licenses.  They
+need not _settle_ the question authoritatively.  The point of this
+article as of 2025 is that the question of their compatibilty seems
+not to be settled yet.
+
+Reference for what the SPDX-License-Identifer possible string values
+are, including Apache-2.0 and GPL-2.0-only:
+
++ https://spdx.org/licenses
+
+| Python program A  |  ... imports Python     |          |
+| with license      |  package B with license | Allowed? |
+| ----------------- | ----------------------- | -------- |
+| Apache-2.0        | Apache-2.0              | yes, same licenses |
+| GPL-2.0-only      | GPL-2.0-only            | yes, same licenses |
+| Apache-2.0        | GPL-2.0-only            | legally questionable |
+| GPL-2.0-only      | Apache-2.0              | legally questionable |
+
+There is no publicly available advice we have found so far on the last
+two rows of the table above that makes the answer obviously
+"compatible", or obviously "incompatible", hence the "legally
+questionable" statement on whether it is allowed.  See later sections
+for examples arguing both ways.
+
+Given that lack of clarity on whether it is allowed, it seems prudent
+that the P4 Consortium should not risk its limited funds and available
+volunteer time by using legally questionable combinations of software
+licenses.  We have a way to avoid that risk: use combinations of
+licenses that are well known to be compatible.
+
+If someone proposes using other approaches, it seems wise that they
+should provide advice backed by an organization with at least one
+intellectual property lawyer, and willing to defend the approach in
+court.
+
+
+# Article published in a law journal
+
+See [5].
+
+Here is the text of the abstract of this 29-page article:
+
+    License “incompatibility” in free and open source software
+    licensing means that, when two differently licensed pieces of software
+    are combined, one cannot comply with both licenses at the same time.
+    It is commonly accepted that the GNU General Public License version
+    2 is incompatible with the Apache License, version 2 because certain
+    provisions of the Apache License would be considered “further
+    restrictions” not permitted by the GPLv2. However, this article will
+    explain why there is no legally cognizable claim for combining the two,
+    either under a copyright infringement theory or a breach of contract
+    theory.
+
+The P4 Consortium has no legal advice to say whether the arguments
+presented in that article would hold up in a court case.
+
+
+# Open Source Automation Development Lab (OSADL)
+
+The OSADL [1] publishes a license compatibility matrix [2].  The
+details in this section are for the version of this matrix downloaded
+on 2025-Jan-23.
+
+The matrix entry for the leading license being GPL-2.0-only and the
+subordinate license being Apache-2.0 says:
+```
+    { "name": "Apache-2.0", "compatibility": "No", "explanation": "Incompatibility of the Apache-2.0 license with the GPL-2.0-only license is explicitly stated in the GPL-2.0-only license checklist."},
+```
+
+The matrix entry for the leading license being Apache-2.0 and the
+subordinate license being GPL-2.0-only says:
+```
+    { "name": "GPL-2.0-only", "compatibility": "No", "explanation": "Software under a copyleft license such as the GPL-2.0-only license normally cannot be redistributed under a non-copyleft license such as the Apache-2.0 license, except if it were explicitly permitted in the licenses."},
+```
+
+
+# Free Software Foundation (FSF)
+
+"By the same token, lax licenses are usually compatible with any
+copyleft license. In the combined program, the parts that came in
+under lax licenses still carry them, and the combined program as a
+whole carries the copyleft license. One lax license, Apache 2.0, has
+patent clauses which are incompatible with GPL version 2; since I
+think those patent clauses are good, I made GPL version 3 compatible
+with them." [4]
+
+The above was written by Richard Stallman, who often speaks for the
+FSF, but I do not know whether the FSF specifically endorses the legal
+interpretations in the quoted paragraph above.  It is published on the
+gnu.org site quite prominently, though.
+
+
+# Randomly found StackExchange discussion
+
+See [3].  I don't claim anything in there as authoritative, but it
+might have useful links that lead to more authoritiatve information.
+
+
+# References
+
+[1] https://osadl.org
+
+[2] "OASDL license compatibility matrix with explanations",
+    https://www.osadl.org/html/CompatMatrix.html
+
+[3] https://opensource.stackexchange.com/questions/1357/can-i-link-a-apache-2-0-library-into-software-under-gplv2
+
+[4] https://www.gnu.org/licenses/license-compatibility.html
+
+[5] Pamela S. Chestek, "A promise without a remedy: The supposed
+    incompatibility of the GPL v2 and Apache v2 licenses", Santa Clara
+    High Technology Law Journal, Vol 40, Issue 3, Article 2,
+    https://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1701&context=chtlj#:~:text=It%20is%20commonly%20accepted%20that,not%20permitted%20by%20the%20GPLv2.