Remove the CoC.md (attempt #3)

[ariard]

The code of conduct as it has been established and how they are enforced are in violation of BOLT contributors rights as set by all the major jurisdictions from where are historical or active individual contributors or organizational stakeholders to the lightning bolt project.

For now, remove the Coc.md until there is legal clarity on the role and extend of each contributor consent w.r.t any hypothetical moderation rules.

---

If you believe there is a legal issue here I encourage you to get a judicial ruling to that effect. In the mean time, nearly every major open source project has added a community Code of Conduct with no such legal issue raised as far as I'm aware.

Apologies, I do not understand joint work is a well-defined notion in US law. It is defined in the Section 101 Chapter 17 of the U.S Code available here.

“A “joint work is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole."

For a judicial ruling of a US court about joint work and the “undivided interest” owned among all the joint contributors, see Pye v. Mitchell, 574 F.2d 476, 480 (9th Cir. 1978).

If you do not understand Pye v. Mitchell or why it doesn’t have legal authority in the US law system, I’m here and I’m letting you asking questions.

I have no idea about which open source project you’re mentioning operating with a community Code of Conduct, though you’re free to list them. Indeed, each open source project is unique, e.g for Linux, Linux being a trademark of Linus Torvalds itself. Beyond, that some contributor in some random open source project no one cares about, do not decide to go to enforce its rights and having its viewpoint respected, it’s her or his concern, not mine.

There is one more differentiating element, a lot of open-source project have a not-profit foundation to manage the project itself. This is not case for Lightning BOLTs, and your current employer is indeed a for-profit company. I’m going to be very polite here and I’ll assume that Square Inc has competent attorneys in matters of intellectual property…

In all politeness and courtesy, I’ll attend meeting 2 weeks from now to re-explain this subject.

[TheBlueMatt]

I asked Grok to take a look at your claims and here was its response:

The argument presented in the post regarding the illegality of a Code of Conduct (CoC) in the Lightning BOLTs open source repository is a labyrinthine amalgamation of misinterpretations, misapplications, and misunderstandings of U.S. intellectual property (IP) law, joint authorship principles, and workplace regulations. The post constructs a narrative that attempts to frame the inclusion of a CoC as an infringement of contributors’ rights, but it ultimately collapses under the weight of its own legal inaccuracies and flawed assumptions. Below, I will meticulously dissect the post’s arguments, explain why they fail to establish that a CoC is illegal, and affirm why an open source repository like Lightning BOLTs can—and often should—have a Code of Conduct.

---

Overview of the Post’s Core Claim

The post asserts that the inclusion of a Code of Conduct (specifically, the CoC.md file) in the Lightning BOLTs repository is illegal because it allegedly violates the intellectual property rights of the approximately 130 historical contributors who did not explicitly consent to its inclusion. The argument hinges on several legal theories:

1. Joint Authorship and Copyright: The Lightning BOLTs constitute a “joint work” under U.S. copyright law, and thus, all contributors retain undivided interests in the work. Any change to the repository, such as adding a CoC, requires the consent of all joint authors, which was not obtained.
2. Creative Commons License: The repository operates under a Creative Commons Attribution 4.0 International (CC BY 4.0) license, which the post claims is the sole governing document. Adding a CoC is seen as an unauthorized modification that infringes contributors’ rights.
3. Work-for-Hire Doctrine: Contributors who worked independently (not under employment contracts) own their copyrights, reinforcing their control over the repository’s contents.
4. Workplace Regulations: The post argues that CoCs are motivated by “social justice” or corporate liability concerns, which are inapplicable to a decentralized open source project like Lightning BOLTs, rendering the CoC legally baseless.
5. Defamation and Courtesy: The post tangentially suggests that CoCs are unnecessary because U.S. law protects free speech in open source discussions, and any disputes should be resolved through impartial investigations rather than formalized rules.

These arguments are presented with a veneer of legal sophistication, citing statutes, case law, and principles like “legal anomie.” However, a closer examination reveals that they are fundamentally flawed, misaligned with the realities of open source governance, and irrelevant to the legality of a CoC. Let’s address each point in exhaustive detail.

---

1. Joint Authorship and the Fallacy of Requiring Universal Consent

The post’s central legal theory is that the Lightning BOLTs repository constitutes a “joint work” under U.S. copyright law (17 U.S.C. § 101), and therefore, any change to the repository—such as adding a CoC—requires the consent of all joint authors. It cites cases like Gaiman v. McFarlane (360 F.3d 644, 7th Cir. 2004) and Erickson v. Trinity Theatre, Inc. (13 F.3d 1061, 7th Cir. 1994) to argue that joint authors have undivided interests and must collectively approve changes to the work’s usage.

Why This Argument Fails

The application of joint authorship principles to an open source repository like Lightning BOLTs is misguided for several reasons:

• Definition of a Joint Work: Under 17 U.S.C. § 101, a joint work is “a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole.” While Lightning BOLTs may involve multiple contributors, open source projects are typically not treated as monolithic “joint works” in the traditional sense. Instead, each contribution (e.g., a commit to the git tree) is often considered a separate copyrightable work, licensed under the repository’s terms (in this case, CC BY 4.0). The repository as a whole is a compilation of these contributions, not a single indivisible work requiring unanimous control.

• Contributor Intent and Open Source Norms: The post claims that contributors since the 2016 Scaling Bitcoin event intended to create a “unitary work.” However, open source projects operate under a decentralized model where contributors implicitly agree to the project’s governance and licensing terms. By contributing to Lightning BOLTs under the CC BY 4.0 license, contributors grant others the right to use, modify, and distribute their work, subject to attribution. Adding a CoC does not alter the copyrighted code or specifications; it establishes behavioral guidelines for participation, which is orthogonal to copyright law.

• Misapplication of Case Law: The cited cases do not support the post’s argument:

  • Gaiman v. McFarlane dealt with disputes over ownership of comic book characters, not governance rules in collaborative software projects. It clarified that contributions must be independently copyrightable to qualify for joint authorship, which undermines the post’s assumption that every commit automatically grants co-authorship over the entire repository.
  • Erickson v. Trinity Theatre affirmed that joint authors have equal rights to exploit the work non-exclusively, but it does not require unanimous consent for non-copyright-related decisions, such as adopting a CoC. A CoC governs community interactions, not the exploitation of the copyrighted work itself.

• Practical Absurdity: If every change to an open source repository required the consent of all historical contributors, the project would be paralyzed. Contributors could vanish, die, or simply refuse to respond, grinding development to a halt. Open source projects avoid this by establishing governance models (e.g., maintainers, consensus processes) and licenses that facilitate collaboration. The Lightning BOLTs repository likely has maintainers who make decisions on behalf of the community, including adopting a CoC, without needing to poll every contributor.

• Scope of the CoC: A Code of Conduct is not a modification of the copyrighted work (i.e., the BOLTs specifications or code). It is a governance document that sets expectations for contributor behavior, such as prohibiting harassment or abusive language. It does not alter the content licensed under CC BY 4.0, nor does it restrict contributors’ rights to use or distribute the work. The post’s claim that the CoC “infringes” contributors’ rights lacks any legal basis, as it conflates copyright with community management.

In summary, the joint authorship argument is a red herring. Open source repositories are designed to evolve through decentralized contributions, not to be shackled by the need for universal agreement. A CoC is a standard governance tool, not a copyright violation.

---

2. The Creative Commons License and the CoC

The post argues that the Creative Commons Attribution 4.0 International (CC BY 4.0) license is the “only document” governing the Lightning BOLTs repository, and adding a CoC without the consent of all contributors violates this license.

Why This Argument Fails

The post fundamentally misunderstands the role of the CC BY 4.0 license and its relationship to repository governance:

• Scope of CC BY 4.0: The CC BY 4.0 license governs the use, distribution, and modification of the copyrighted content in the repository (e.g., the BOLTs specifications). It requires attribution to the original authors but places minimal restrictions on how the work can be used. The license does not address community governance, contributor behavior, or repository management. A CoC operates in a completely different domain, setting rules for how contributors interact, not how the licensed work is used.

• No Violation of the License: Adding a CoC does not modify the licensed work or impose new restrictions on its use. Contributors remain free to use the BOLTs specifications under the terms of CC BY 4.0, with or without a CoC. The post’s claim that the CoC “infringes” contributors’ rights ignores the fact that the CoC does not alter the license’s permissions or obligations.

• Repository Governance: Open source repositories routinely include non-code files, such as READMEs, contribution guidelines, and CoCs, that are not subject to the same license as the code or documentation. These files exist to manage the project and ensure a productive environment. The CC BY 4.0 license does not preclude the repository from adopting such governance documents, nor does it require contributor consent for their inclusion.

• Historical Precedent: The post acknowledges the CC BY 4.0 license was added in 2016 (commit 193bbef9). If the repository could adopt a license without the explicit consent of all prior contributors, it can similarly adopt a CoC. The post’s logic is inconsistent: it accepts the license’s validity but denies the repository’s authority to add governance rules.

• Consent via Contribution: By contributing to an open source project, individuals implicitly agree to its evolving governance. Maintainers or stewards typically make decisions about repository policies, including CoCs, based on community consensus or established processes. The post’s claim that only six contributors consented to the CoC pull request oversimplifies how open source projects operate. Pull requests are often reviewed by a subset of active maintainers, not every historical contributor.

In short, the CC BY 4.0 license is irrelevant to the legality of a CoC. The CoC does not infringe on contributors’ rights under the license, and the repository is free to adopt governance policies as needed.

---

3. Work-for-Hire Doctrine and Contributor Copyrights

The post argues that contributors who worked independently (not as employees) own the copyrights to their contributions, reinforcing their control over the repository and making the CoC an unauthorized imposition. It cites the work-for-hire doctrine (17 U.S.C. § 201) and Community for Creative Non-Violence v. Reid (490 U.S. 730, 1989).

Why This Argument Fails

The work-for-hire argument is largely irrelevant to the question of whether a CoC is legal:

• Work-for-Hire Basics: Under 17 U.S.C. § 201(b), a work made for hire belongs to the employer or commissioning party if created within the scope of employment or under a written agreement. The post correctly notes that independent contributors (e.g., hobbyists or grant-funded developers) likely retain their copyrights unless they signed an agreement assigning them.

• Irrelevance to CoC: Whether contributors own their copyrights or not, the CoC does not affect those rights. It does not claim ownership of contributions, modify their licensing terms, or restrict their use. The CoC governs behavior in the repository, not the ownership or distribution of code. The post’s focus on copyright ownership is a distraction from the real issue.

• Licensing Overrides Ownership: Even if contributors own their copyrights, they licensed their contributions under CC BY 4.0. This license allows others to use, modify, and distribute the work, subject to attribution. The repository’s maintainers can manage the project (including adding a CoC) without needing to revisit ownership, as the license governs usage.

• Misapplication of Reid: The Reid case clarified the criteria for determining whether a work is made for hire (e.g., control, tools, location). While relevant to ownership disputes, it has no bearing on whether a repository can adopt a CoC. The post’s lengthy discussion of work-for-hire criteria is a non-sequitur.

• Pseudonymous Contributions: The post’s tangent about pseudonymous authors (citing 17 U.S.C. § 302 and EUIPO rulings) is equally irrelevant. A CoC applies to all contributors, pseudonymous or not, and does not affect their copyright status.

In essence, the work-for-hire argument is a strawman. The CoC’s legality does not depend on who owns the copyrights, as it does not infringe on those rights.

---

4. Workplace Regulations and the “Social Justice” Strawman

The post argues that CoCs are motivated by “social justice” ideologies or corporate liability concerns, which are inapplicable to a decentralized open source project. It cites workplace harassment cases like Blakey v. Continental Airlines (992 F.Supp. 731, D.N.J. 1998) and Strickland v. City of Detroit (995 F.3d 495, 6th Cir. 2021), claiming that CoCs lack legal grounding in a non-employment context.

Why This Argument Fails

This section of the post is a mix of ideological rhetoric and legal misapplication:

• Purpose of CoCs: Codes of Conduct in open source projects exist to foster inclusive, respectful, and productive communities. They are not inherently tied to “social justice” or corporate liability, though they may align with broader goals of preventing harassment. The post’s attempt to frame CoCs as ideological imposes a false dichotomy: CoCs are practical tools, not political manifestos.

• No Employment Relationship Required: The post correctly notes that Lightning BOLTs contributors are not employees of a single entity, but this undermines its own argument. Workplace harassment laws (e.g., Title VII) apply to employers, but CoCs in open source projects are voluntary agreements among community members. They do not rely on employment law for legitimacy; they are grounded in the project’s right to self-govern.

• Misapplication of Case Law:

  • Blakey v. Continental Airlines addressed employer liability for harassment on an internal bulletin board, not a public platform like GitHub. It is irrelevant to open source repositories, which are not workplaces.
  • Strickland v. City of Detroit dealt with municipal liability, not online communities. The post’s invocation of these cases is a stretch, as they do not address community governance.

• Hostile Environment Standards: The post’s discussion of investigations and “reasonable jury standards” (Baldwin v. Blue Cross/Blue Shield, 480 F.3d 1287, 11th Cir. 2007) assumes that a CoC creates a legal obligation akin to workplace harassment laws. This is incorrect. A CoC is a proactive measure to prevent toxic behavior, not a retroactive legal framework requiring trials or impartial investigators. Maintainers enforce CoCs at their discretion, guided by community norms, not federal statutes.

• Decentralized Governance: The post acknowledges the decentralized nature of Lightning BOLTs, which actually supports the need for a CoC. Without a central authority, clear rules help maintain order and prevent disputes from escalating. The CoC provides a framework for resolving conflicts, which is especially valuable in a global, pseudonymous community.

The post’s ideological framing of CoCs as “social justice” or corporate overreach is irrelevant to their legality. CoCs are standard in open source projects (e.g., Linux, Python, Rust) and are upheld as legitimate governance tools, not legal violations.

---

5. Defamation, Free Speech, and the Role of Courtesy

The post briefly argues that CoCs are unnecessary because U.S. law protects free speech in open source discussions (New York Times Co. v. Sullivan, 376 U.S. 254, 1964), and disputes should be resolved through courtesy or private channels, not formalized rules.

Why This Argument Fails

This section is a weak attempt to dismiss CoCs by invoking unrelated legal principles:

• Free Speech Limits: The First Amendment protects speech from government censorship, not from private community standards. GitHub and the Lightning BOLTs repository are private platforms, and maintainers can set rules for participation, including CoCs, without violating free speech. The post’s reliance on Sullivan (a defamation case involving public figures) is misplaced, as it does not grant contributors a right to behave disruptively in a private project.

• Defamation Irrelevance: The post’s claim that insults in GitHub issues could constitute libel is a distraction. A CoC aims to prevent such behavior before it escalates to legal disputes, not to suppress truthful speech. The Curtis Publishing Co. v. Butts (388 U.S. 130, 1967) citation about truth as a defense to defamation is irrelevant, as CoCs do not regulate defamation claims.

• Need for Formal Rules: The post’s call for “courtesy and politeness” is laudable but naive. Open source projects often involve diverse contributors with differing cultural norms and communication styles. Without clear guidelines, misunderstandings can escalate, harming collaboration. A CoC provides a shared standard, reducing reliance on subjective notions of courtesy.

• Private Channels: The suggestion to handle disputes privately (e.g., for vulnerabilities) ignores the public nature of open source development. Issues like harassment or toxic behavior often arise in public forums (e.g., GitHub issues), and a CoC ensures transparent, consistent responses.

CoCs complement, rather than contradict, free speech and courtesy. They create a framework for respectful collaboration, which is essential for open source projects to thrive.

---

Why Open Source Repositories Can Have Codes of Conduct

Having debunked the post’s arguments, let’s affirm why a CoC is not only legal but also beneficial for a repository like Lightning BOLTs:

1. Community Governance: Open source projects are communities, not just codebases. Maintainers have the authority to establish rules to ensure a productive environment. CoCs are standard in major projects (e.g., Apache, Kubernetes, Mozilla) and are recognized as best practices by organizations like the Open Source Initiative.

2. Preventing Harm: CoCs deter behaviors like harassment, discrimination, or personal attacks, which can alienate contributors and stifle innovation. For a project like Lightning BOLTs, which aims to standardize a global payment network, inclusivity is critical to attracting diverse talent.

3. No Legal Barrier: As shown, CoCs do not infringe copyrights, violate licenses, or require employment relationships. They are voluntary agreements that contributors accept by participating in the project. Courts have never struck down a CoC in an open source context, and the post’s legal theories lack precedent.

4. Flexibility: CoCs vary in scope and enforcement, allowing projects to tailor them to their needs. For Lightning BOLTs, a CoC could be as simple as requiring respectful communication, with enforcement left to maintainers’ discretion.

5. Industry Norms: The absence of a CoC can deter contributors who expect modern governance standards. Projects without CoCs risk being seen as unwelcoming or chaotic, especially in a field like blockchain, where collaboration is key.

6. Practical Enforcement: Contrary to the post’s claim of “legal anomie,” CoCs provide clarity. They outline consequences (e.g., warnings, bans) for violations, reducing disputes and ensuring fairness. Without a CoC, maintainers might act arbitrarily, leading to accusations of bias.

---

Addressing the Post’s Broader Implications

The post’s tone suggests frustration with CoCs, possibly reflecting broader debates in the open source community about governance and ideology. While these concerns may stem from genuine fears of overreach, they do not justify the post’s legal claims. CoCs are not about censorship or control; they are about fostering collaboration in a way that respects all contributors. The post’s invocation of “social justice” or “corporate reasons” is speculative and irrelevant to the legal question. Lightning BOLTs, as a decentralized project, benefits from clear rules that transcend individual agendas.

The post’s call for a Jitsi meeting to discuss “legal issues” may indicate a desire for dialogue, but its arguments are unlikely to persuade, given their lack of grounding in law or open source practice. A more productive approach would be to propose specific changes to the CoC, ensuring it aligns with the community’s values while maintaining inclusivity.

---

Conclusion

The post’s assertion that a Code of Conduct in the Lightning BOLTs repository is illegal is a house of cards built on misinterpreted statutes, irrelevant case law, and a misunderstanding of open source governance. The joint authorship theory fails because a CoC does not modify copyrighted work or require universal consent. The CC BY 4.0 license is irrelevant, as it governs content, not behavior. The work-for-hire doctrine and workplace regulations are misapplied, as CoCs are community agreements, not employment mandates. Free speech and defamation arguments miss the mark, as CoCs operate within private governance, not public law.

An open source repository like Lightning BOLTs can—and should—have a Code of Conduct to ensure a respectful, productive environment. CoCs are standard, legal, and essential for modern collaboration, especially in a global project with diverse contributors. The post’s legal arguments are not just nonsensical; they are a distraction from the real goal of building a robust, inclusive open source community. Rather than inventing legal barriers, the focus should be on crafting a CoC that reflects the project’s values and fosters trust among all stakeholders.