Project licensing

[kayabaNerve]

Currently, all of the code in the project is MIT licensed. This keeps all our infrastructure accessible, while letting the community build on it and iterate, hopefully contributing back. To be more specific, on the notable pieces of of code currently in this project:

crypto/

• The multiexp crate is beneficial to a large amount of parties and could be argued as core infrastructure for ff/group.
• The FROST library is likely to be of interest to projects with this same task, as well as of independent interest to a variety of parties.

coins/

• The Monero library offers transaction signing abilities, an API I personally prefer to monero-rs, and a solution to https://github.com/monero-project/research-lab/issues/103, making it notable even outside of Rust.

There are three further planned pieces (beyond further coins, which will largely be predicated on existing libraries):

• Processor, which has already started, which will provide a unified coin API. This will be dependent on our substrate chain for coordination and explicitly handle multisig keys though, so there's not necessarily independent value in it (using it as the basis of a Rust multi-coin wallet). It could be segmented into a coin API, and files making coins match that API, as one library, with the multisig wallet + Substrate chain handling left in the Processor itself.
• Consensus, as documented in the docs folder, which will be a modification of Aura or BABE + GRANDPA. It should be noted these are "GPL-3.0-or-later WITH Classpath-exception-2.0" already, forcing any modified implementations to also be GPL-3.
• Daemon, which will be a Substrate chain using our consensus with the DEX functionality.

The immediate plan is to update the processor's license to AGPL, and use AGPL for the daemon (along with consensus if possible).

Pros:

• Decreased odds of flippant forks which don't provide additional merit.
• Forks must provide their source code to all users.
• Since this is only being applied to binaries, these projects aren't expected to built on top of, not hampering development, and these licenses shouldn't notably affect anyone who doesn't deploy a modified version (network-accessible instances must only declare themselves when modified).

Cons:

• The AGPL is a heavy handed license which may intimidate developers or make them not prefer to contribute.
• A multi-coin Rust wallet can't use our unified coin type and existing integrations without being AGPL (without separation, which I'm not against). This is the sole non-fork reason I can think of which would be impacted by this.
• Decreased odds of forks, which can be considered a con despite being listed as a pro.

My personal view on forks is that they're fine so long as they provide merit. Else, they're an damaging obfuscation to the project. While this is decently arbitrary, and not a well written blog post yet meant to be my brief take on this issue, I do believe projects which show sufficient POTENTIAL technical innovation do count as providing merit, yet I don't believe projects which simply add a premine and use that to obtain VC funding show merit. On the contrary, I do believe projects which remove notable premines offer sufficiently increased decentralization to warrant existence.

My goal with this, beyond ensuring FOSS as I can currently cite multiple cross-chain projects which are closed source, is to make people interested in flippantly forking reconsider due to the required level of transparency and accreditation which isn't feasible to work around. Any fork would have to argue to the populace their documented divergence is sufficiently notable. For projects with merit, that is possible. For projects without...

I also do not currently see actual detriment beyond potentially making certain developers not interested, including myself from roughly a year ago. I strongly admire the MIT license and believe in it for our libraries, and admire those who always use it, truly offering their code to the world. Unfortunately, this is an example of when cryptocurrency emphasizes currency more than it does crypto. As a decentralized exchange, we are explicitly measured by financial activity, and the easiest way to have financial activity is to have financials. As an individual unable to offer financials to the noted degree, one working on ways to ensure the DEX still has them, it's important to note it'd be immensely easier to be more successful via walking in, forking, and having financials already to offer. That's why I'm hoping the AGPL will increase the view of such projects while demonstrating their contribution is capital, not labor, letting the public make a more informed decision.

I am currently the sole copyright holder of the project. At some point, this MUST be turned over to a larger group, such as "Serai Developers", in order to prevent re-licensing without immense effort. Since I am the only person who needs to decide at this time, that means I CAN relicense the processor as AGPL right now without issue, AND I can revert it back to MIT after sufficient discussion has happened, before the copyright is turned over. If the processor is not made AGPL now however, all its active development work will be MIT, which doesn't offer the protection of the AGPL. If the processor is reverted to MIT, it'll just be MIT though, making the tighter grip required now yet not actually committed to.

As a final note, I will note this can be taken a step further by making FROST LGPL to ensure that the new cryptography scheme it is has the collaborative effort needed to perfect it. The remaining effort for the library is notably in optimizations for large groups, yet it's currently sufficiently performant so I do not see that as a requirement. It'd also bar adoption by certain parties interested in private modifications, which would needlessly turn away people who may eventually submit select changes back/be willing to contribute to development in other ways. Accordingly, I do truly believe all of our libraries, including FROST, should be MIT.

[kayabaNerve]

It should be noted AGPL-3.0-only specifically was adopted. There hasn't been a new version in 15 years and I don't care to grant another party the ability to re-license the project however they see fit.

[TheArchitect108]

Please keep in mind, after the community starts contributing to the processor it will be perpetually harder to change licensing as you must gain consent of each contributor. Many projects get stuck with GPL / AGPL for this reason, it can be very challenging or impossible to find and gain consent from all historical contributors.

[kayabaNerve]

As of right now, copyright is still under "Luke Parker", not "Serai Developers". That's intentional until we resolve this, though I haven't seen any reasons to move off AGPL.

I will note the current ETH integration work is split ownership with @noot though, and demonstrative of your point here.

I'd be in favor of closing this for the current status quo tbh, yet I want to leave the floor open a bit longer for counter comments.

[kayabaNerve]

I'm increasingly confident in the status quo. No reason has been presented to change it, though I won't say this is the most advertised conversation, and the libraries, which is what matters for integration, are MIT without issue.

[erciccione]

I suggest to move away from MIT for such important project. One of the biggest drawbacks of the MIT is that your code can be taken by a big corporation and implemented in their app, leaving the original project to die. Also leaves you without protection against patent trolls. I understand the concerns about the AGPL, so i would suggest something less strict like the LGPL. It's flexible enough and ensures Serai will stay open source.

EDIT: I saw the AGPL file after reading this comment, so you might be already using the AGPL? To avoid confusion i suggest to create the canonical LICENSE file which contains the current license used by the project.

[kayabaNerve]

Right now, the repo hosts MIT and AGPL code, with each crate specifying their license explicitly. Libraries, from DLEq (largely intended to used by other projects) to Monero are MIT to ensure their accessibility. Everything specific to Serai, the processor and chain, is AGPL.

For the latter, LGPL does seem like a half step given how the code is intended to be used in a networked setting, which the LGPL isn't suitably prepared for. For the former, LGPL could be used instead of MIT, which would require corporate edits to the Monero lib would have to be made available to consumers of the modified Monero lib. I'm not against that, but I don't feel a need to due to how it's for consumers only.

Regarding clarification and implementation, I do note issues. 1) We don't ship a copy of the MIT license. 2) The Ethereum lib (AGPL, as it's intended for Serai specifically) has a distinct copyright holder status. This itself is not an issue, but must be kept in mind. 3) The processor has a short AGPL blurb. Crates under substrate do not. This is ambiguous regarding holder, even if the license remains defined.

I believe the solution is: 1) Ship a copy of the MIT license. 2) Add a LICENSE file clarifying the license statuses. 3) Ensure all AGPL crates have their blurbs. 4) Consider MIT blurbs (which may replace # 1 from this list?)

Would love to hear your further thoughts though :D

[kayabaNerve]

Relevant: https://github.com/serai-dex/serai/pull/77.

To be clear, copyright is currently held by myself, with the exception of ethereum (shared with @noot). I do plan on turning the project over to "Serai Developers" or similar, making it effectively impossible to re-license, yet only want to do so after this has been suitably discussed.

[kayabaNerve]

LGPL isn't possible. We'd have to be the stupidity that is GPL-3.0-with-classpath-exception D:

Side note, DLEq is MIT with split copyright predating Serai entirely.

[kayabaNerve]

AGPL with conversion to MIT after 1 year? I believe the AGPL was more of an intent to force honesty out of counterparties while we're young and vulnerable to capital-based takeovers from other groups than anything else. While I don't see the issue with Serai being AGPL long term, we'd have to set a conversion now.

I'd have to double check the exact requirements extended by the AGPL to comment if this would be helpful.

[kayabaNerve]

noot's copyright on ethereum has been officially relinquished.

[kayabaNerve]

The runtime is AGPL-3.0 which... makes sense, and also satisfies Substrate's licensing requirements. The issue is with the RPC code posited in the current in-instructions branch, which is dependent on the runtime and accordingly required to be AGPL-3.0 by extension.

I don't believe its feasible for us to offer an RPC lib which is AGPL-3.0 licensed. Accordingly, we either need to: A) Re-license the runtime, which I'd really rather not, and revisit Substrate's licensing terms. B) Remove the runtime from the RPC lib.

We currently use the runtime for the following:

• Getting the index of pallets.
• Events, which are of the pallet (which are AGPL-3.0).

I'm unsure how to move the events to the primitives (which are MIT licensed) since there's the Pallet event macro for it. The main consideration is we need the Event type to decode it. If we define a #[pallet::event] of Event(primitives::Event), SCALE should transparently encode that. It makes the pallet itself a bit worse, needing to .0 everything, yet should solve the fundamental problem.

As for the former, we can manually hard code numbers and use the CI to assert their correctness. We can also define an AGPL-3.0 sub-package which generates MIT licensed code. This just raises legal concerns and muddies the stack, being not worth it overall.

[kayabaNerve]

Closing, as I believe the current licensing structure is sufficiently sane. We will have to re-define events as defined and also declare consts for pallet indexes. Not only can we test their accuracy in-runtime, we should be able to define a pallet as using a specific index as-well (removing most of the concerns around inconsistency).