Hacker News Reader

Comment by scotu | Hacker News Reader

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)

View on HN

>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.

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

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.

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?

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

> 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_Lice...

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.

> 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.

> 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.

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

> 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?

As long as you keep them seperate enough, via APIs or.else, no issue at all.

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.

>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

> 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.

I was reading this[0], but didn't scroll down through the comments. It appears you are correct.

However, I think if you just installed Pijul on a server and then called it through your operating system interface, then you _might_ be fine. You might need to make it so the interface to Pijul is generic and could swap out with other VC systems.

I still might also be wrong about this. I'm not a lawyer and the comments in [0] are on both sides of the argument.

[0] http://softwareengineering.stackexchange.com/questions/10788...

EDIT: edited to express less certainty over my interpretation of the license

> then called it through your operating system interface, then you _might_ be fine

Might, exactly. Depending on various courts accepting there is a loophole in GPL, and my layman understanding is that there isn't. Skimming GPLv2 I don't see them differentiating in derivative works between those that use compile time linking and those that use mechanisms like CLI. I'm weary of bringing after the fact constructs to justify something that GPL doesn't talk about. And after all how is CLI that much more different than dynamic linking - CLI is merely an interface that is subjectively a bit more friendly in certain situations but this imo shouldn't a have a bearing in legal discussions.

> 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..

Mission accomplished?

You can't add proprietary bits to their system without contributing those bits back so everyone can have them. Boo hoo.

This is the big conceit of copyleft licenses: that "derivative works" are exclusively "modified and extended versions of the program" to use the FSF's terminology, and not a small piece of a much larger system.

It's easy to imagine wanting to add Pijul support to Tower, SourceTree, Gerrit, Phabricator, etc. - projects that all dwarf Pijul. But these projects will be unable or unwilling to risk doing so, because of the AGPL.

I'm sorry, but that's nothing but FUD. Tell me exactly why those projects would be unable to integrate.

I literally wrote that you need to publish that under AGPL any extensions, so you didn't really blew my mind there...

It definitely be part of something like Gitlab (or github, bitbucket or AWS CodeCommit), you just have to model your business around the fact that the software is available to everybody. You know, like wordpress (sure, they are GPL so they can have some proprietary components but the practical implication is that you CAN create your own, for pay, wordpress.com service).

Plugins can be a different story. Does the software have a rest interface? then use that, no license virality. If it doesn't, you release them AGPL

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.

Reply on news.ycombinator.com