deploy: c824ba9

Author: Conan-Kudo

copyright/index.html

@@ -27,7 +27,7 @@
 <li><a href=/about>About</a></li><li><a href=/community>Community</a></li><li><a href=/contribute>Contribute</a></li><li><a href=/governance>Governance</a></li><li><a href=/docs>Documentation</a></li><li><a href=https://github.com/AsahiLinux>GitHub</a></li><li><a href=/blog>Blog</a></li><li><a href=/support>Donate</a></li></ul></div></header><section id=post-section>
 <div class=post-wrapper>
 <div class=post>
-<h1 id=copyright-policy>Copyright policy</h1><p>Asahi Linux is an open source project, and all contributions must follow the appropriate open source licenses.</p><p>These contribution rules are particularly important for code that is to be upstreamed into other projects, to maintain a clean paper trail of the licensing.</p><h2 id=licensing>Licensing</h2><p>Code developed for Asahi Linux itself should be licensed under a permissive license that allows other projects to take advantage of the code without running into license compatibility problems. The specific licenses are subject to being decided on a case-by-case basis, but we will usually use a permissive license such as the MIT license.</p><p>Code developed for other open source projects must be licensed under that same project&rsquo;s license, and follow licensing/header/authorship conventions appropriate for that project. However, specific modules developed by Asahi Linux contributors (such as entire drivers or submodules) should be dual-licensed under a permissive license such as MIT, to ensure that they can be ported or reused within other projects.</p><p>For original code, we use <a href=https://spdx.github.io/spdx-spec/appendix-V-using-SPDX-short-identifiers-in-source-files/>SPDX license identifiers</a> to record the license of individual files in a concise way. Files should have header of this form (with whatever license information is appropriate):</p><p><code>// SPDX-License-Identifier: GPL-2.0+ OR MIT</code></p><p>No specific authors should be listed in source code files themselves, as this is hard to maintain and unlikely to remain accurate. For top-level and informational places where a copyright statement is needed, such as the MIT license text or &ldquo;about&rdquo; style dialogs, the code should be attributed to &ldquo;The Asahi Linux Contributors&rdquo;.</p><p>We do not require contributors to accept any kind of CLA, nor do we require any kind of copyright assignment. You retain all copyright ownership of any code you write. These are merely conventions about how the origin of the code should be documented in version control and files.</p><h2 id=attribution>Attribution</h2><p>Asahi Linux uses Git for managing source code, and the Git history serves as a record of authorship. The Git &ldquo;Author&rdquo; field should reflect the primary author of a change - if you commit a change authored by another person, you should ensure they are listed as the author. If a change is authored by multiple people, you should add one or more <code>Co-Developed-by: Foo Bar &lt;foo@bar.com></code> lines at the end of the commit message.</p><p>Non-Git releases of the software will be arranged to have an automatically generated authorship file containing a list of all Git contributors.</p><p>In order to certify the origin of contributions, all contributors are required to accept the Developer&rsquo;s Certificate of Origin 1.1:</p><blockquote>
+<h1 id=copyright-policy>Copyright policy</h1><p>Asahi Linux is an open source project, and all contributions must follow the appropriate open source licenses.</p><p>These contribution rules are particularly important for code that is to be upstreamed into other projects, to maintain a clean paper trail of the licensing.</p><h2 id=licensing>Licensing</h2><p>Code developed for Asahi Linux itself should be licensed under a permissive license that allows other projects to take advantage of the code without running into license compatibility problems. The specific licenses are subject to being decided on a case-by-case basis, but we will usually use a permissive license such as the MIT license.</p><p>Code developed for other open source projects must be licensed under that same project&rsquo;s license, and follow licensing/header/authorship conventions appropriate for that project. However, specific modules developed by Asahi Linux contributors (such as entire drivers or submodules) should be dual-licensed under a permissive license such as MIT, to ensure that they can be ported or reused within other projects.</p><p>For original code, we use <a href=https://spdx.github.io/spdx-spec/v2.3/using-SPDX-short-identifiers-in-source-files/>SPDX license identifiers</a> to record the license of individual files in a concise way. Files should have header of this form (with whatever license information is appropriate):</p><p><code>// SPDX-License-Identifier: GPL-2.0+ OR MIT</code></p><p>No specific authors should be listed in source code files themselves, as this is hard to maintain and unlikely to remain accurate. For top-level and informational places where a copyright statement is needed, such as the MIT license text or &ldquo;about&rdquo; style dialogs, the code should be attributed to &ldquo;The Asahi Linux Contributors&rdquo;.</p><p>We do not require contributors to accept any kind of CLA, nor do we require any kind of copyright assignment. You retain all copyright ownership of any code you write. These are merely conventions about how the origin of the code should be documented in version control and files.</p><h2 id=attribution>Attribution</h2><p>Asahi Linux uses Git for managing source code, and the Git history serves as a record of authorship. The Git &ldquo;Author&rdquo; field should reflect the primary author of a change - if you commit a change authored by another person, you should ensure they are listed as the author. If a change is authored by multiple people, you should add one or more <code>Co-Developed-by: Foo Bar &lt;foo@bar.com></code> lines at the end of the commit message.</p><p>Non-Git releases of the software will be arranged to have an automatically generated authorship file containing a list of all Git contributors.</p><p>In order to certify the origin of contributions, all contributors are required to accept the Developer&rsquo;s Certificate of Origin 1.1:</p><blockquote>
 <h2 id=developers-certificate-of-origin-11>Developer’s Certificate of Origin 1.1</h2><p>By making a contribution to this project, I certify that:</p><ul>
 <li>The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or</li><li>The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or</li><li>The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.</li><li>I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.</li></ul></blockquote><p>To certify this, add a line to the end of your Git commit message as follows:</p><pre tabindex=0><code>Signed-off-by: Random J Developer &lt;random@developer.example.org&gt;
 </code></pre><p>This can be automated by simply using <code>git commit -s</code>.</p><p>Real names are not required for authorship or sign-off info. We encourage people to use a name they are commonly known by (e.g. a name you commonly use to interact in similar spaces), as that helps establish trust.</p><h1 id=reverse-engineering-policy>Reverse engineering policy</h1><p>We are committed to ensuring that all source code and documentation produced by the project is legal and free of copyright violations and other legal problems. In order to ensure this, we have a policy that all contributors must follow, particularly if they are doing certain kinds of reverse engineering.</p><p>&ldquo;Clean-room&rdquo; reverse engineering is often considered the gold standard to ensure good legal standing for a reverse engineering project. This involves having separate teams, one of which does the reverse engineering and writes documentation, and the other implements that documentation into the final product. This approach is not a legal requirement to ensure that the final product is free from copyright violations, nor does it absolutely guarantee such a result, but it is a fairly strong legal defense should copyright questions arise.</p><p>We recognize that a true textbook clean-room approach is not sustainable for most open source projects of this nature. Thus, we aim to ensure that Asahi Linux&rsquo;s code and contributions are effectively equivalent to what a clean-room approach would produce, without mandating the overhead of a true clean-room process.</p><p>In order to protect contributors and developers who want to stay away from such subjects, we require that all reverse engineering discussion happen in the #asahi-re and #asahi-gpu (for GPU RE) IRC channels.</p><h2 id=non-reverse-engineering-development>Non-reverse-engineering development</h2><p>If you are merely looking at existing Asahi Linux code and improving it (without taking or referencing code from anywhere else), you are not reverse engineering anything, and you do not need to worry about anything else. Just make sure to follow the <a href=#copyright-policy>Copyright policy</a>.</p><h2 id=referencing-other-open-source-code>Referencing other open source code</h2><p>This is generally OK, but you should not copy and paste any actual code unless the license is compatible and the origin of the code is documented.</p><p>In particular, be careful of open source dumps from Apple, as they are often licensed under the APSL, which is not GPL compatible. Asahi Linux does not allow any APSL code to be used directly. You can use it as a reference for how things work, and you can take inspiration from register names (since those are effectively hardware documentation; we do not consider mere last-level register names to be copyrightable), but do not copy whole <code>#define</code> blocks or include files, other code, or reimplement identical code flows or algorithms. Follow sensible downstream register naming conventions (such as prefixes).</p><p>For example, <a href=https://github.com/opensource-apple/xnu/blob/master/pexpert/pexpert/arm64/arm64_common.h#L10>this</a> register, as documented in XNU include files, should be defined like this when used for Linux:</p><pre tabindex=0><code>#define SYS_HID0                  sys_reg(3, 0, 15, 0, 0)