Aave V3 Launch strategy: Code licensing

Changing meaning of idea to align with the goal of central body is exactly newspeak.
OS has clear defiition and is not “anyone can read code” but “anyone can fork code”

He was merely making a point. He isn’t a fascist, he isn’t part of a totalitarian government that controls everything. He won’t sneak up on you in a dark corridor and kill you and he won’t control your thoughts. Equivocating a point made in a discussion with this is absolutely insanely hyperbolic and insulting.
There is no need for this. And there is no point of doing it.

i think it’s gonna be needed if the goal is to release under a more strict license.

1 Like

In my opinion, the middle ground of having the Aave DAO holding the licensing for a period of time and then full open sourcing makes sense at the current moment.
I don’t think doing that goes against the “ethos” of the DeFi community, it is a matter of being realistic. All type of resources has been spent by members of the Aave community building Aave v3, and I think it is pretty fair that if some other project wants to use the Aave v3 codebase for commercial purposes, the Aave DAO will need to give permission for a period of time X.
Then about problems like “un-authorized” forks, it can seem that in practise is not effective as anybody can deploy code, but for me it is a matter of having the full clarity that action is just not authorized by the Aave holders.
Then, I support being quite open on giving permissions to other projects if good synergies are found, and obviously those don’t necessary need to be of monetary nature.

3 Likes

I have been going through this thread and I see a lot of people want the V3 code to be open sourced rather than getting a license. IMHO, I feel this could be annoying for other developers who have no intention of making money but they just want to contribute to the community.

OS should be in such a way that it allows anyone to use and modify it without seeking specific permission or making any payment to the original creators. But that’s not the case here. I can surely say, AAVE has a team of very good devs but by requiring an license, you might be killing some room for extra innovations in the project.

Okay. To get this going a little bit, let me summarise what was discussed and proposed until now.

We basically have two options proposed until now:

  • Keep the V3 protocol Open Source, preferably under the MIT license (see here for license text The MIT License | Open Source Initiative) - this means that, “without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software” will be granted to anyone who wants it.

  • Restrict the use of the V3 protocol under the “Business Source License 1.1” (see here for license text Business Source License 1.1 | MariaDB) - this license restricts the use of the software for up to 4 years (with room for the license holder (AAVE DAO) to make exceptions within that time). After the time has passed and the “change date” has been reached, the license will transfer into a GPL3.0 license, and will thus be open source (see here for license text GNU General Public License version 3 | Open Source Initiative)

Both licenses are non custom and free to use - a custom license is not needed and the license itself will not cost anything.

But keep in mind, that under the second scenario, i.e. restrictive license, the AAVE DAO will most likely need to be incorporated, which will incur legal cost, highly likely running cost and it will most probably take weeks if not months to get this off the ground.
To get it going quicker, the license could first be granted to the company with a contract that transfers the IP to the AAVE DAO the minute it is incorporated - this will cost a bit more money (for legalese) but could cut the time significantly for V3 to be released. This also requires the willingness of the company to do, as the AAVE DAO has no control over that.

I really like to see further discussion about this. The thread in itself has just 722 view as of now. But this is a big decision. A lot may just choose to vote, rather than participate in the discussion, but it is very important to get as much feedback as possible. A tweet of this thread by the right persons, could and should give this a bit more traction.

EDIT: A little clarification to the time delay mechanism of the restricted license. The 4 years mentioned is the maximum the license allows. The proposed delay ranged from 1-2 years.

6 Likes

I’d like to see Aave release the V3 protocol open source. I think there’s a lot of potential problems that come with restricting the code. For example, what if part of the Aave community were to become dissatisfied with the current protocol? Because the code is restricted, Aave governance would have a negative incentive to restrict any challenge to bad governance. Hopefully, any restrictions would be of much shorter duration than 4 years, which is practically an eternity in crypto time.

Of course this would probably not be great for token holders though. Just a small developer’s opinion on this topic.

i agree that if anything, restrictions should be way shorter (1 year max, which is usually the rate of new protocol developments).

But i’m not sure i follow on why having a more restrictive license would bring negative incentives to keep proper governance for token holders, could you elaborate?

1 Like

If the license were to only be granted at AAVE governance’s discretion, it wouldn’t really be any different than any other licensed software where the owners predictably leverage their copyrights of their code to the ecosystem’s detriment, and basically picking winners and losers by choosing who gets to use their code. That’s the kind of dynamic I refer to when I mention negative incentives. Not that I think AAVE would engage in this kind of behavior, but the potential is there.

Honestly though it’s just a dumb nitpick. I think having the code be restricted for a short time is definitely reasonable. Also, it would be a really interesting experiment to have source code rights owned by a DAO.

3 Likes

no i understand your point and i don’t think its dumb nitpick.
Look at the flip side though: We are talking about community coordinated forks. The Aave governance could provide know-how, help in evaluating security and market risk, and especially help the users discerning between money grabbing schemes and legit aave forks. A collaborative fork on the other hand might provide participation in protocol development and expansion of the Aave IP.

2 Likes

I agree with this idea and the idea to protect the protocol and grow for a set period of time after wich it can open source

2 Likes

The problem if the code/license belongs to the owners of Aave is that a entity can attack by holding the right to vote or the Aave token simply, it is enough that an entity is sufficiently powerful for some time to be able to abuse the code, the idea of keeping it under license for some time and releasing it gradually seems to me well relevant

What is the risk for users and/or owners of Aave?
I may contradict myself but I also think that innovation should not be kept secret and that it should be shared, and that it proves the success of a project if it is forked or if there is innovation around it, but on the other hand it is necessary to know how to protect it and to admit that it belongs to an entity in a certain way, at the beginning at least

Is there a risk if it belongs to an entity that it could be legally attacked?

1 Like

I would like to know the advantages and risks as well, I think that it is necessary to take into account the energy and the time that the developers devote to build such an effective protocol and that it is necessary to understand the ins and outs, for the moment it is difficult for the common man to understand the differences, in any case even by rereading I have difficulty to understand clearly the stakes

When it comes to licensing the code, the risk, at least legally, are very, very low. The only real risk there is that if the developer team used already license restricted code and build it into AAVE v3 without permission, there is a legal case to be made by the license holder of that piece of code to sue. In that case, the newly incorporated AAVE DAO would need to fight that legal battle, because it licensed (or for the pirated code “sublicensed”) the code. But this is surely not the case. But then again, we all know about patent trolling, so it does not necessarily need to be the case for someone to sue. In any case, this could also happen if we release the code open source, as this would also be considered sublicensing.

And there comes the, in my opinion, big risk factor with this. Incorporating the DAO brings up a slew of questions that are as of yet unanswered. It basically is a whole new adventure. What about taxes, legal representation, regulation, etc. Some of those questions can be answered (just incorporate the DAO in a tax haven like Bermuda, where there are no corporate taxes), others can not be answered (will the AAVE DAO be considered a bank, as it renders bank-like services?) as of now.
The question here is more: Will the AAVE DAO take on this adventure as one of the first DAOs?
I have no doubt in my mind that regulations will come eventually. Not simply because I think if cryptocurrencys and DeFi want to become mainstream, there needs to be a societal bridge that enables trust in it - that usually comes with regulation. The crypto world will not survive in what could essentially be considered “anarchy” right now.

But, I digress. The tl;dr is: There are risks that can not be calculated today. But there is also opportunity.

1 Like

Aave V3 is definitely innovative and Bring various significant features to the Defi protocol, like , a cross chain lending protocol feature allowing assets to he moved between the deployment networks, awesome move towards reducing fees and transaction time.

But as it is pretty obvious among creators and developers, having the V3 licensed instead of being open sourced like the previous versions could be very limiting towards the creatives and innovators, if the code/license belongs to the owners of Aave is that a entity can attack by holding the right to vote or the Aave token simply, that entity can sufficiently abuse the code.

1 Like

Limiting creatives and innovators is not the goal here, you’re right. This is why there needs to be room for exceptions, which would allow the governance to license the code out. This, as I mentioned, would in best practice never involve monetary incentives, as that might steer the DAO to just give it out to the highest bidders.

The second part I don’t quite get. Do you mean a 51% attack on the governance? That scenario is highly unlikely. I hear this argument often about PoS system - they might be “vulnerable” to attack. Keep in mind, right this minute a 51% attack would cost an attacker about 1.5 billion dollars if they buy it OTC (from whom?) and far more if they would buy it on the open market. And all that to control the license of the code base for the v3 AAVE protocol?

And what do you mean by abusing the code? If someone wants to abuse the code, they could simply look on chain and have the code base there. Why would someone with the goal of “abusing” the code go through the trouble and take over the AAVE DAO?

1 Like

I was looking around to check if it’s possible to amend software licenses and in what scale. It obviously isn’t possible (you need to create a custom license) but some discussions I read were very interesting, for example this one mit - Can I modify an open source license to require that I be notified? - Open Source Stack Exchange.

What if we just establish a “fair forking policy” for the codebase, so that if the codebase is being used to fork the protocol, the Aave community can contribute in providing advisory for security, configuration and collaboration. It would be a soft policy to incentivize participation within forks, and not something to be enforced - having forks that collaborate with the creators of the technology helps ensuring the safety of the users.

2 Likes

The discussion in that thread doesn’t really come to an end, does it? They’re talking “free open source” as opposed to just “open source” and if it is possible to amend the MIT license to get a forker to send a notification to the original creator.
But in my opinion, the definition of open source is pretty clear. There can’t be any restrictions.

Quote from https://opensource.org/faq:
Can I restrict how people use an Open Source licensed program?
No. The freedom to use the program for any purpose is part of the Open Source Definition. Open source licenses do not discriminate against fields of endeavor.

So in any case, restricting it, even by as little as requiring a notification to the original creator would make it not open source.

But say we’d license under a custom license that would require the forking project to get into contact with the AAVE DAO. In that case, the license would need to be copyleft (meaning derivatives can only be published under the same license as the original). If it wasn’t, there could just be one team, notifying AAVE that they would like to fork the project, then fork it and release it under a different license, which could be open source.
In that case new projects that want to fork v3 will just fork the relicensed open source version, forgoing the “hassle” to notify the AAVE DAO.
If it is released under a license with copyleft though, AAVE v3 will never become open source, ever. It’ll always be under that restrictive license.

This, in my opinion could be achieved under the Business Source License. There just needs to be a rule set for the AAVE DAO to act by when considering forking requests. Like I said, I think monetary incentives for the treasury would be a bad influence. In a, in part (!), hyper capitalistic crypto community this will probably end in highest bidder = most likely to be a allowed a fork.

To be honest, I don’t know how the DAO would react to forking requests in general. Restricting with the Business Source License could be considered an experiment. See how the DAO reacts and works with or against forks. And in the end, it would be only a year of restrictions. It would be interesting to see.

my concern in this case is more the work needed to bring an eventual business license forward. There is some legal involved that might take months to actually get finalized. Not sure the community wants to wait this much to release V3.