Licensing issues with Aphrodite Engine #37
Replies: 6 comments 9 replies
-
Tagging every contributor. |
Beta Was this translation helpful? Give feedback.
-
Feel free to correct me if I'm wrong. I don't think even GPL will help enforce the stated objective. It basically entitles the recepient of software to the source code and other things. APGL affecting other software that integrates with the licensed work on an API level is new to me, and I see that as problematic if true. |
Beta Was this translation helpful? Give feedback.
-
Going for GPL or LGPL won't do the trick. The obligation to redistribute modified code triggers on redistribution, and for the purposes of those two, SaaS/a hosted instance does not count. In that case, they are functionally the same as BSD and MIT style licences. I also researched ready-made alternative licences and I couldn't find anything better, all the other licences concerned with hosting I could find are even more restrictive. It seem our 2 options are: Option 1) Custom licence, written from scratch Pros:
Cons:
Option 2) AGPL with a carve out that software interacting with Aphrodite trough the API doesn't get infected with the licence. This might contradict a clause in the AGPL, as it explicitly mentions "scripts to control those activities" as being included(my reading is that it wouldn't but again it's ambigous and that's the problem here), so we would have to clarify that our carveout overrules the AGPL and be trough in listing everything in the carveout. GPL variants with carveouts aren't unprecedented, LGPL is the GPL with a carveout and GCC infamously ships with a carveout for code inserted as part of compilation Pros:
Cons:
We're stuck between a rock and a hardplace |
Beta Was this translation helpful? Give feedback.
-
“The GNU Affero General Public License [...] requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version" "If you make access to modified software available to users over a network, you must make your source code available to those users." "The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits." https://opensource.google/documentation/reference/using/agpl-policy |
Beta Was this translation helpful? Give feedback.
-
After some deliberation with experts on this topic, we've come to the conclusion that we'll need to return to the AGPL license with no additional clauses if we are to continue using code from AGPL-licensed repositories such as @henk717 's KoboldAI. If we add a clause for API in the license, it would be nullified the moment a pure AGPL code is added to the repository. We want to keep collaborating with the Kobold community as close friends, so this isn't a risk we are willing to take. Those in favour of a return to AGPL, please leave an approval in the upcoming pull request. If you are against it, please let us know so we can figure out a solution. |
Beta Was this translation helpful? Give feedback.
-
Just wanna chime in that AGPL absolutely does allow for commercial use and indeed anyone can take the code, modify it, and resell all or part it, or run it as their own paid service, collecting all of the profits! You could totally run a competitor offering a paid inference-as-a-service like chatgpt. With just one main restriction - the final product would be open source.
|
Beta Was this translation helpful? Give feedback.
-
We have recently transitioned our license to MIT in response to concerns that the AGPL license might deter potential contributors and pose compatibility issues with non-AGPL licensed codebases. This decision was made following team discussions and direct exchanges with contributors. However, our initial choice of moving towards the less restrictive MIT license was not extensively deliberated upon. As a result, this change has limited our access to AGPL-licensed code from repositories such as KoboldAI or Text-Gen WebUI.
The purpose of Aphrodite Engine is to offer a top-tier, innovative LLM inference engine that is available for commercial use, unlike TGI. The AGPL license would impose restrictions on any corporation utilizing proprietary software that integrates closely with this engine. As our forthcoming website is closed-source, we too would be adversely affected by the AGPL.
Upon further internal deliberation, we concluded that while AGPL may be too restrictive, the MIT and Apache 2.0 licenses may be too open. This could potentially allow corporations to extract significant portions of Aphrodite code for use in their proprietary software, without any obligation to contribute back their modifications. A case in point is Redis, where the BSD-3-Clause license permitted Amazon AWS to utilize, optimize, and enhance their codebase without any commitment to contribute upstream. We are keen to prevent such a scenario.
We anticipate that either LGPL or GPLv3 will fulfill our objectives, without discouraging corporate contributors. Given that we've already undergone one license change, we would prefer not to implement another so soon without an open discussion with all contributors to this repository. We invite you to share your thoughts on the adoption of GPLv3 or suggest an alternative license. If you also have any questions, feel free to ask and I'll answer as best as I can.
Beta Was this translation helpful? Give feedback.
All reactions