4 ms·

>commercially available library Are there any examples of this? How do you monetize a DLL file? One time purchase and later upgrades? It seems like you'd have

by andai 2y ago

>commercially available library Are there any examples of this? How do you monetize a DLL file? One time purchase and later upgrades? It seems like you'd have to put it behind an API and charge for usage, though I don't have a good overview of what the other options are.

alemanek 2y ago
This used to be much more common. I worked on a product in 2004 that licensed a library around providing a nice SDK for different payment processors. Effectively making it super simple to switch or route payments to different processing gateways. We paid on a per domain basis and also paid a yearly maintenance fee to get updates. Nothing stopped us from just using the library in ways that violated the license but we didn’t. The threat of lawsuit is an effective deterrent if the ethical concerns aren’t. In my experience for B2B the people that are going to steal from you were never going to pay anyways.
- tonyedgecombe 2y ago
  >In my experience for B2B the people that are going to steal from you were never going to pay anyways. I used to think that but eventually the evidence pointing to the opposite was overwhelming. It wasn't just small companies either, some of them you will have heard of.
gettalong 2y ago
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.

by andai 2y ago

alemanek 2y ago

This used to be much more common. I worked on a product in 2004 that licensed a library around providing a nice SDK for different payment processors. Effectively making it super simple to switch or route payments to different processing gateways. We paid on a per domain basis and also paid a yearly maintenance fee to get updates. Nothing stopped us from just using the library in ways that violated the license but we didn’t. The threat of lawsuit is an effective deterrent if the ethical concerns aren’t. In my experience for B2B the people that are going to steal from you were never going to pay anyways.

tonyedgecombe 2y ago
>In my experience for B2B the people that are going to steal from you were never going to pay anyways. I used to think that but eventually the evidence pointing to the opposite was overwhelming. It wasn't just small companies either, some of them you will have heard of.

gettalong 2y ago

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.