4 ms·

The library is dual-licensed as AGPL plus a commercial license. So everything is in the open and can be tested and tried out under the AGPL. Once the library is

The library is dual-licensed as AGPL plus a commercial license. So everything is in the open and can be tested and tried out under the AGPL. Once the library is used in a commercial context, you nearly always need to buy the commercial licenses to stay compliant. This is how it generally works. What the commercial license does is a different thing. You could charge once OR once and for every upgrade to an (arbitrarily defined) new major version OR each year via a subscription OR ... It is really up to you and how you want to handle this.

pabs3 2y ago
The AGPL is pretty easy to comply with in a commercial context even if you are using it as part of a SaaSS product. Just either use the code unmodified, or release your modifications to customers, or to the public in general. Do the businesses buying commercial licenses just not understand the AGPL license? or are their development processes not rigorous enough to ensure compliance? The AGPL includes some easy ways to be forgiven for accidental violations, so that should not be a problem in almost all cases. So only deliberate non-compliance should be an issue.
- gettalong 2y ago
  I'm not a lawyer but I think you mistaken in this regard. One indication for this is that otherwise some major companies would have problems. For example, the GPL FAQ has the following part in the FAQ item title "What is the difference between an 'aggregate' and other kinds of 'modified versions'?" (https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation): > If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. A combined work needs to be distributed under the AGPL, an aggregated work does not. Since Ruby is interpreted the code of HexaPDF loaded from the application would run in the same address space and thus it would be a combined work. The following two links are also relevant: https://opensource.stackexchange.com/questions/5003/agplv3-source-redistribution-when-does-it-apply-to-my-code-for-a-server-side-ja/5005#5005 https://opensource.stackexchange.com/questions/5003/agplv3-s... and https://opensource.stackexchange.com/questions/5010/can-i-use-the-middleman-loophole-to-reduce-agpl-to-lgpl/5011 https://opensource.stackexchange.com/questions/5010/can-i-us...
  - pabs3 2y ago
    Just add an AGPL command-line interface, or a daemon wrapping the library and you have a process boundary. That doesn't necessarily create a derivative work boundary, but it probably would if it is generic enough to be useful to everyone.
    - gettalong 2y ago
      Yes, creating a binary and calling that would circumvent the AGPL. But then everything will be more complex and slower. Also, doing this extra work and developing the binary is probably more expensive than just buying a commercial license.

pabs3 2y ago

The AGPL is pretty easy to comply with in a commercial context even if you are using it as part of a SaaSS product. Just either use the code unmodified, or release your modifications to customers, or to the public in general. Do the businesses buying commercial licenses just not understand the AGPL license? or are their development processes not rigorous enough to ensure compliance? The AGPL includes some easy ways to be forgiven for accidental violations, so that should not be a problem in almost all cases. So only deliberate non-compliance should be an issue.

gettalong 2y ago
I'm not a lawyer but I think you mistaken in this regard. One indication for this is that otherwise some major companies would have problems. For example, the GPL FAQ has the following part in the FAQ item title "What is the difference between an 'aggregate' and other kinds of 'modified versions'?" (https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation): > If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. A combined work needs to be distributed under the AGPL, an aggregated work does not. Since Ruby is interpreted the code of HexaPDF loaded from the application would run in the same address space and thus it would be a combined work. The following two links are also relevant: https://opensource.stackexchange.com/questions/5003/agplv3-source-redistribution-when-does-it-apply-to-my-code-for-a-server-side-ja/5005#5005 https://opensource.stackexchange.com/questions/5003/agplv3-s... and https://opensource.stackexchange.com/questions/5010/can-i-use-the-middleman-loophole-to-reduce-agpl-to-lgpl/5011 https://opensource.stackexchange.com/questions/5010/can-i-us...
- pabs3 2y ago
  Just add an AGPL command-line interface, or a daemon wrapping the library and you have a process boundary. That doesn't necessarily create a derivative work boundary, but it probably would if it is generic enough to be useful to everyone.
  - gettalong 2y ago
    Yes, creating a binary and calling that would circumvent the AGPL. But then everything will be more complex and slower. Also, doing this extra work and developing the binary is probably more expensive than just buying a commercial license.