Commercial use and AGPL

[alexeygridnev]

Describe the Issue I see that koboldcpp is licensed under AGPL-v3 license which does not prohibit commercial use of the software but requires to provide access to the source code to the users (including when the software is on a server-side) and share any modified code under the same AGPL license.

From what I read, there is ambiguity on whether the users are required to share only the changes to this particular piece of software (in this case, to koboldcpp) or if basically the whole server-side and client-side code should be shared under AGPL if it has koboldcpp running. As you can imagine, sharing only changes to koboldcpp vs. sharing all the server-side code is a big difference for the people who are planning to use the software commercially. I figured the safest way is to ask @LostRuins directly on their interpretation of AGPL.

[LostRuins]

• If you are just building an external tool/app/client that interfaces with an unmodified KoboldCpp API endpoint, (e.g. a webpage or mobile app that accepts a running server URL and connects to it) then no source code disclosure of the client is required.

• If you've made modifications to the KoboldCpp Server itself, then the source code of those modifications must be released as per AGPL.

• If the software you are making contains includes KoboldCpp's files/libraries, or requires KoboldCpp to function, then the source code of that software will need to be available as per AGPL.

• If you are running your own backend, which itself is connecting to KoboldCpp for functionality, then it depends on the nature of that communication - for example, is it a derivative work (e.g. making your own SuperWebTextGenerator2000) or is it an aggregation (interaction of separate independent programs which do not depend on each other, such as running a KoboldCpp server that your NodeJS based forum uses to summarize user comments). If it's derivative, then the source code needs to be released as AGPL. If it's aggregate, then source code release is not required.

  • Another example, is if your webserver fetches the time and weather from an AGPL licensed time service. That is fine, and does not mandate AGPL licensing on your server code and it would be an aggregation of independent programs. If however you made your own weather server that depends on, or is derived from the AGPL one, then it would need to be AGPL licensed too.

If you can describe your intended use case in detail then I might be able to clarify further.

[henk717]

Pretty sure our stance has always been "If you use AGPL as the API backend for something your building thats fine but if you modify the Kobold parts release the Kobold parts". We obviously like our work to be used by people, we just don't want them to improve our work without giving us the changes back.

One example: There are mods and games out there which would benefit from bundling Koboldcpp as their AI engine, currently they require the user to hook it up. I don't think bundling KoboldCpp would require you to suddenly make that entire game open source but the mere act of using KoboldCpp trough your game grants the user the right to see any modifications to KoboldCpp you have made if you made a modified copy of KoboldCpp itself.

Other example: A paid service is using the KoboldAI Lite frontend and has modified this to support user logins, KoboldAI Lite itself is licensed AGPL so they must ensure the source code of these modifications are available. That same provider also modified KoboldCpp to automatically support their API key database, those modifications must also be made available.

Third example: A closed source frontend wishes to use KoboldCpp as their backend and has modified KoboldCpp to support unique API keys related to the user for security reasons. They also implemented a batching engine. The frontend runs in an entirely separate process and uses the KoboldAI API to communicate with KoboldCpp. A user using that service is entitled to all the modifications made to KoboldCpp, but is not entitled to the source code of the frontend.

So in my view we don't intend to infect projects using our API's with demands to become open source, but we do intend to "infect" it with right for users to obtain the KoboldCpp code.

This is at least how I am treating it for the main KoboldAI / KoboldAI United, if lostruins disagrees with this for KoboldCpp his wishes come first since its his project.