Does using an AGPLv3-licensed library prevent me from dual-licensing my own source code?

Question

I wrote some software (a simple command-line utility) and released the source code under the following zlib-style open source license:

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely. This software is provided 'as-is', without any express or implied warranty.

My software uses a third-party library which is released under a dual AGPLv3/commercial license model, i.e. I can use the library for free under the AGPL or I can purchase a commercial license. I chose to use the library under the AGPL.

The vendor (copyright holder) of the library objected to this on the grounds that my zlib-style license is not compatible with the AGPL. I proposed to the vendor that I would dual-license my code under both the existing zlib-style license and under the AGPL.

The vendor replied that I cannot dual-license my source code, because my source code will not compile without their library, and is therefore a composite work which must be licensed under the AGPL only.

My understanding is that while this would apply to a compiled version of my software (which was compiled against their library and links to it at runtime), there is no such restriction on my source code itself, because simply using an API whose implementation is licensed under the AGPL cannot impose license terms on the API user.

Who is right?

(I intend to distribute a compiled binary version of my software to a client, and I have no problem licensing that binary under the AGPL only and complying with its terms; my only concern is that I would like the source code to remain available under its existing zlib-style license as well.)

Answer 1

The fact that you use your own license, rather than a well-known open-source license complicates matters a bit. I am not a lawyer, but your license looks close enough to the actual zlib license that basing my analysis on the zlib license should give the same outcome. I would urge you to adopt a well-known license, which could be the actual zlib license.

The FSF considers the zlib license to be compatible with the GPL, and in my opinion the your license is equally compatible.
The library vendor might think the licenses are incompatible because the zlib license does not require derived products to remain open-source, but the restrictions of the GPL are not required to be present in the other license for them to be compatible, as long as that other license does not forbid those restrictions.

This means that your choice of license is legally sound, but it can lead to an interesting situation if you are not careful.

If an application depends, directly or indirectly, on a library that is under the (A)GPL license, then the terms and conditions of the (A)GPL license apply to the entire application and also to the parts that are not explicitly licensed under the (A)GPL license.

With your permissive license, it can be that a client of you is not aware enough of the dependency on the third-party AGPL library and they create a closed-source application with your library that is in violation of the AGPL. The library vendor will naturally avoid this situation.

Dual-licensing your library is not an answer to the problem described above, because dual-licensing allows your clients to choose which license they want to apply and they still can get into the situation of accidentally violating the AGPL license.

A better solution is to avoid distributing the third-party library along with your library. Instead, in your documentation you would inform your clients that they need to obtain a copy of the library directly from the vendor and that they have to choose between an AGPL or a commercially-licensed version.
Your zlib(-style) license is compatible with both options, and your clients must make a deliberate choice if they are willing to abide by the AGPL or if they are going to pay to keep their sources private.