4 ms·

Honestly, I initially wanted to make my software AGPL because it seemed quite attractive, but all these problems, or supposed problems even, just made me not wa

Honestly, I initially wanted to make my software AGPL because it seemed quite attractive, but all these problems, or supposed problems even, just made me not want to deal with it and I made the software proprietary instead. It was a SaaS that I was fine with letting end users copy and tinker with but didn't necessarily want big companies to do the same. Now that's obviously against Free Software, but I couldn't be arsed to deal with the nuances, and I found that at least for a SaaS that you'd like to make money off of, proprietary is the likely way to go.

swiley 5y ago
Big companies don’t touch AGPL stuff with a ten foot pole.
- ttiurani 5y ago
  This is good to know and precisely the reason I use AGPLv3 whenever I can. IMO open source developers writing code on their free time for the common good or just for fun should make sure with a licence like AGPLv3 that their work isn't appropriated by fundamentally immoral corps to increase profits. It isn't a badge of honor that a FAANG uses your library, it's just exploitation.
- LinuxBender 5y ago
  I witnessed this. There was a process to submit licenses to legal. People didn't follow the process and their projects were killed off just prior to completion as audits would surface licenses. This happened multiple times. People tried to argue with legal, but they wouldn't even entertain the conversation.
- pabs3 5y ago
  Its not exactly hard to comply with the AGPL. Just choose either to not modify the software, or if you do then link to the git repo you store the changes in.
  - swiley 5y ago
    It doesn't matter though. The GPL was easy to comply with, AGPL completely freaks them out.
    - pabs3 5y ago
      Why? Is it that they haven't read the AGPL yet?
  - rstuart4133 5y ago
    > Its not exactly hard to comply with the AGPL. Just choose either to not modify the software Unfortunately, the GPL and AGPL suffer from the same flaw: they don't rigorously define what a derivative work is. The way the licences are written they make the definition seem self evident, but it's self evident the way porn is self evident - everyone knows it when they see it. For example, from the way the GPL is written, dynamic linking to something makes it a derivative work, but invoking services from a http server is not. So how about I circumvent your GPL licence by putting an RPC shim layer than talks over http? Some projects have solved the problem by drawing their strict demarcation lines. For example, Linus has publicly stated on numerous occasions that using the kernel user user space API does not make a user space program a derivative work of the Linux kernel. Somewhat more dubiously, they seem to tolerate kernel modules that use GPL kernel symbols only. I've convinced myself that strong, clear demarcation is fundamental to Linux being accepted everywhere. The reason this is important is when you say "choose to not modify the software", the software in question is the original software or any derivative work. The problem is there is no clear definition of when your code becomes a derivative work. If you give a lawyer that much wriggle room and put enough money up as the prize, and you end up spending 10's of millions defending lawsuits from Oracle's lawyers trying to wriggle through an "API is copyrightable" loophole. A GPLv4 that insisted the licence holder clearly define what they consider to be a derivative work would IMO be a big step forward in copyleft licences. Oh and get rid of the "Installation Information" requirement, or at least make it compatible with code signing. A device defending itself by insisting any binary it runs is signed by a trusted source is not compatible with defining the private keys securing the signature are "Installation Information".
rakoo 5y ago
> It was a SaaS that I was fine with letting end users copy and tinker with but didn't necessarily want big companies to do the same. Now that's obviously against Free Software If you're talking about Libre Software then you were totally right in picking the AGPL: the goal is to put the user in control, not intermediaries. A big company providing a service through your software is not a user so you don't owe them anything. AGPL is actually the best license because if a company uses it, they must give their users the freedom you wanted to give users in the first place. > I found that at least for a SaaS that you'd like to make money off of, proprietary is the likely way to go. The always-renewed armada of email providers, all of them being just a slight variation of the same stack (postfix/dovecot/cyrus/rspam/any unix). It's the same for pretty much any internet service: I do believe that if it weren't for Open Source (not Libre Software), half of them wouldn't have taken the time and money to develop the necessary bricks. Google, Facebook, Twitter, and their monstruous influence, were made possible due to Open Source licenses that voluntarily didn't want to care about the user specifically. The success of your business will be orthogonal to the licence you choose. You are providing a service, ie making sure the software runs, isn't slow, is at the last secure version, allows people to register etc... none of which depends on whether your software is Open Source or not.

swiley 5y ago

Big companies don’t touch AGPL stuff with a ten foot pole.

ttiurani 5y ago
This is good to know and precisely the reason I use AGPLv3 whenever I can. IMO open source developers writing code on their free time for the common good or just for fun should make sure with a licence like AGPLv3 that their work isn't appropriated by fundamentally immoral corps to increase profits. It isn't a badge of honor that a FAANG uses your library, it's just exploitation.
LinuxBender 5y ago
I witnessed this. There was a process to submit licenses to legal. People didn't follow the process and their projects were killed off just prior to completion as audits would surface licenses. This happened multiple times. People tried to argue with legal, but they wouldn't even entertain the conversation.
pabs3 5y ago
Its not exactly hard to comply with the AGPL. Just choose either to not modify the software, or if you do then link to the git repo you store the changes in.
- swiley 5y ago
  It doesn't matter though. The GPL was easy to comply with, AGPL completely freaks them out.
  - pabs3 5y ago
    Why? Is it that they haven't read the AGPL yet?
- rstuart4133 5y ago
  > Its not exactly hard to comply with the AGPL. Just choose either to not modify the software Unfortunately, the GPL and AGPL suffer from the same flaw: they don't rigorously define what a derivative work is. The way the licences are written they make the definition seem self evident, but it's self evident the way porn is self evident - everyone knows it when they see it. For example, from the way the GPL is written, dynamic linking to something makes it a derivative work, but invoking services from a http server is not. So how about I circumvent your GPL licence by putting an RPC shim layer than talks over http? Some projects have solved the problem by drawing their strict demarcation lines. For example, Linus has publicly stated on numerous occasions that using the kernel user user space API does not make a user space program a derivative work of the Linux kernel. Somewhat more dubiously, they seem to tolerate kernel modules that use GPL kernel symbols only. I've convinced myself that strong, clear demarcation is fundamental to Linux being accepted everywhere. The reason this is important is when you say "choose to not modify the software", the software in question is the original software or any derivative work. The problem is there is no clear definition of when your code becomes a derivative work. If you give a lawyer that much wriggle room and put enough money up as the prize, and you end up spending 10's of millions defending lawsuits from Oracle's lawyers trying to wriggle through an "API is copyrightable" loophole. A GPLv4 that insisted the licence holder clearly define what they consider to be a derivative work would IMO be a big step forward in copyleft licences. Oh and get rid of the "Installation Information" requirement, or at least make it compatible with code signing. A device defending itself by insisting any binary it runs is signed by a trusted source is not compatible with defining the private keys securing the signature are "Installation Information".

rakoo 5y ago

> It was a SaaS that I was fine with letting end users copy and tinker with but didn't necessarily want big companies to do the same. Now that's obviously against Free Software If you're talking about Libre Software then you were totally right in picking the AGPL: the goal is to put the user in control, not intermediaries. A big company providing a service through your software is not a user so you don't owe them anything. AGPL is actually the best license because if a company uses it, they must give their users the freedom you wanted to give users in the first place. > I found that at least for a SaaS that you'd like to make money off of, proprietary is the likely way to go. The always-renewed armada of email providers, all of them being just a slight variation of the same stack (postfix/dovecot/cyrus/rspam/any unix). It's the same for pretty much any internet service: I do believe that if it weren't for Open Source (not Libre Software), half of them wouldn't have taken the time and money to develop the necessary bricks. Google, Facebook, Twitter, and their monstruous influence, were made possible due to Open Source licenses that voluntarily didn't want to care about the user specifically. The success of your business will be orthogonal to the licence you choose. You are providing a service, ie making sure the software runs, isn't slow, is at the last secure version, allows people to register etc... none of which depends on whether your software is Open Source or not.