4 ms·

Impressive. Much respect. Enterprise crippleware is obnoxious. So are restrictive and radioactive licenses like AGPL. What bugs me are those who speak out of t

Impressive. Much respect. Enterprise crippleware is obnoxious. So are restrictive and radioactive licenses like AGPL. What bugs me are those who speak out of the sides of their mouth how it's not with different flavors of rationalized BS. Bug fixing priority, tech support, and integration consulting are the proper places to monetize, not features for-profit express turnpike or telling me what I can't do with code.

riskneutral 4y ago
> Bug fixing priority, tech support, and integration consulting are the proper places to monetize Yeah ... the problem is, you can't charge a corporate millions of dollars for that off the bat, but you sure can charge the millions of dollars for software licensing. And they are happy to pay it. In fact, they want to pay to it, it makes them feel more secure and they have a budget to use.
- cvccvroomvroom 4y ago
  The easy way to do that is to have themes and branding. Call it something else. "Enterprise Edition". Then they can enjoy the nice, warm fuzzy feeling of different logos.
YPPH 4y ago
I don't see anything wrong with the AGPL. If $bigCorp wants to rent access to improved versions of my software, they should give me the changes.
- pabs3 4y ago
  AGPL doesn't require that $bigCorp give you the changes, only that they give their users the changes. You could get changes from existing users, but they might not be willing or able to help you. You could become a user, but that could be expensive or $bigCorp could just ban you from the service.
  - YPPH 4y ago
    I really can't say whether that's correct or not. IANAL. The licence in terms says you must give Corresponding Source to users "interacting with it remotely through a computer network". Does it suffice if I initiate a connection to a public $bigCorp server (and receive "access denied")? Or must I be able to successfully connect? Maybe $bigCorp could put a proprietary authentication proxy in-between to avoid me "interacting with" the software. So, let me narrow my comment to address what you've said. If $bigCorp wants to rent me access to improved versions of my software, they should give me the changes.
    - pabs3 4y ago
      Your revised comment is definitely correct now. Not sure about your questions since IANAL but I guess it depends on the details of how $bigCorp's server setup works. If they have some other software that controls access to the AGPLed software, then maybe they don't have to give non-customers source code. If the login form comes from the AGPLed software, but non-customers don't have a login, then maybe the non-customers do interact with the software in a limited way, so source code obligations may come into play.
npteljes 4y ago
Nothing about AGPL prevents anyone monetizing bug fixing, tech support and integration consulting. You can also do whatever with the code. You just need to provide it if you host the project as a service.
michaelt 4y ago
> Bug fixing priority, tech support, and integration consulting are the proper places to monetize I know this is a widespread business model, but it's always seemed backwards to me. Having my customers pay me more when I produce more bugs and lower usability? That sounds like a reward for doing a bad job.
- pabs3 4y ago
  While it does seem like a perverse incentive, there will always be more customers than you are able to provide service to anyway, since no matter how good your documentation and how perfect your install process, issues will arise at the boundaries between your software and the customer's other systems, so integration services are valuable. In complex systems there will be more bugs than you can fix, so prioritization is valuable. Support is valuable because of the customers who have less experience with the software than you.
quadrifoliate 4y ago
Wait, isn't the license [1] on this repo AGPL? While I would like to voice a general protest against the AGPL FUD, it's also somewhat strange to do it in the same breath as "Much respect" for Citus here. ---------------------------------------- [1] https://github.com/citusdata/citus/blob/master/LICENSE https://github.com/citusdata/citus/blob/master/LICENSE

riskneutral 4y ago

> Bug fixing priority, tech support, and integration consulting are the proper places to monetize Yeah ... the problem is, you can't charge a corporate millions of dollars for that off the bat, but you sure can charge the millions of dollars for software licensing. And they are happy to pay it. In fact, they want to pay to it, it makes them feel more secure and they have a budget to use.

cvccvroomvroom 4y ago
The easy way to do that is to have themes and branding. Call it something else. "Enterprise Edition". Then they can enjoy the nice, warm fuzzy feeling of different logos.

YPPH 4y ago

I don't see anything wrong with the AGPL. If $bigCorp wants to rent access to improved versions of my software, they should give me the changes.

pabs3 4y ago
AGPL doesn't require that $bigCorp give you the changes, only that they give their users the changes. You could get changes from existing users, but they might not be willing or able to help you. You could become a user, but that could be expensive or $bigCorp could just ban you from the service.
- YPPH 4y ago
  I really can't say whether that's correct or not. IANAL. The licence in terms says you must give Corresponding Source to users "interacting with it remotely through a computer network". Does it suffice if I initiate a connection to a public $bigCorp server (and receive "access denied")? Or must I be able to successfully connect? Maybe $bigCorp could put a proprietary authentication proxy in-between to avoid me "interacting with" the software. So, let me narrow my comment to address what you've said. If $bigCorp wants to rent me access to improved versions of my software, they should give me the changes.
  - pabs3 4y ago
    Your revised comment is definitely correct now. Not sure about your questions since IANAL but I guess it depends on the details of how $bigCorp's server setup works. If they have some other software that controls access to the AGPLed software, then maybe they don't have to give non-customers source code. If the login form comes from the AGPLed software, but non-customers don't have a login, then maybe the non-customers do interact with the software in a limited way, so source code obligations may come into play.

npteljes 4y ago

Nothing about AGPL prevents anyone monetizing bug fixing, tech support and integration consulting. You can also do whatever with the code. You just need to provide it if you host the project as a service.

michaelt 4y ago

> Bug fixing priority, tech support, and integration consulting are the proper places to monetize I know this is a widespread business model, but it's always seemed backwards to me. Having my customers pay me more when I produce more bugs and lower usability? That sounds like a reward for doing a bad job.

pabs3 4y ago
While it does seem like a perverse incentive, there will always be more customers than you are able to provide service to anyway, since no matter how good your documentation and how perfect your install process, issues will arise at the boundaries between your software and the customer's other systems, so integration services are valuable. In complex systems there will be more bugs than you can fix, so prioritization is valuable. Support is valuable because of the customers who have less experience with the software than you.

quadrifoliate 4y ago

Wait, isn't the license [1] on this repo AGPL? While I would like to voice a general protest against the AGPL FUD, it's also somewhat strange to do it in the same breath as "Much respect" for Citus here. ---------------------------------------- [1] https://github.com/citusdata/citus/blob/master/LICENSE https://github.com/citusdata/citus/blob/master/LICENSE