23
submitted 1 year ago by Rucknium@monero.town to c/monero@monero.town

Why

Currently, Monero only has one node written in C/C++, many would see this as an issue. Having only one implementation makes us more vulnerable to implementation bugs, having another node will help us to spot and fix these issues.

monerod's code is also a bit of a mess, as many devs who have worked on it would agree. Cuprate is a fresh start and is built with modularity in mind which will lead to a cleaner and easier to understand codebase.

Having a consensus rules document will make it easier for developers to build software to interact with Monero. It will also make it easier to spot potential issues with consensus rules.

top 9 comments
sorted by: hot top controversial new old
[-] silverpill@mitra.social 13 points 1 year ago

@Rucknium

>All code produced for this CCS will be licensed under MIT.

The decision to change license from AGPL to MIT was a mistake. And what is particularly concerning, apparently a lot of people are okay with that.

Such attitude led to demise of many other communities where independence was sacrificed for "adoption" and corporate takeover was perceived as a good thing.

[-] kowalabearhugs@monero.town 4 points 1 year ago

Can you expound on that and perhaps share some examples of your latter point?

[-] silverpill@mitra.social 17 points 1 year ago

@kowalabearhugs Currently, some parts of Cuprate are licensed under AGPL-3. This means anyone using this code should keep their derivative works as open source and use the same license. The license protects the project from hostile forks and generally serves as a deterrent against privatization of public goods. Lemmy, Mastodon and many other Fediverse servers use AGPL-3 license and it is totally reasonable choice for Cuprate too.

However, when this CCS proposal was discussed some people started to push aggressively against AGPL (going as far as calling it "legal nightmare") and the developer agreed to change the license and even agreed to re-write AGPL-licensed parts of the application if needed.

As I said, this is a mistake, and makes Monero weaker. I think Cuprate may eventually become a dominant implementation because Rust provides a better security and developer experience, and a big chunk of modern cryptographic libraries is being written in Rust (especially in zero-knowledge cryptography). But now any company can safely use Cuprate as part of their infrastructure because it has business-friendly license, create a closed-source fork and hire developers who were previously working on open-source version.

The change of license is basically a signal that corporate interests are more important than interests of ordinary users. As for examples of where this attitude leads, see any cryptocurrency project where companies or "foundations" pay developers for their work and therefore shape the product. Exceptions are rare, and Monero is one of few that relies on donations and crowdfunding.

[-] RealPappenheimer@monero.town 5 points 1 year ago

The above message was cross posted on Reddit by koalabearhugs. My reply on this message seems to get tricked by Reddit (not visible?), so I reply here as well.

" Can't agree with you more. I am very surprised it got to funding this way. This is a very bad decision for Monero as a whole, and the aggressive way the licensing decision got pushed makes you wonder. It is very hard to crack Monero in a technical sense, this push for permissive (=corporate) licensing is opening Monero widely to be brought down in the future via another angle. For some reason the community doesn't care. It behaves as an ignorant bunch of people that won't even investigate the risks and consequences. Goldbacks might be a better route after all. "

In the same thread on Reddit kayabaNerve pointed out some technical advantages of the rewrite in Rust. My reply to this message: "All the supposed technical advantages are of no use if permissive (=corporate) licensing is used. Dangerous development it is."

Sorry for the crossposts.

Choosing the wrong licensing-model could be disastrous for Monero, so I hope people reconsider.

[-] silverpill@mitra.social 1 points 1 year ago

@RealPappenheimer This issue was discussed at length in monero-community matrix room when proposal was submitted. I guess it's too late to reverse the decision. Even the person who wrote AGPL-licensed modules appears to support the change, although I don't know why they suddenly changed their mind.

[-] kowalabearhugs@monero.town 5 points 1 year ago

Thank you for the write-up, I really appreciate it. You make some excellent points. Consider bringing this up in the CCS proposal discussion.

[-] Saki@monero.town 4 points 1 year ago

This Licence decision diagram might be helpful for general public:

  1. Allow others to create closed-source projects with your code?
  2. Yes -> MIT license
  3. No -> Allow others to create a closed-source web service with your code?
  4. [3.] Yes -> GPL-3 or LGPL-3
  5. [3.] No -> AGPL-3
[-] crab@monero.town 3 points 1 year ago

Would love for more Monero software to be written in Rust. Hopefully some good can come out of this despite the controversy.

[-] hyc@monero.town 3 points 1 year ago

Anyone who's been in software development long enough should know that the majority of total rewrite projects fail. Like 99% of the time. Community members throwing money at this proposal might as well be burning their cash.

this post was submitted on 26 Aug 2023
23 points (84.8% liked)

Monero

1690 readers
8 users here now

This is the lemmy community of Monero (XMR), a secure, private, untraceable currency that is open-source and freely available to all.

GitHub

StackExchange

Twitter

Wallets

Desktop (CLI, GUI)

Desktop (Feather)

Mac & Linux (Cake Wallet)

Web (MyMonero)

Android (Monerujo)

Android (MyMonero)

Android (Cake Wallet) / (Monero.com)

Android (Stack Wallet)

iOS (MyMonero)

iOS (Cake Wallet) / (Monero.com)

iOS (Stack Wallet)

iOS (Edge Wallet)

Instance tags for discoverability:

Monero, XMR, crypto, cryptocurrency

founded 1 year ago
MODERATORS