diff --git a/copyright-and-license-issues/README-choosing-copyright-holder-and-license-for-new-files.md b/copyright-and-license-issues/README-choosing-copyright-holder-and-license-for-new-files.md new file mode 100644 index 0000000..01dcb50 --- /dev/null +++ b/copyright-and-license-issues/README-choosing-copyright-holder-and-license-for-new-files.md @@ -0,0 +1,214 @@ + + +# 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 +``` + +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 +``` + +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 +``` +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. diff --git a/copyright-and-license-issues/licenses-apache-and-bsd.md b/copyright-and-license-issues/licenses-apache-and-bsd.md new file mode 100644 index 0000000..c7c0db2 --- /dev/null +++ b/copyright-and-license-issues/licenses-apache-and-bsd.md @@ -0,0 +1,60 @@ + + +# 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 diff --git a/copyright-and-license-issues/licenses-apache-and-gpl-v2.md b/copyright-and-license-issues/licenses-apache-and-gpl-v2.md new file mode 100644 index 0000000..6204352 --- /dev/null +++ b/copyright-and-license-issues/licenses-apache-and-gpl-v2.md @@ -0,0 +1,122 @@ + + +# 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. diff --git a/copyright-and-license-issues/licenses-ptf-and-scapy.md b/copyright-and-license-issues/licenses-ptf-and-scapy.md new file mode 100644 index 0000000..24a1b71 --- /dev/null +++ b/copyright-and-license-issues/licenses-ptf-and-scapy.md @@ -0,0 +1,74 @@ + + +# Considerations for ptf and scapy Python packages + +The Python library Scapy is released under the GNU General Public +License v2.0 [1]. + +[1] https://github.com/secdev/scapy/blob/master/LICENSE + + +The ptf package is released under the Apache 2.0 license: + +[2] https://github.com/p4lang/ptf/blob/main/LICENSE + + + +# Compatibility of GPL v2.0 and Apache 2.0 licenses + +See [this article](licenses-apache-and-gpl-v2.md). + + +# Consequences + +Assuming everything above is correct, consider a Python program that +imports both the scapy and ptf packages _directly_, i.e. it imports +ptf directly, and it also imports scapy directly. + +Should P4.org publish such a program, and if so, under what license +should it be released? + +It seems that the answer is "no", because the argument for whether +this is allowed is too unclear. + +Should P4.org publish such a program under Apache-2.0? It seems +that the answer is "no", because the program imports scapy, which is +GPL-2.0-only. It is too unclear whether this is allowed. + +Should P4.org publish such a program under GPL-2.0-only? It seems +that the answer is "no", because the program imports ptf, which is +Apache-2.0. Again, it is too unclear whether this is allowed. + +There are at least a few Python programs in p4lang repositories that +currently import both the scapy and ptf packages, including these: + ++ https://github.com/p4lang/p4factory/blob/master/testutils/xnt.py ++ https://github.com/p4lang/p4c/blob/master/backends/ebpf/tests/ptf/test.py ++ https://github.com/p4lang/p4c/blob/master/backends/ebpf/tests/ptf/l2l3_acl.py ++ https://github.com/p4lang/switch/blob/master/testutils/xnt.py ++ https://github.com/p4lang/switch/blob/master/tests/ptf-tests/common/utils.py ++ https://github.com/p4lang/p4-dpdk-target/blob/main/third-party/ptf_grpc/ptf-tests/switchd/wcm/switchdverifywcmtraffic.py ++ https://github.com/p4lang/p4-dpdk-target/blob/main/third-party/ptf_grpc/ptf-tests/switchd/lpm/switchdverifytraffic.py ++ https://github.com/p4lang/ptf/blob/master/src/ptf/packet_scapy.py ++ https://github.com/p4lang/ptf/blob/master/utests/tests/ptf/test_mask.py + + +# What could we do about this? + +One possibility _might_ be to change the license of ptf so that it is +multi-licensed [1], i.e. it can be used either as the Apache-2.0 +license, or GPL v2, at the choice of the user. + +Then in the cases where someone writes a program A that imports both +scapy and ptf in in A, they can choose to use ptf under the GPL v2 +license, and also release program A under the GPL v2 license. + +In cases where they write a program A that imports ptf, but not scapy, +then they have a choice whether to publish program A under the GPL v2 +license, or the Apache-2.0 license. + +[1] https://en.wikipedia.org/wiki/Multi-licensing diff --git a/copyright-and-license-issues/licenses.md b/copyright-and-license-issues/licenses.md new file mode 100644 index 0000000..ff8e969 --- /dev/null +++ b/copyright-and-license-issues/licenses.md @@ -0,0 +1,195 @@ + + +# Introduction + +The P4 compiler `p4c` is a leading project of the P4 Consortium, and +used by several companies as the front end of P4 compilers for a +variety of hardware targets. Most of these companies develop +significant proprietary back end code, combine it with some of the +code published in https://github.com/p4lang/p4c, and the resulting +binary executables are released. These companies have no obligation +due to copyleft licenses to release their compiler back end source +code. + +This is allowed, because p4c source files published in the +https://github.com/p4lang/p4c repository are licensed under the Apache +2.0 license. This license was chosen for multiple reasons, but in +part to enable companies to do this. It is the P4 Consortium's intent +to continue enabling this. + + +# Linux Foundation review of P4.org software licenses in published code + +In early 2024 P4.org became part of The Linux Foundation. In November +2024 the Linux Foundation designated a licensing specialist to do a +quick review of software licenses in the public repositories in the +https://github.com/p4lang organization. + +They recommended a fairly light-weight mechanism to make the software +license of all source files explicit and easy to track with automated +tools: adding an SPDX-License-Identifier comment line [1]. + +[1] https://spdx.org/licenses/ + + +These look like the following examples, where the syntax of everything +_except_ the comment indicator is required by SPDX, i.e. there is a +precise specified syntax for ethe "SPDX-License-Identifier:" +characters to be present, and exactly what sequence of characters may +follow it on the line. + +```c++ +// SPDX-License-Identifier: Apache-2.0 +``` + +```python +# SPDX-License-Identifier: GPL-2.0-only +``` + + + +# Why is the top level LICENSE file insufficient? + +One short answer is that for a few files in the p4c repository, and +some other p4lang repositories, releasing them under an Apache 2.0 +license puts P4.org on [questionable legal +ground](licenses-apache-and-gpl-v2.md). Source files that are an +exception to the Apache 2.0 license are described below. We expect +them to be a fairly small set of files, and that these exceptions are +_not_ among the source files that are compiled to create a P4 compiler +executable binary. + +Given that, a per-file software license tracking mechanism becomes +useful. It is also useful when individual files or subsets of files +are copied into other open source software projects. + + +# Most source files will be released with Apache 2.0 license + +The Apache 2.0 license is the default choice for all source files in +https://github.com/p4lang projects, unless this would put P4.org on +[questionable legal grounds](licenses-apache-and-gpl-v2.md). + + +# Source files that should not be released under the Apache 2.0 license + +See [this article](licenses-apache-and-gpl-v2.md) for background on +questions of compatibility of the Apache 2.0 and GPL v2 licenses. + + +## Python source files that import the Scapy package + +Note: All of the source files in this section are _only_ for running +tests, and are _not_ part of a compiled `p4c` executable. + +The Python library Scapy is released under the GNU General Public +License v2.0 [2]. + +[2] https://github.com/secdev/scapy/blob/master/LICENSE + +Note: Scapy is released under the GPL, _not_ the Lesser GPL (aka +LGPL). + +While the LGPL explicitly allows releasing proprietary binaries that +dynamically link with LGPL libraries, the GPL has no such provisions. + +Unless someone can provide a legal ruling from an intellectual +property lawyer to the contrary, we prefer to avoid [questionable +legal ground](licenses-apache-and-gpl-v2.md) by releasing all Python +source files meeting the following conditions under the GPL v2.0 +license: + +(a) files that directly import the `scapy` package +(b) files that indirectly import the Scapy package, by importing a + package that imports Scapy + +We believe that this should not be a significant hindrance to those +who wish to distribute proprietary P4 compiler executables, because +all such Python source files are test programs, run either during CI +for testing p4c executables, or during testing by those making +modifications to p4c code. These Python source files that use Scapy +are not part of P4 compiler executables. + +If a company wishes to distribute Python programs that import the +Scapy package, they will have to decide how to comply with Scapy's +license themselves. P4.org can inform them of the reasons we made the +licensing choices related to Scapy that we did, and continue to avoid +using Scapy or any other copylefted libraries in P4 compiler +executables. Similarly for any other programs besides the P4 compiler +that we expect companies will want to add proprietary extensions to. + + +## C files intended to be compiled and executed in the Linux kernel, e.g. EBPF + +Note: When analyzing the source files described in this section more +carefully, we will take special care to ensure that they are not files +used to build a P4 compiler executable, and update this note when that +task is complete with our findings. + +One or more published p4c back ends produce C source files that are +intended to be compiled and loaded into the kernel via the EBPF +feature, at least [3], [4] and perhaps others. + +[3] https://github.com/p4lang/p4c/blob/main/backends/ebpf/README.md +[4] https://github.com/p4lang/p4c/blob/main/backends/tc/README.md + +While there are a few examples of companies releasing binaries of +Linux driver code for their hardware and not releasing the source +code, we leave it to their legal teams to navigate any of the +intricacies that may be involved in that endeavor. + +[5] is a good introduction to software licensing questions related to +using EBPF. + +[5] https://ebpf.io/blog/ebpf-licensing-guide/ + +While it is _possible_ to write restricted EBPF programs that are +loaded into the Linux kernel that can be distributed under a non-GPL +license, these are the exception, not the rule. + +Do companies using EBPF distribute these programs under GPL 2.0? Yes, +they commonly do. The EBPF code loaded and run in the Linux kernel is +the "data plane" part of the system. The "control plane" part of the +system runs in user space applications on Linux, and these can be +distributed under other licenses, including proprietary licenses. 98% +or more of the code of these systems is in the control plane code. +The data plane code by itself is unlikely to cause any significant +loss of competitive advantage to publicize it. + +Thus our plan is to release all of the following kinds of source files +under the GPL v2.0 license, the same as the Linux kernel: + +(a) files that are intended to be compiled and loaded into the kernel + via EBPF. +(b) header files included from files in category (a). + +Note that this list of files appear to consist of _only_ 2 source +files in the entire p4c repository. Most of the source files related +to EBPF are part of a p4c back end that uses EBPF, which can be +Apache-2.0 licensed, or they are control plane source files used for +testing the EBPF programs loaded into the kernel. + +If any subtle questions arise as to whether a particular P4 compiler +back end, e.g. `p4c-ebpf`, must thus be released under GPL v2.0, we +will raise these questions to the P4 Technical Steering Team for their +advice. + +We expect that for P4 compiler back ends that do not produce source +code for use with EBPF, this question will never arise. + + +# Third party libraries used by p4c + +There are many libraries used by `p4c` executable binaries, and for +some, several alternate libraries that can be used in their place. + +TODO: We should summarize those, and their licenses, here, as advice +to those who wish to produce proprietary `p4c` executable binaries.