Secret network license change

I just noticed on the Secret Network discord some discussion about the license for the network code. I was surprised to learn that the license was updated from a GPL license to a far more restrictive license in Nov 2022 in advance of the Shockwave upgrade. The license can be found here: SecretNetwork/LICENSE at master · scrtlabs/SecretNetwork · GitHub.

Although it can be argued the validators approved this change by approving the upgrade, as far as I know there was no explicit discussion about this change of the license in the public governance chats prior to the upgrade, and it is not mentioned in the proposal on chain: https://secretnodes.com/proposals/123 .

The most pertinent clause, in my opinion, is part three which now reads as:

3. Permitted Uses. For the sole purpose of contribution to this repository, you are granted a non-exclusive, non-transferable, non-sublicensable license to publish, copy, modify, adapt, merge, translate or create derivative works based upon, the Program (such resulting program, collectively, the “Resulting Program”) solely for Non-Commercial Use as long as you: a. give prominent notice (“Notice”) with each copy of the Resulting Program that the Program is used in the Resulting Program and that the Program is the copyright of Gamma; and b. subject the Resulting Program and any distribution, publication, copy, modification, merger therewith, combination with another program or derivative works thereof to the same Notice requirement and Non-Commercial Use (as defined in section 1) restriction set forth herein. c. You will not use any trade names, trademarks, service marks, or product names or logos of Gamma, Secret Network, Secret Coin, or any other contributor or related entity, in a way that may cause confusion about the identity of the owner or authorized user of such marks, names or logos.

The new wording of the license could restrict the ability of validators to determine the future forms of the network, given that Slabs (Gamma) owns all edit privileges to the Secret Network repo. In effect, it limits anyone other than Slabs from forking the existing repository and running a blockchain with it. Although we all recognise that Slabs does the bulk of network development, does that mean we want that set in stone so that all new network code must be approved by Slabs for all perpetuity? Personally, such a situation seems antithetical to the idea of a decentralized network to me. I am curious about why this change was made by Scrt Labs, what the rationale was (scared of competitors?), and why it was not publicly discussed in advance of the Shockwave upgrade?

6 Likes

Hey,

I will leave it up to SCRT labs to post any follow up but I had a similar conversation on Reddit one day with a response by the Labs Legal representative quoted as well, it might help.

2 Likes

Hi @ertemann, thanks for sharing the link. The response in that thread just reiterates what is in the license. The problem is that “third-parties” includes the validator set. I don’t think it is an exaggeration to say that this license change essentially renders on-chain governance completely impotent. If the chain votes to upgrade the chain with code that scrt labs does not want, then there is no recourse for the validators to do anything about that (e.g. forking the chain). Maybe that scenario seems far-fetched in the short term, but long-term when there are potentially hundreds of different stakeholders (validators, dapps etc) deeply invested in SN who knows what the situation might be. It seems to me that a change like this should have been something discussed prior to implementation.

3 Likes

Any comment from slabs? Has there been no response?

2 Likes

They will respond is what they told me, i bumped it again today :slight_smile:

1 Like

Hi @darwinzer0, I will try to address the issue you raised in more detail. First, I do wish to emphasize once more that The license change was in no way intended to allow SCRT labs to void future majority votes. As we previously conveyed, the stated purpose of the license change is to protect the work invested in developing the code against opportunistic third parties who could have used it for personal gains under the terms of the previous license. Furthermore, the scenario that you describe is in fact extremely improbable because if a majority of stake holders voted to adopt a certain code change, there probably would be no specific party against whom legal action could be taken for violating the terms of the license, even if SCRT labs wished to enforce the license terms in such a scenario (an unfounded assumption in itself, given SCRT labs’ strong inherent interest in maintaining the integrity of the network). On the other hand, the scenario from which the license change is intended to protect the network, is obviously much more likely. In view of all that, the only reasonable conclusion remains (in our opinion, at least) that the license change served the common interest of all network members, and did not create any real disadvantage for validators.

1 Like

Hi @yonathan_b, thank you for your response.

There is a difference between stated intentions and potential ramifications of an action like this. Some of these ramifications have to do with optics. Firstly, it signals that Slabs sees itself as the “owner” of Secret Network. This is exacerbated by the fact that the change was made with no public discussion in advance. If the opinion of Slabs was that it was in the common interest of the network, why was it not presented to the community to make the decision? This was part of my initial question that remains unanswered.

Secondly, strong networks should be robust enough to withstand copycat networks. Anyone can spin up their own version of Bitcoin or Ethereum but it is never going to replace them. Giving network code a more restrictive license honestly just looks weak, like there is no confidence that the network can continue to innovate and stay ahead of the competition.

Thirdly, there are still many developers in crypto who are inspired and motivated by the idea of decentralization. Part of that means is that anyone at any time should be able to contribute and help define what the network becomes. Here’s a real ramification for the license change with regard to me as a developer. I am actively working on a number of different projects related to Secret Network, driven primarily by my own excitement by what the technology could enable. At this point, Secret Network is unique and I want to build on it because of that, but this license change makes me seriously keep a look out for other options because it does not sit well with me. Just as one small example, I was hoping to submit a PR on the network code for a new API function. It is a feature that I think could help protect against information leaking based on gas usage. I probably still will, but I have real second thoughts-- I think why should I freely contribute my time to help a private company develop their code under a license that gives them all commercial control over it? If it was an Apache, MIT, open copyleft etc license without commercial restrictions, then I would have zero reservations. Had there been proper consultation about this change with the community you might have realized that there might be this response. I don’t know if I am unusual regarding this but I suspect not.

Finally, I don’t follow logic of why if there is “no specific party against whom legal action could be taken” that this in anyway helps prevent copycat networks. If someone forked the code and made a new version, Slabs could absolutely take legal action against the developers of that forked code. And of course could also go after validators of the new network as well, if they wanted.

3 Likes

100% agree here, personally, I do not consider returning as a developer due to this change, and the PaaS with Secret Network ideas I had for our current and future products are also out the window. I won’t be using this software if it is under a commercial license and I have spoken with many developers that hold a similar stance. I regretfully think this will result in an exodus of developers and the cancellation of many a dapp currently in development.

2 Likes

Hey @darwinzer0,

I don’t think the license implies that SCRT Labs owns Secret Network. That leap in logic isn’t true in either spirit or practice of the license, and it’s a very extreme interpretation of it.

As to the rest - I see where you’re coming from. This wasn’t an easy choice, and I can tell you that even within SCRT Labs there are a variety of opinions. Ultimately, this was my decision and weighing current factors I believe it is the right choice for the network.

With that said, we’re more than happy to have this public discussion, and if there are good, practical, recommendations to better capture the spirit of - ‘open for everyone, as long as it’s used to benefit Secret Network’ - I’m all ears!

1 Like

I doubt this is the case. This isn’t inline with any of the dozens of conversations we’re having with developers building or considering to build on Secret.

But I am interested in hearing more from @darwinzer0, who I consider to be a valued contributor.

2 Likes

Hi Guy, I meant about optics here–that it conveys the impression that that is how Slabs sees its role, and that I think comes down to the fact that there was no consultation in advance. It seems like a no brainer that this should have been publicly discussed and agreed to by the community before making the change.

Not sure what the actual numbers here are, but I would generally be concerned about survivorship bias

As mentioned this was and remains a conflicting decision, and I’m happy to have the discussion now because what’s done is done. With that said – and this is not something I often do – I still firmly believe this was the right choice in this date and time.

I’m still happy to hear more opinions. I have been known to change my mind. I also disagree with the assessment that this centralizes ownership of the network, but I understand the claim regarding optics.

I’m mostly interested if there’s a better version that captures what we want to capture. I think everyone would agree that having developments be concentrated into and onto Secret are beneficial for all stakeholders that truly care about the ecosystem. If there’s a better way to capture this - that’s great. I’ve been in crypto for a long time and have long held the same position of BTC/ETH succeeding in their network effects while forks didn’t (really). To be honest, I don’t think that calculus applies anymore to any project that isn’t one of these two, at least for the time being. So I don’t consider that to be a strong argument in practice (even though it definitely is in spirit).

I think talks from slabs or anyone else of forking secret is a bit silly for majority of parties who might want to given what it would take to maintain a secure deployment of the network, but that aside. As a token holder, I’d prefer people who may want to fork to simply contribute to secret network codebase instead. Think you can improve something on the network or add a feature that is competitive? Great, submit a pull request, if people vote to add the features then I’m sure it would be included like other things we’ve voted to include. I get the other viewpoints from a classical standpoint but I dont see how they benefit me as a SCRT holder really.

1 Like

I agree that it doesn’t imply that SCRT Labs owns the network, but it does imply ownership of the codebase.

3 Likes

I agree with @darwinzer0 here.

Let me bring another point that was not touched yet:

Having such a restrictive license prevents any other 3rd party from taking over continual maintenance and development in case Slabs ceases to exist at some point of time. How is the community guaranteed to have someone continue building and maintaining the codebase in such a case?

I think part of having less restrictive license in such open-source projects is exactly this - allowing anyone to continue the legacy of the great work that was started by others.

1 Like

A community member that I value very much said crossposting my comment on Discord to the from would be helpful. That’s why I decided to share it here as well.

My Discord post:
3-4 years ago I argued that a more restrictive license would be better for SN. Tor, Guy and Leor opposed it. So the network license change discussed in the forum was something I supported. There is a big BUT. Such a major license change should have been decided by the onchain vote after long discussions. Slabs made this decision alone and secretly, betraying the existential culture that the network has had for many years. Like many community members at the moment, I am hugely disappointed. this is despotism and unfair use of power. I cannot accept this (although it is a change that I think is correct). Many valuable members who have served the network for a long time will also not. It is a great injustice and humiliation against the members of this community. I’ve been in SN somehow since 2016-2017. Tor once said why are you still here when you criticize it so much. Because, in a way, it has been one of the constants of my life. Like many long community members. If this change is not put into the community vote, I will definitely leave SN at the risk of losing a constant of my life. Please don’t do this to community members.

There are some points I would like to add to it also:

Why we need more restrictive licence? We are entering into SN2 phase. We are putting a lot of community resource to make the necessary innovation to implement ZK, FHE, MPC… We should protect this know-how in some capacity. Otherwise this innovations and know-how could be easily implemented into other networks. It’s not about just forks. Even our code snippets could make a lot difference. Contrary to what some argue, whether the network is strong or not is not decisive in this regard. We need a more restrictive licence and as Guy said, these innovations should only be available for SN’s benefit. Because as a community we are funding this research.

But some arrangements should be made. For example the ownership of the codes should belong to SN not to only SLabs. We can find a solution for this. SA is a DAO and has a legal identity. Like that a new DAO with a legal entity can be created to represent the entire networks right to ownership of codes. We can discuss the pros and cons of these and find the best solution.

In addition, there will be community members who do not want such a license change in any way. Which already exists. Their presence is one of the reasons that makes us strong. SN has always benefited from these discussions and culture.They could also emphasize their rightful points. And at the end of this discussion, we should decide together as a community and respect the result. As we always do.

I’ve always had a lot of respect for Guy. We’ve been through some very difficult times and somehow he managed to get this ship into its destination. Without his perseverance, intelligence, prudence and leadership, there would be no trace of SN right now. I beg him to act the same way once again.

What community resources are going into funding this research? No inflation is going towards it, no compool is going towards it? It seems weird to paint this as resources of the community for the sake of protecting research performed by labs funded by labs (labs is, of course, a valued entity to the network, it’s just a weird framing)

When we, as a community, allocated some of the tokens to Slabs as a core developer with genesis, didn’t we tacitly accept this as a reward/funda for a development effort? If not all, at least some.

Also, based on your argument, we’ll assume that improvements made with resources from CP or inflation are eligible for license restriction. Wouldn’t your point of objection, then, stem from an objection to the source of development rather than a principled stance advocating open source? And so you won’t be justifying Slabs’ license change?

Well, I also think that this sort of licensing is wrong prima facie. But even from your perspective, I think that viewing this as community resource dedication is weird.