5 ms·

Precisely. I'm not arguing based on some reasoning of my own that AGPL is bad. I'm arguing based on working at a previous big company where if you checked in AG

by zellyn 10y ago

Precisely. I'm not arguing based on some reasoning of my own that AGPL is bad. I'm arguing based on working at a previous big company where if you checked in AGPL code, Ninjas in hazmat suits broke through the skylights and parasailed down to exorcise the toxic intrusion. Enough mixed metaphors?

zellyn 10y ago
For more info (can I just light up the DannyBee bat signal?), see all of these… https://hn.algolia.com/?query=dannybee%20agpl&sort=byPopularity&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=dannybee%20agpl&sort=byPopular...
chriswarbo 10y ago
> if you checked in AGPL code This sounds like taking some of Pijul's source code and putting it inside another project. That would certainly have business implications, which justifies ninjas. It's possible to use AGPL as a business strategy (I worked at a company whose main product used CPAL[1] which has a similar network-use clause); but such decisions should not be made via VCS commit. Of course, if the choice of AGPL prevents a business from reusing Pijul's code then presumably that's why they chose AGPL. That's kind of the point of copyleft. I imagine very few businesses would care about Pijul's source code though. If Pijul matures into a compelling tool, then the relevant phrase would be "if you used an AGPL command"; no need for ninjas there, unless (as others note) you're building a PijulHub or something. [1]: https://en.wikipedia.org/wiki/Common_Public_Attribution_License https://en.wikipedia.org/wiki/Common_Public_Attribution_Lice...
- millstone 10y ago
  If a BigCorp is to use AGPL code, it needs to erect internal barriers (on code search, etc) to ensure that said code does not find its way into other projects. Those internal barriers usually incur a cost that outweighs whatever benefit the code provides, relative to unencumbered alternatives. If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your needs forever into the future. That's a terribly foolish bet. A business founded on a principle of radical openness might be compatible with AGPL. But any business that wants to have some internal software (HR, etc) is well advised to stay the hell away from AGPL.
  - tom_mellior 10y ago
    > If a BigCorp is to use AGPL code, it needs to erect internal barriers (on code search, etc) to ensure that said code does not find its way into other projects. Yes, but this has nothing in particular to do with the AGPL and everything to do with copyright laws. There is no licence except public domain/CC-0 that allows BigCorp to incorporate other people's code without any obligations whatsoever (attribution, at least). Copyright laws forbid such incorporation by default.
  - chriswarbo 10y ago
    > If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your needs forever into the future. That's a terribly foolish bet. I agree; one of the many reasons I'm against proprietary software is that it forces users into this helpless situation. I don't quite get the "internal barriers" idea; is it common for companies to mix together code from multiple projects, including ones they don't own, such that it's difficult to disentangle them? Regarding your example, why would copy/pasting code from an internal code search be treated any differently from, say, searchcode.com? A modicum of diligence is always required regarding ownership, licensing, appropriateness, trust, etc.

by zellyn 10y ago

zellyn 10y ago

For more info (can I just light up the DannyBee bat signal?), see all of these… https://hn.algolia.com/?query=dannybee%20agpl&sort=byPopularity&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=dannybee%20agpl&sort=byPopular...

chriswarbo 10y ago

> if you checked in AGPL code This sounds like taking some of Pijul's source code and putting it inside another project. That would certainly have business implications, which justifies ninjas. It's possible to use AGPL as a business strategy (I worked at a company whose main product used CPAL[1] which has a similar network-use clause); but such decisions should not be made via VCS commit. Of course, if the choice of AGPL prevents a business from reusing Pijul's code then presumably that's why they chose AGPL. That's kind of the point of copyleft. I imagine very few businesses would care about Pijul's source code though. If Pijul matures into a compelling tool, then the relevant phrase would be "if you used an AGPL command"; no need for ninjas there, unless (as others note) you're building a PijulHub or something. [1]: https://en.wikipedia.org/wiki/Common_Public_Attribution_License https://en.wikipedia.org/wiki/Common_Public_Attribution_Lice...

millstone 10y ago
If a BigCorp is to use AGPL code, it needs to erect internal barriers (on code search, etc) to ensure that said code does not find its way into other projects. Those internal barriers usually incur a cost that outweighs whatever benefit the code provides, relative to unencumbered alternatives. If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your needs forever into the future. That's a terribly foolish bet. A business founded on a principle of radical openness might be compatible with AGPL. But any business that wants to have some internal software (HR, etc) is well advised to stay the hell away from AGPL.
- tom_mellior 10y ago
  > If a BigCorp is to use AGPL code, it needs to erect internal barriers (on code search, etc) to ensure that said code does not find its way into other projects. Yes, but this has nothing in particular to do with the AGPL and everything to do with copyright laws. There is no licence except public domain/CC-0 that allows BigCorp to incorporate other people's code without any obligations whatsoever (attribution, at least). Copyright laws forbid such incorporation by default.
- chriswarbo 10y ago
  > If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your needs forever into the future. That's a terribly foolish bet. I agree; one of the many reasons I'm against proprietary software is that it forces users into this helpless situation. I don't quite get the "internal barriers" idea; is it common for companies to mix together code from multiple projects, including ones they don't own, such that it's difficult to disentangle them? Regarding your example, why would copy/pasting code from an internal code search be treated any differently from, say, searchcode.com? A modicum of diligence is always required regarding ownership, licensing, appropriateness, trust, etc.