131–140 of 180 posts
Earlier quoted context omitted.
If you buy a macOS machine today, it ships with bash3.2 by default. That's the last version that was GPLv2. It is a decade old by now. Some companies most definitely care.
As I've mentioned elsewhere, git is GPL, so Macs are screwed regardless. :P
It's not about GPL, it's about GPLv2 vs GPLv3 and the requirements that come with it.
Sadly, I'm afraid the AGPL license is going to make this untouchable to businesses… :-( [Edit] Interestingly, they cover that. I suppose if you're just running Pijul rather than integrating with its code, it might be safe to use in a corporate environment. Still, it's likely to be offputting.
Earlier quoted context omitted.
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…
>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 .
Earlier quoted context omitted.
Only uneducated people think that merely using or deploying AGPL software is 'problematic' in any way. Please don't spread that unreasonable fear.
I can't even.
Earlier quoted context omitted.
>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 .
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?
Earlier quoted context omitted.
> 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 appl…
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…
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.
Earlier quoted context omitted.
All that sounds like differences in the intr internal model. From everything I have understood it wor would be possible to reimplement git to store only patches, their position in the commit tree and the commit hash, and have it behave exactly like the git reference implementation. Is the difference between patches and git commits in a DAG really only a difference in internal representations or is there a user-facing…
Speed is about the only user-facing difference. But the big user-facing difference is that commits are glued to their parents. They really are glued; the merges and potential conflicts involved with rebasing and cherry-picking are a consequence of trying to undo this glue. Darcs' and pijuls' patches aren't glued, they only either commute or do not, and the conflict resolution mechanisms for non-commutative patches ar…
Earlier quoted context omitted.
It does not prevent any company from creating a Pijulhub. However, if you make modifications to Pijul or link it as a library into other code, that code must be made open-source. (And note that GitHub doesn't even use the original git written by Linus, they wrote their own implementation, libgit2.)
Afaik libgit2 is a derivative of git. Anyways, for Pijul to be successful, there must be something like PijulHub. The bar is higher now. Thus, make it easy to build this hub!
Earlier quoted context omitted.
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…
>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 .
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.
Earlier quoted context omitted.
Indeed, but if can accurately deduce what the behavior will be from a few relatively simple rules, then that is an excellent basis for forming an intuition.
That's a deduction… intuition is usually drawing conclusions based on pattern-matching on similar situations (e.g. 'how do I do this in git/svn?').
If by intuitive we mean "matches the patterns that other people expect (e.g. git/svn)" then obviously Pijul is not intuitive. But if once one learns the basics, it becomes fairly easy to infer what the tool will do in more advanced cases, then one might say it is at least "intuitable".