3 ms·

It depends how you look at it: 1. I would contribute to GCC because it's still "free". 2. I would have contributed to Caddy, but now they are half commercial,

It depends how you look at it: 1. I would contribute to GCC because it's still "free". 2. I would have contributed to Caddy, but now they are half commercial, so I'm disinclined to provide my "free" to their commercial success. Most decent people that I know would calmly do the same. Most leeching off Caddy will send the vitriol to the author. But, they are not his community, now they are his customers.

csdreamer7 9y ago
> It depends how you look at it: 1. I would contribute to GCC because it's still "free". 2. I would have contributed to Caddy, but now they are half commercial, so I'm disinclined to provide my "free" to their commercial success. Your argument would apply to any Apache or BSD licensed code. Not just Caddy. Caddy has used the Apache 2 license for 2 years. Why would you not contribute now vs when the license was committed? Because they are not providing full free builds anymore? The public source code you are contributing to is still free. Nothing would have stopped anyone else from slapping a EULA on a custom Caddy build to sell. It feels like a poor reason to refuse to contribute to an Apache licensed project.
- kilburn 9y ago
  License isn't everything. An Apache licensed project with no commercial offering will happily incorporate your improvements whenever they meet its quality standards and scope. Now, when the company controlling the upstream project is chafging for the same functionality your patches provide... let's just say ut is going to be harder to contribute them upstream. That's why I find it a no-brainer to invest in and contribute back to open source projects without "paid features available" whereas I will avoid the same project when they do. Projects where maintainers get money through support contracts are fine for me, although a similar argument may be made regarding the project's documentation/easiness of configuration.
  - Whitestrake 9y ago
    > Now, when the company controlling the upstream project is chafging for the same functionality your patches provide... It's important to correct this statement, which is either disingenuous or just incorrect. Light Code Labs is not charging its users for the functionality of the Caddy server. They are charging its users to provide pre-compiled binaries with optional customization in the form of a selection of plugins and server types. Don't conflate binaries distributed under EULA via the build server at caddyserver.com with the actual functionality of the (still 100% free) software. You're welcome to (not) contribute and (not) benefit, at your leisure. As the actual post linked by OP states, the maintainers tried support contracts. Nobody bought them, so it wasn't sustainable. Their options were to look for other solutions or stop maintaining the project. You may or may not prefer that they abandoned it instead, but they made a choice.
- deleted 9y ago
  [deleted]
- stordoff 9y ago
  (This doesn't necessarily apply to Caddy, I'm thinking more abstractly) Licensing isn't everything. There's a difference in attitude between an open source project that provides commercial services to support itself and a commercial project that also has an open source version. It's a fuzzy line, but "is this good for business?" and "does this make it a better project?" don't always align.

csdreamer7 9y ago

> It depends how you look at it: 1. I would contribute to GCC because it's still "free". 2. I would have contributed to Caddy, but now they are half commercial, so I'm disinclined to provide my "free" to their commercial success. Your argument would apply to any Apache or BSD licensed code. Not just Caddy. Caddy has used the Apache 2 license for 2 years. Why would you not contribute now vs when the license was committed? Because they are not providing full free builds anymore? The public source code you are contributing to is still free. Nothing would have stopped anyone else from slapping a EULA on a custom Caddy build to sell. It feels like a poor reason to refuse to contribute to an Apache licensed project.

kilburn 9y ago
License isn't everything. An Apache licensed project with no commercial offering will happily incorporate your improvements whenever they meet its quality standards and scope. Now, when the company controlling the upstream project is chafging for the same functionality your patches provide... let's just say ut is going to be harder to contribute them upstream. That's why I find it a no-brainer to invest in and contribute back to open source projects without "paid features available" whereas I will avoid the same project when they do. Projects where maintainers get money through support contracts are fine for me, although a similar argument may be made regarding the project's documentation/easiness of configuration.
- Whitestrake 9y ago
  > Now, when the company controlling the upstream project is chafging for the same functionality your patches provide... It's important to correct this statement, which is either disingenuous or just incorrect. Light Code Labs is not charging its users for the functionality of the Caddy server. They are charging its users to provide pre-compiled binaries with optional customization in the form of a selection of plugins and server types. Don't conflate binaries distributed under EULA via the build server at caddyserver.com with the actual functionality of the (still 100% free) software. You're welcome to (not) contribute and (not) benefit, at your leisure. As the actual post linked by OP states, the maintainers tried support contracts. Nobody bought them, so it wasn't sustainable. Their options were to look for other solutions or stop maintaining the project. You may or may not prefer that they abandoned it instead, but they made a choice.
deleted 9y ago
[deleted]
stordoff 9y ago
(This doesn't necessarily apply to Caddy, I'm thinking more abstractly) Licensing isn't everything. There's a difference in attitude between an open source project that provides commercial services to support itself and a commercial project that also has an open source version. It's a fuzzy line, but "is this good for business?" and "does this make it a better project?" don't always align.