4 ms·

> They are using AGPL as a fake open license Actually, AGPL is the only license respecting copyleft's spirit for network applications such as the Vulcain Gatew

> They are using AGPL as a fake open license Actually, AGPL is the only license respecting copyleft's spirit for network applications such as the Vulcain Gateway Server (https://www.gnu.org/licenses/why-affero-gpl.en.html https://www.gnu.org/licenses/why-affero-gpl.en.html). If big companies don't want to play the game for whatever legal reasons, that's on them. And... so there is the commercial license (even if I'm pretty sure I'll never sell a single one for Vulcain). If they really want to use it, they can pay (they pay for AWS, Windows, Sales Force... and a lot of other proprietary software after all). > knowing no one will actually use it MongoDB (among other big projects) is very popular, and has been licensed for a while with AGPL (and it wasn't even restrictive enough to prevent Amazon to predate them, but that's another topic). Also Ghostscript, ownCloud, nextCloud, SugarCRM... In the case of Vulcain, the protocol is what has most value (IMHO), and it is not licensed under AGPL. It's pretty easy to implement directly the protocol in an app server (if it is written in a programming language able to deal with HTTP/2 directly such as Go, Rust, C or Node). > so this is really just a paid commercial venture trying to make itself look open sourcey My goal when publishing free software isn't to help big companies making proprietary services to make even more money without giving anything back (MongoDB, Redis, ... stories). Thanks to AGPL, users not able to modify the software (lack of financial resources, time or skills) can still benefit from changes made by big companies. That's the goal of copyleft. If they don't want to play according to the copyleft rules, then ok, they can pay as for any other proprietary software. It looks like a fair deal to me. > The work you're doing is too important to needlessly kill it like this. I really appreciate, and I'll maybe consider switching to another license at some points if it's a real blocker. Mercure.rocks (another of my projects) use the same strategy (permissive spec, that anybody can implement, and AGPL implem) and so far it got both adoption (and PRs, even if, as for Vulcain, the main value is in the spec, the server is a tiny piece of software that doesn't require too much maintenance). For lower level stuffs (such as my PHP libraries), I use MIT because they are designed to build something bigger, not to be used as-is such as the Vulcain Gateway Server or Mercure.

curryst 7y ago
> If big companies don't want to play the game for whatever legal reasons, that's on them. And... so there is the commercial license (even if I'm pretty sure I'll never sell a single one for Vulcain). If they really want to use it, they can pay (they pay for AWS, Windows, Sales Force... and a lot of other proprietary software after all). If I were looking at using this, it's somewhat of a show-stopper for me not because I think that my company wouldn't want to pay for it; it's that the procurement process is so painful that it becomes almost not worth it for the limited scope of use. I think a lot of people miss one of AWS' greatest selling points: I go through procurement once to get authorized to use AWS, and it then opens up a whole cache of services I can utilize. Things with a wide range of functionality are worth fighting with procurement over; things that implement a single function start to kick in cost-benefit questions over whether I can get by with the functionality provided by MIT or Apache licensed projects, or if I can re-implement the portions I'm interested in. > In the case of Vulcain, the protocol is what has most value (IMHO), and it is not licensed under AGPL. I shudder at the thought of trying to convince legal of this. That may be your interpretation or goal, but Legal is likely going to take the broadest possible interpretation of the licensing. I'm not a lawyer, I have no context to discuss who's right here, but my experiences with legal have been to always assume that they will take an extremely conservative approach (as is their job). That being said, Mongo does do the same thing, and the surrounding discussions seem to agree that using Mongo's API does not make your software a derived work. The AGPL introduces a risk that someone, maybe an intern or someone 3 years later who doesn't know the licensing context around the AGPL software, will do something that makes internal applications a derived work. Even denoting what makes something a "derived work" gets into murky territory that, afaik, has not entirely been legally tested in court. It has far less to do with being unwilling to contribute the changes back to upstream, and more to do with a fear of the risk that someone will accidentally violate the segregation between our applications and the AGPL'ed one, and suddenly all of our proprietary code is under the AGPL because one application violated that boundary. Which is legitimate fear if your codebases are tightly coupled (i.e. this app used Vulcan as a library, and that app links to this library that almost all of our applications use, so now it's all under the AGPL). The problem is not contributing changes to Vulcan upstream, it's the risk of the license infecting proprietary software. This is super cool, and I am definitely going to dig into this for personal projects. I really appreciate the work you put in, and you open sourcing this. The licensing is entirely up to you, and I'm going to poke around in it either way; but it is a killer for trying to use it in enterprise-y environments.

curryst 7y ago

> If big companies don't want to play the game for whatever legal reasons, that's on them. And... so there is the commercial license (even if I'm pretty sure I'll never sell a single one for Vulcain). If they really want to use it, they can pay (they pay for AWS, Windows, Sales Force... and a lot of other proprietary software after all). If I were looking at using this, it's somewhat of a show-stopper for me not because I think that my company wouldn't want to pay for it; it's that the procurement process is so painful that it becomes almost not worth it for the limited scope of use. I think a lot of people miss one of AWS' greatest selling points: I go through procurement once to get authorized to use AWS, and it then opens up a whole cache of services I can utilize. Things with a wide range of functionality are worth fighting with procurement over; things that implement a single function start to kick in cost-benefit questions over whether I can get by with the functionality provided by MIT or Apache licensed projects, or if I can re-implement the portions I'm interested in. > In the case of Vulcain, the protocol is what has most value (IMHO), and it is not licensed under AGPL. I shudder at the thought of trying to convince legal of this. That may be your interpretation or goal, but Legal is likely going to take the broadest possible interpretation of the licensing. I'm not a lawyer, I have no context to discuss who's right here, but my experiences with legal have been to always assume that they will take an extremely conservative approach (as is their job). That being said, Mongo does do the same thing, and the surrounding discussions seem to agree that using Mongo's API does not make your software a derived work. The AGPL introduces a risk that someone, maybe an intern or someone 3 years later who doesn't know the licensing context around the AGPL software, will do something that makes internal applications a derived work. Even denoting what makes something a "derived work" gets into murky territory that, afaik, has not entirely been legally tested in court. It has far less to do with being unwilling to contribute the changes back to upstream, and more to do with a fear of the risk that someone will accidentally violate the segregation between our applications and the AGPL'ed one, and suddenly all of our proprietary code is under the AGPL because one application violated that boundary. Which is legitimate fear if your codebases are tightly coupled (i.e. this app used Vulcan as a library, and that app links to this library that almost all of our applications use, so now it's all under the AGPL). The problem is not contributing changes to Vulcan upstream, it's the risk of the license infecting proprietary software. This is super cool, and I am definitely going to dig into this for personal projects. I really appreciate the work you put in, and you open sourcing this. The licensing is entirely up to you, and I'm going to poke around in it either way; but it is a killer for trying to use it in enterprise-y environments.