6 ms·

Why do you find it offputting? IANAL but it basically doesn't allow you to add code to (or get code from) Pijul itself and making it in another license. You can

by scotu 10y ago

Why do you find it offputting? IANAL but it basically doesn't allow you to add code to (or get code from) Pijul itself and making it in another license. You can use it to store closed source code, you can host it yourself, offer it as a sevice for money, you can even create your own extensions as long as you release them AGPL... I feel that AGPL for a product is misunderstood and pre-rejected without justification by far too many. Now, if you are developing a library, then AGPL sucks as a license for it, but for a cohesive product? Seems acceptable to me (not sure if it's my favorite choice)

omginternets 10y ago
>I feel that AGPL for a product is misunderstood and pre-rejected without justification by far too many. Isn't that precisely the parent comment's point? Perhaps it shouldn't be this way, but the argument is that the AGPL will make pijul "untouchable" by businesses, de facto.
- scotu 10y ago
  but does granparent commenter find it off putting now that he realized it's not content viral? It's weird that it's not today's Oracle or Microsoft equivalent spreading the FUD/false info nowadays but developers in discussions on this very site. AGPL explicitly does not touch the content it processes, I expect a legal department to be pretty good at understanding that unless they heard something and don't bother to read the license. Anyway I don't really care anymore. We act based on what we believe not on facts (this is not directed to any parent comments, to be clear). Whatever
  - omginternets 10y ago
    Again, I think the two of you are arguing on different levels. You're saying AGPL shouldn't be offputting. He's saying that by some quirk of circumstance, it is. In other words, his argument is that picking AGPL was a poor strategic decision, given its (admittedly undeserved) baggage.
- 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.
- bedros 10y ago
  you should check the AGPL with ghostscript. Personally, I will stay away from any AGPL code. Basically, ghostscript says you cannot distribute AGPL code with your commercial code, even though they are not linked together, not even on the same media. https://ghostscript.com/doc/current/Commprod.htm https://ghostscript.com/doc/current/Commprod.htm
stormbrew 10y ago
Here's the thing: Lawyers are expensive and legal implications are often not obvious to non-lawyers. Without a really really compelling reason to invoke them to clear the use of an AGPL project, clearing the use of it as non-threatening to the business' distribution model is probably not worth it. This is why businesses ban it outright.
frant-hartm 10y ago
> offer it as a sevice for money Yes, you can, but if you add something - like issue tracking, user/access management etc.. around that then you need to publish that under AGPL as well.. It means it will never be part of something like github, bitbucket or AWS CodeCommit. And then there are plugins to CIs (checkout from repository ...) - would those be affected?
- mynewtb 10y ago
  As long as you keep them seperate enough, via APIs or.else, no issue at all.
- dbmikus 10y ago
  Correct me if I'm wrong, but this only means that if you modify the code or directly incorporate the code library into your own, you must distribute your work. If you are just calling the service through it's API (either CLI or through the programming language interface), then you don't need to distribute anything. This just protects against people taking open source code GPL, modifying it for themselves, using it in backend services, and then never distributing their modifications.
  - frant-hartm 10y ago
    >directly incorporate afaik this means any kind of linking (static or dynamic), using a jar or using a npm package or similar.. >through the programming language interface which implies some version of the above
  - RaleyField 10y ago
    > If you are just calling the service through it's API That's contestable afaik. > through the programming language interface i.e. dynamically linking which is usually understood to be prohibited unless linking code has a compatible license. > either CLI Here's the problem - you can take any GPL library, make small CLI or REST adapter for it and license it GPL as well, then use that adapter from your proprietary application - is that still allowed? Because if it is then GPL can't ever be enforced and if it isn't you can't call CLI APIs even if original libraries themselves provide it.
deleted 10y ago
[deleted]

by scotu 10y ago

omginternets 10y ago

>I feel that AGPL for a product is misunderstood and pre-rejected without justification by far too many. Isn't that precisely the parent comment's point? Perhaps it shouldn't be this way, but the argument is that the AGPL will make pijul "untouchable" by businesses, de facto.

scotu 10y ago
but does granparent commenter find it off putting now that he realized it's not content viral? It's weird that it's not today's Oracle or Microsoft equivalent spreading the FUD/false info nowadays but developers in discussions on this very site. AGPL explicitly does not touch the content it processes, I expect a legal department to be pretty good at understanding that unless they heard something and don't bother to read the license. Anyway I don't really care anymore. We act based on what we believe not on facts (this is not directed to any parent comments, to be clear). Whatever
- omginternets 10y ago
  Again, I think the two of you are arguing on different levels. You're saying AGPL shouldn't be offputting. He's saying that by some quirk of circumstance, it is. In other words, his argument is that picking AGPL was a poor strategic decision, given its (admittedly undeserved) baggage.
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.
bedros 10y ago
you should check the AGPL with ghostscript. Personally, I will stay away from any AGPL code. Basically, ghostscript says you cannot distribute AGPL code with your commercial code, even though they are not linked together, not even on the same media. https://ghostscript.com/doc/current/Commprod.htm https://ghostscript.com/doc/current/Commprod.htm

stormbrew 10y ago

Here's the thing: Lawyers are expensive and legal implications are often not obvious to non-lawyers. Without a really really compelling reason to invoke them to clear the use of an AGPL project, clearing the use of it as non-threatening to the business' distribution model is probably not worth it. This is why businesses ban it outright.

frant-hartm 10y ago

> offer it as a sevice for money Yes, you can, but if you add something - like issue tracking, user/access management etc.. around that then you need to publish that under AGPL as well.. It means it will never be part of something like github, bitbucket or AWS CodeCommit. And then there are plugins to CIs (checkout from repository ...) - would those be affected?

mynewtb 10y ago
As long as you keep them seperate enough, via APIs or.else, no issue at all.
dbmikus 10y ago
Correct me if I'm wrong, but this only means that if you modify the code or directly incorporate the code library into your own, you must distribute your work. If you are just calling the service through it's API (either CLI or through the programming language interface), then you don't need to distribute anything. This just protects against people taking open source code GPL, modifying it for themselves, using it in backend services, and then never distributing their modifications.
- frant-hartm 10y ago
  >directly incorporate afaik this means any kind of linking (static or dynamic), using a jar or using a npm package or similar.. >through the programming language interface which implies some version of the above
- RaleyField 10y ago
  > If you are just calling the service through it's API That's contestable afaik. > through the programming language interface i.e. dynamically linking which is usually understood to be prohibited unless linking code has a compatible license. > either CLI Here's the problem - you can take any GPL library, make small CLI or REST adapter for it and license it GPL as well, then use that adapter from your proprietary application - is that still allowed? Because if it is then GPL can't ever be enforced and if it isn't you can't call CLI APIs even if original libraries themselves provide it.

deleted 10y ago

[deleted]