Remove MODERATION-GUIDELINES (#3)

[ariard]

Making more clear the legal arguments especially the point on the lack of consent, this is very clear that bitcoin core is a common or public property (cf. the wording used by a former lead maintainer) authored by a collective group of developers (~1200 contributors from the git log).

A collective work is a notion that is defined in intellectual property laws, and one of the main rule is that all the rights on the collective work must be exercised with the common agreement of all the contributors, i.e the unanimity rule by default.

There is nothing in the moderation guidelines about policing code changes, only about contributor behavior in this community. It does not put any restrictions on use or modification of the codebase outside of that, that is only covered by the MIT license. Only changing the license could require full contributor buy-in.

As the co-authors or co-contributors must exercise their rights in common, the establishment of the moderation guidelines is a clear violation on this principle of unanimity. Here the same procedural standard that for a change of license like for the MIT one should be followed, i.e full contributor buy-in.

Given the way we’re publishing and assigning change in the project since the time of Satoshi Nakamoto, the de minimis standard to be applied can be as low as 1 authored commit. Those legal standards on collective works are followed in the US, in major European jurisdictions and as far as I can guess in a hundreds of other juridiction.

[ariard]

Pinging Jess from the BDFL here, as contrary to Matthew Zipkin or Wladimir van der Laan, she is a lawyer and she has more know-how to understand that kind of issues.

[pinheadmz]

@achow101 please leave this PR open for discussion

[ariard]

@achow101 please leave this PR open for discussion

I reached out to Jess by email this afternoon.

I’ll wait and I’ll commit to a courteous and polite discussion, without ad hominem.

[pinheadmz]

I’ll wait and I’ll commit to a courteous and polite discussion, without ad hominem.

This is fantastic! It's exactly why we have moderators, it helps keeps the discussion focused and without personal attacks like: "is anyone can quote a significant technical contribution attributed to Matthew Zipkin ?..."

[glozow]

Assuming this pull request is actually about removing the moderation guidelines and not just a general complaint about moderation, concept nack. It is helpful to be communicative about why moderation exists and what its goals are. It may genuinely be helpful to someone who doesn't immediately understand why they were moderated. And some people may struggle with these concepts and need repeated reminders, so having pre-written guidelines may be useful.

Meta on meta: this is the third identical pull request continuing a circuitous and nonsensical ramble conflating moderation with censorship. It is noisy, a waste of contributor time, and should be closed.

[ryanofsky]

In case it's helpful to anyone else I asked chatgpt to produce a summary / steelman version of ariard's views after uploading various issues and threads here. Maybe this could help clarify things and steer conversation in a more productive direction.

Summary

Here’s a steelmanned summary of Antoine Riard’s main arguments, boiled down into clear points with as much substance and internal logic as possible:

🧭 1. Consent & Legitimacy of Moderation Guidelines

Antoine’s core claim is that moderation guidelines, as currently formulated and enforced, lack legitimate consent from the full set of contributors, which he sees as a legal and ethical problem.

• Bitcoin Core has ~1200 contributors. Only a small subset (~13) were involved in approving the moderation guidelines.

• The guidelines were formalized after a closed, invitation-only event (CoreDev Berlin 2024), which he argues excluded many contributors.

• Therefore, he argues, the guidelines do not meet the legal standard (in his view) of collective consent required for rules governing a collective work under intellectual property law.

Steelman interpretation: He believes that since Bitcoin Core is a collaborative work (legally, perhaps a “joint work”), major policy changes should require more inclusive consent, similar to what would be needed to change a software license.

---

⚖️ 2. Legal Concerns about Authority

Antoine frequently references U.S. and EU legal frameworks to argue that:

• Maintainers and moderators may be acting beyond their legal authority when enforcing moderation rules on contributors who never agreed to them.

• Moderation can have chilling effects on free expression, especially when done by people with potential conflicts of interest (e.g. being employed by funders of the project like Chaincode).

• He also implies that if such moderation discourages contributions and leads to bugs or defects, it could create liability—especially if it can be shown to be coercive or retaliatory.

Steelman interpretation: He wants maintainers to think more carefully about legal risk, especially around moderation perceived as silencing dissent or skewing technical outcomes in favor of funders or employers.

---

🧠 3. Conflicts of Interest

Antoine argues that some moderators and maintainers may be subject to indirect pressure from their funders/employers (e.g., Chaincode, Spiral) when making moderation decisions.

• He suggests that moderators could be biased (even unconsciously) if their grant renewals or employment depend on staying aligned with organizational preferences.

• This could lead to uneven enforcement of moderation rules or retaliation against contributors with dissenting views, especially on controversial proposals (e.g., mempoolfullrbf, CTV).

Steelman interpretation: He’s advocating for clear conflict of interest procedures—like recusal mechanisms or reporting channels—to reduce the risk that moderation power gets abused in subtle ways.

---

💣 4. Moderation as Attack Surface

Alongside kanzure and midnightmagic, he argues that having a formal moderation policy is a liability, not a strength:

• A public, written policy creates a roadmap for adversarial actors to exploit, rule-lawyer, or weaponize against the project.

• Moderators themselves become centralized points of failure or coercion, either socially (reputation, gatekeeping) or through external threats (e.g. legal, personal).

Steelman interpretation: In a high-stakes project like Bitcoin, minimizing hierarchy and formal authority structures is a security feature. He sees moderation rules as creating targets and incentives that didn’t exist before.

---

🧠 5. Deep Skepticism of Governance-by-Maintainers

Antoine repeatedly emphasizes that:

• No current maintainer or moderator is Satoshi Nakamoto.

• Therefore, they don’t hold a special claim to decide rules for participation or discourse around Bitcoin Core development.

• Their legitimacy stems from ongoing contributor consensus and mutual respect—not organizational roles or assumed authority.

Steelman interpretation: He’s warning against the institutionalization of power in an open source project that historically prided itself on meritocracy and decentralization.

---

🤝 Reasonable Proposals (buried under fire)

Amid the legal threats and strong language, he has made some potentially useful proposals:

1. Conflict-of-interest guidelines—especially rules for when a moderator should recuse themselves.

2. More transparency around how moderation decisions are made, especially in controversial PRs or discussions.

3. More inclusive, consensus-driven processes for setting behavioral rules—possibly modeled after technical review processes.

---

🧨 Tone, Impact, and Challenges

• Oblique style & erratic tone: He mixes legal theory, sarcasm, and aggressive analogies (e.g. “middle finger,” “rape analogy,” lawsuits), which alienates many people and weakens his case.

• Overclaims about legal standards: Some assertions (e.g. “the rules are illegal”) are likely exaggerated or misunderstood—but they reflect a deep concern about coercion and fairness, especially when money is involved.

• Unclear targets: He names individuals (e.g. Zipkin, Jonas, Morcos) in ways that feel personal or accusatory, though he says he’s making legal or structural critiques.

---

Overall

Antoine seems to be reacting not just to moderation guidelines, but to a broader feeling that the project has become politically gatekept and economically captured, with moderation as the enforcement layer. He’s expressing a desire to rebalance power toward the wider contributor base, even if his methods are incendiary.

I also liked basically all the suggestions it produced, and maybe there are ideas here we could follow up on:

Suggestions

Here’s a breakdown of some possible ways forward that balance Antoine's concerns with the health and practicality of the project, followed by some moderation process ideas (good or bad) that could help.

---

✅ Constructive Paths Forward (if others want to pursue them)

Here are a few possible de-escalation or clarification steps, some of which have already been partially discussed or implemented:

1. Clarify Consent and Scope

• Clarify that the moderation guidelines are not binding legal rules, just an internal tool for keeping discussion focused and respectful.

• Explicitly note (perhaps in the doc header) that the MIT license and copyright law continue to govern the codebase and contributions.

🔹 This could help calm fears that moderation implies legal or editorial control over the code itself.

2. Add an “Acknowledgement” Model Instead of a Vote

• Acknowledge that the document was never, and can’t realistically be, approved by all contributors (many are gone or inactive).

• Instead, maintain a log of active contributors who've reviewed it and optionally voiced support or suggestions.

🔹 This gives visibility to who stands behind the guidelines without pretending universal consensus.

3. Explicitly Separate Moderation from Governance

• Reiterate that moderation only affects GitHub conversation threads, not inclusion of code, contributor rights, or consensus decisions.

🔹 This addresses the concern that moderation is being used to enforce project-wide social or political norms.

---

🛠️ Possible Moderation Guideline Improvements

Here are a few concrete changes or ideas that might make moderation more robust and less vulnerable to critique:

✅ Good Ideas

• Conflict of Interest Clause (lite version):
  Antoine proposed this, and there’s a plausible middle ground:

  “Moderators should recuse themselves from decisions involving individuals or topics where they have a professional or financial conflict of interest, where practical.”

• Add Clear Definitions / Examples of things like:

  • “On-topic”

  • “General criticism”

  • “Reframing constructively”

  This helps reduce the appearance of arbitrariness, which was a repeated complaint.

• Audit Trail / Oversight Commit Panel:
  Not a new body, but maybe a lightweight, rotating panel (3 respected contributors) who can review hard moderation calls if escalated.

• Clarify Appeal Path:
  Right now, meta issues or emails go into the void. A clearer SLA or expectation for response might help.

---

⚠️ Risky or Counterproductive Changes

Some ideas, while superficially appealing, could actually worsen governance, increase drama, or make attacks easier:

❌ Avoid “Universal Contributor Referenda”

• Requiring 1200+ contributors to approve policies retroactively is not practical or meaningful. Antoine is possibly referencing legal theory about collective works, but applying it here would paralyze the project.

❌ Avoid “No Moderation” / Nostr-ification

• Completely removing guidelines, as some propose, risks flooding threads with off-topic or toxic debate, and contributes to burnout—especially on contentious topics like soft forks.

❌ Avoid Individualized Moderator Rules

• Having different rules for different moderators, or moderation-by-accusation (“You work for X, so you can’t moderate Y”), would devolve fast.

---

🧩 Final Thought: Document Tone

One very minor improvement might be changing the tone of the document intro. Right now it says:

“It is easier to rephrase deleted comments to be constructive and respectful than to replace long term contributors who are burnt out…”

That’s reasonable, but might land as slightly passive-aggressive. You could try something more collaborative, e.g.:

“Our goal is to maintain a space where contributors can productively discuss Bitcoin Core’s technical development over time. Moderation is intended to preserve focus, reduce friction, and avoid burnout—not to gatekeep participation.”

[laanwj]

As the co-authors or co-contributors must exercise their rights in common, the establishment of the moderation guidelines is a clear violation on this principle of unanimity. Here the same procedural standard that for a change of license like for the MIT one should be followed, i.e full contributor buy-in.

No, it is not. Software licensing says nothing about the other policies around a project. MIT-licensed software in particular ranges from "periodic corporate drop, no contributions accepted" to "post patches to an unmoderated mailing list and everything gets merged". Bitcoin Core, like any other FOSS project, needs to keep finding its own balance there (and as long as discussion is hosted on github, needs to follow github ToS), but it has otherwise nothing to do with legalism.

FOSS gives you the IP rights to fork a project. If that term has any meaning, the source code is a public/common property, the maintainers are not.

Meta on meta: this is the third identical pull request continuing a circuitous and nonsensical ramble conflating moderation with censorship. It is noisy, a waste of contributor time, and should be closed.

Yes i'm done here.

[ariard]

This is fantastic! It's exactly why we have moderators, it helps keeps the discussion focused and without personal attacks like: #14 (comment)

Sure, I’ll re-commit to restrain myself from any personal attack towards like anyone. Like I might have done on the other threads, if it has been interpreted as such.

Wishing to have a high-quality and courteous conversation on the underlying objective legal principles at stake.

[ariard]

Assuming this pull request is actually about removing the moderation guidelines and not just a general complaint about moderation, concept nack.

This is a pull request to remove the moderation guidelines in their current state, as from my understanding there is a clear violation of the consent of the ~1200 historical contributors as tracked by the git log. This does not say that you could not have moderation rules for the 13 contributors that have formally ACKed the moderation rules as it has been reported by Matthew Zipkin here.

However, even here there is a formality to respect, as among the 13 contributors, I’m not sure the 13 contributors have legally been informed they’ve the right not to give the consent to the moderation rules in their present state.

It is helpful to be communicative about why moderation exists and what its goals are. It may genuinely be helpful to someone who doesn't immediately understand why they were moderated. And some people may struggle with these concepts and need repeated reminders, so having pre-written guidelines may be useful.

This is here where there is some legal unknown as bitcoin as a software from my understanding has been licensed by Satoshi Nakamoto herself / himself, when he or her was still active. This license is granting the “right to modify” the Software, and any modification of the terms of the license towards any user of the software, under which those moderation rules might fall, would have to been done with Satoshi explicit agreement.

The situation is even different for users who have became contributors in the past, if the de minimis standard to be applied is as low as 1 authored commit.

Meta on meta: this is the third identical pull request continuing a circuitous and nonsensical ramble conflating moderation with censorship. It is noisy, a waste of contributor time, and should be closed.

I do no say that moderation is censorship, I’m saying that the way moderation has been established in this project is violating the consent of the ~1200 historical contributors, including as far as I can tell the explicit agreement of Satoshi Nakamoto herself or himself. If this has not been said clearly in the 2 previous pull requests, I’m re-saying it here.

That you, even if you’re a maintainer, you do not lend attention, or you do not wish to lend atttention to those issues, I understand and I respect that. May I politely and courteously remind you that the industry stakeholders financially supporting the non-profit you open-source contributions work is associated with, as far as I know, do care about things like intellectual property.

Do not interpret those words as a personal attack, this is just a matter of fact. Having been in this space for more than half-a decade now, I’m aware that some people who have set non-profit to support bitcoin open-source development, have spent a lot of legal time to dissociate open-source contributions, from the commercial activities of their stakeholders.

If you do not wish to further engage in this conversation, a choice I respect, you’re free to point out that conversation to someone else as your non-profit org. Someone who is better able or more willing to engage in a high-quality and courteous conversation on those topics.

[ariard]

In case it's helpful to anyone else I asked chatgpt to produce a summary / steelman version of ariard's views after uploading various issues and threads here. Maybe this could help clarify things and steer conversation in a more productive direction.

I do not recommend to use chatgpt to produce an opinion in any legal matters, as there has been situations in the past where chatgpt has generated false and invalid court decisions. What we call hallucinations (cf. an example of an issue reported by Associated Press).

I strongly deny that Russ’s chatgpt-produced summary version of my views are in any kind of fashion faithful or correct to my real views. Especially concerning one excerpt:

"He mixes legal theory, sarcasm, and aggressive analogies (e.g. “middle finger,” “rape analogy,” lawsuits), which alienates many people and weakens his case”.

This is completely legally false that is weakening any kind of potential case both in US or major European jurisdictions. I do believe I might have attorneys advising me in my professional career, and as such a clear understanding of what I can say, including sarcasm and aggressive analogies, without falling under any kind of defamation concerns.

That those words could be aggressive or inflammatory, this might be true, though once again the 1st amendment is very very permissive in what you can say in both online and in-person forums. This is also true for what you can say under the perspective of what is allowed by the framework of European fundamental rights.

May I gently ask to Russ to stop to use chat-gpt or any kind of machine-learning tools to represent my view. Appreciate that.

I’ll re-say to what I was asserting to Matthew Zipkin above, that I commit to a courteous and polite conversation, and I’ll restrain myself of more personal attacks, or even what can be understood as aggressive comments.

All that said, this is correct that the crux of the matter is about what is considered as a collective work, or “joint work” under US laws. Said legal notion which has it’s more or less own equivalent in a lot lot lot lot of other jurisdictions.

Whatever disagreement I could or I can have with his employers, I’ll take opportunity to re-affirm my respect I do have for the person of Russ Yanofsky, both for his technical contributions in this space and his human qualities.

[ariard]

No, it is not. Software licensing says nothing about the other policies around a project.

Note a license is only a special kind of private contract in international law, and intellectual property licenses is even a special branch of law. In the silence of what the license is saying on disagreement, established legal principles prevails.

Let’s remind that as far as someone can observe from the current git log, the earliest commit (e071a3f6c) has already a MIT license assigned to Satoshi Nakamoto, i.e in August 2009. Before as far as what is known the start of you, Wladimir van der Laan, the start of your involvement in this project in May 2011 (with commit ad88e7626 afaict).

MIT-licensed software in particular ranges from "periodic corporate drop, no contributions accepted" to "post patches to an unmoderated mailing list and everything gets merged".

The intellectual property question is orthogonal to the question of the medium of communication leveraged (be it Github or a mailing list). So for all the questions in the ranges from “periodic corporate drop, no contributions accepted” to “post patches to an unmoderated mailing list and everything gets merged”, again in the lack of a more precise software license, this is what is understood as “collective work” principles that should play.

There is no legal uncertainty that computer programs are falling under intellectual property principles, that has been judged as such by many jurisdictions all over the world.

Current license is assigned to “The Bitcoin Core developers”, asking who is this we is not at all a pure rhetorical question, though a very pragmatic question for all questions of factual qualification and application of a de minimis standard.

Bitcoin Core, like any other FOSS project, needs to keep finding its own balance there (and as long as discussion is hosted on github, needs to follow github ToS), but it has otherwise nothing to do with legalism.

The history of the works of the mind and disagreement among their co-authors or contributors have not started with FOSS project. Let’s remind for the historical note that the 1st “computer program” has been invented by a woman, Ada Lovelace, in the XIXth century. Be it a play of musics, theater works, cinematographic production, there is a multitude of human artifacts that are the result of collaboration among a group of authors or contributors, said group driven by other considerations than “money” or “material advantages”. So it has nothing to do with impromptu legalism.

FOSS gives you the IP rights to fork a project.

This is not what is contested here. However a FOSS license, if it credits you as a co-author, implicitly grants you some rights as a co-author on said project, including asking for a full contributors buy-in in case of re-licensing as you pointed out yourself. That those rights are not exercised 90% of the time, it can be a reality.

If that term has any meaning, the source code is a public/common property

This is not what is disagreed here that this source code as an original is a common property. What is disagreed on is the implications to follow from this common property, and specifically in that in no circumstances it’s giving any kind of rights to any effective contributor to this common to apply moderation rules on the other ~1200 contributors as it can be seen from the git log.

the maintainers are not.

As far as I know, none of the current maintainers are Satoshi Nakamoto, and specifically in this bitcoin core open-source project, it has always been set that maintainers have a janitorial role, i.e mainly merging the code when there is a consensus of the contributors. In no way maintainers have any kind of say on contributor behavior in this open-source project, contrary to what your comment can suggest.

There has no such granted by the MIT license as set by Satoshi Nakamoto and it’s contrary to the principles of intellectual laws in vigor in many jurisdictions.

Yes i'm done here.

That’s your choice, if you do not wish to further engage on those issues, in all courtesy and politeness. Whatever our respective and antagonist positions on the current issue, this is independent of the respect I can have for your career in the open-source world.

[ryanofsky]

re: glozow #15 (comment)

Meta on meta: this is the third identical pull request continuing a circuitous and nonsensical ramble conflating moderation with censorship. It is noisy, a waste of contributor time, and should be closed.

I'd recommend letting this issue stay open, because part of the claim here is that moderation policies are violating the legal / ethical rights of ~1200 historical contributors, so it would be informative to know if any other past or possible future contributors feel that way. It might also be useful for this to stay open to figure out underlying concerns behind the requested change and maybe spin off other PRs to address them.

The change has been nacked enough times that I think anybody who's bothered by posts here can safely mute this thread and ignore it without needing to worry about this PR getting merged.

I do think a reason why we have a separate "meta" repository, and separate roles for maintainers and moderators is so maintainers should not have to think about or be involved in moderation issues if they don't want. I think it would probably be better if moderators not maintainers made most decisions here.

re: ariard #15 (comment)

May I gently ask to Russ to stop to use chat-gpt or any kind of machine-learning tools to represent my view.

I'm actually surprised you disagree with the characterization it gave. I would have guessed you'd take pride in it! Anyway I did not mean to cause offense. In general I have trouble understanding your posts because they are dense and do not have a clear structure, so I've found if I use chatgpt to summarize the key points, and then read your posts after I have a much better understanding. I do not plan to do this again though.

[ariard]

I'd recommend letting this issue stay open, because part of the claim here is that moderation policies are violating the legal / ethical rights of ~1200 historical contributors, so it would be informative to know if any other past or possible future contributors feel that way.

Objectively, I do not think I’m the only one among all the ~1200 historical contributors to raise questions about the moderation policies. As far as I can tell, there have been also Bryan Bishop and Midnight Magic (who both have authored at least 1 commit in the git tree) who have objected too.

One just has to browse the original conservation about the establishment of moderation rules respectively in January 2023 and February 2024 on the bitcoin core repository, to observe this was from being consensual, or even more following any kind of principle of unanimity standard.

Moreover, while I perfectly understand that human beings have feelings and emotions, a feeling is a very subjective state of mind. In my perspective, grounding a discussion on the open Internet on feelings among people with different cultural backgrounds is not necessarily the most objective criterions to have a high-quality conversation, and is more likely to end up in a dead end road.

Maintainers and moderators are perfectly fine to have feelings, though I do not see how the quality or the intensity of their feelings grants any credibility or objectivity to the matters discussed in the present thread. I do think it’s better to take in example Wladimir van der Laan's position to point out the license actually used in the project, as a license and what has been done as practice over a decade by the project contributors are objective facts that can be discussed.

I do think a reason why we have a separate "meta" repository, and separate roles for maintainers and moderators is so maintainers should not have to think about or be involved in moderation issues if they don't want. I think it would probably be better if moderators not maintainers made most decisions here.

Ultimately, if this is correct it’s a joint work issue, this is not up to the moderators to make the decisions as they have no legitimacy to be moderators in any kind of way, but rather the ~1200 historical contributors as a whole under the principle of unanimity.

Closing or not this pull request has no incidence from the legal viewpoint, and it will change nothing from the established principles from the perspective of intellectual property, as it’s only accessorily about the publication intermediary. It could be a qualification of bad faith from the people vetted with Github permissions, and that it can have legal incidence.

To re-assert my viewpoint I do not call for any change in the way code changes are elaborated and merged in bitcoin core, and I do understand Wladimir van der Laan concern on entering into excessive legalism, which is fine on my side. However, as he says himself in its own words the moderation guidelines are “only about contributor behavior in this community”, which as I understand it is somehow an admission of the nature of the moderation guidelines. I believe when you’re attempting to coerce another human being’s behavior without her or his consent, it can start to be a very legal question.

I'm actually surprised you disagree with the characterization it gave. I would have guessed you'd take pride in it! Anyway I did not mean to cause offense. In general I have trouble understanding your posts because they are dense and do not have a clear structure, so I've found if I use chatgpt to summarize the key points, and then read your posts after I have a much better understanding. I do not plan to do this again though.

We’re fine here, I just worked briefly a bit in ML in my pre-bitcoin career, and learnt from that time that when you feed a ML engine with data set 1 you get outcome A and when you feed a ML engine with data set 2 you get outcome B. Just to be careful with ML / LLM usage, and somehow building a data set can be a very manual handcrafted thing.

I know my posts can be sometimes dense and not necessarily always with a clear structure. Please let me know if there is any point in my post I can re-explain, clarify, highlight in a best effort. Wishing only to have a high-quality conversation here with the utmost politeness and courtesy.

[ariard]

To level-up the conversation in quality here about Bitcoin Core moderation guidelines, I can only recommend to read the following academic paper “A Theory of Joint Autorship for Free and Open Source Software Projects” which is apparently coming from a FSF workshop of 2017. It’s like ~40 pages, though worth it.

This is absolutely not an endorsement of the view of the author, however I think it’s framing well some of the questions of rights raised by my pull request in the context of open source software, with numerous examples of practices done elsewhere (Debian, Apache, Oracle), etc.

If you do not have a legal background, I believe this is a good bridge for one to build a better understanding of the issues discussed. It’s not only from the viewpoint of US law, though it also pointed out open-source softwares cases that were ruled in Germany.

[pinheadmz]

If you do not have a legal background,

I certainly don't but I want you to know, @ariard that I am taking your concerns seriously and spending time to understand them. I am not going to be able to personally digest this 40 page paper or Pye v Mitchell which you cited in a similar issue in the BOLTs repository, so I am actively seeking legal counsel (outside of Chaincode) to help me work out with you exactly what the implications are. Give me some time to process.

[ariard]

I am not going to be able to personally digest this 40 page paper or Pye v Mitchell which you cited in a similar issue in the BOLTs repository, so I am actively seeking legal counsel (outside of Chaincode) to help me work out with you exactly what the implications are. Give me some time to process.

Sure, I fully understand and I can only recommend to work with one or more legal counsels to disentangle the issues pointed out there or in the BOLTs repository. Note, each open-source project is distinct as an “original” work for matters of IP, so bitcoin core is a distinct matter than Lightning BOLTs. That I’ve opened requests on 2 questioning moderation guidelines, it’s more a question of fact given I’ve been an active contributor on both. Though I’m not only the open-source developers who have substantially contributed to both project in the past.

I fully understand it can take time to process, and I’ll always assume that Russ or you will be of good faith to talk about those subjects on this channel. Doing it on a transparent channel where everyone comment it’s good as it’s letting other open-source contributors to chin in and give their perspective. Transparency is more respective of open-source ethos.

[ariard]

I’ll re-open a newer draft for moderation when I found over the next weeks, on the image of what I’ve done for Lightning BOLTs.

To be fair, the current MODERATION-GUIDELINES.md is more balanced, but I’ve always been (a) critical in the almost closed door fashion it has been established following an invitation-only meeting and (b) zero trust in moderators being paid by Chaincode or Block Inc. I’ll ask for more independent moderators to be appointed. Otherwise, I don’t have problems with anyone else in the bitcoin core community.

I’m not going to excuse myself here, I have clearly spent more nights over the last years dealing with bitcoin or lightning vulnerabilities than any executive at Chaincode or Block Inc. “Leaders who code” where was this motto used to be displayed …?

We’re not changing the viewpoint that bitcoin core is an unintended joint authorship, if things have to be become more legal.

[ariard]

I’ll halt to contribute further on bitcoin core, even including discussing consensus changes on the github repository, as the moderation is completely arbitrary to not say more.

That said, I’m leaving open this pull request, as the problem of an unintended joint authorship is quite serious be it for bitcoin core or other bitcoin open-source projects in the industry. Anyone who has a bit of legal know-how in matters in intellectual property should be able to understood the issues at stake.

[ariard]

I’ll re-open a newer draft for moderation when I found over the next weeks, on the image of what I’ve done for Lightning BOLTs.

So I’ll put that in pause as I’m not planning to contribute to bitcoin core anymore, even to discuss consensus changes. But if one wishes to have an example, one can see the draft on the Lightning BOLTs. It’s the same issue there than here, i.e (a) no foundation and (b) no idea what an “impartial party” means to handle moderation in a decentralized open source project with a community of contributors and stakeholders all over the world.