[3825]

Any sources behind the claim that agpl is behind the lack of success for rethinkdb?

I am very bullish about agpl. As far as I understand, the choice of agpl has no effect on your code which you put in a repository. Is that not the case?

[scotu]

As I wrote in another comment here I'm really surprised by the shallow reasoning of fellow developers regarding AGPL: https://news.ycombinator.com/item?id=13643645

I mean, I might not understand the finer legal details but thinking "all your code you see after using anything GPL has to be GPL" is really weird, did this people ever used a linux kernel? (yes I know GPL is different from AGPL and at a high level I also know what is different)

[lvh]

Define "your code which you put in a repository"?

Disclaimer: IANAL. AGPL enforcement is generally a little unclear. If you ship a binary, you have to make the source available. If your binary answers on the wire but you don't ship it you (under the APL) have to make the source available.

So, uh, yes -- as long as you never use it, which seems a little silly of a definition?

[gpm]

> Define "your code which you put in a repository"?

... Code you add with the equivalent of `git add; git commit`. I.e. suppose git was AGPL instead of GPL, that would have no effect on the license of say, Rust (MIT+Apache) regardless of the fact that git is used in the development.

[lvh]

My apologies, I completely misunderstood your question.

Again, (A)GPL enforcement is unclear and subject of real debate, but my understanding is that nobody thinks virality impacts data being used by the program (e.g. source code in a VCS).

[fadzlan]

Honest question, although on a bit different topic I guess.

Does AGPL prevents some company creating Github like services for Pijul?

[lvh]

There is serious disagreement between serious legal scholars (Moglen, Rosen) about what kind of cooperation between components would trigger (A)GPL virality clauses. Linking counts according to one, but not the other; IIUC everyone agrees subprocesses don't count.

So, assuming said company would not want to AGPL their code (and assuming they don't distribute binaries), that choice would imply some technical decisions they would presumably not be very happy about, but overall: no.

[WorldMaker]

I think the problem with the AGPL is that we don't know. The virality of the AGPL hasn't really been tested in courts of law yet, and it is easy to assume the worst, especially if you consider trying to need to explain AGPL terms to lawyers in a court case, much less a potentially non-technical juror.

[kibwen]

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

[qznc]

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!

[kibwen]

Being open-source doesn't make it any harder to build a centralized source code hosting site, it just makes it harder to get VC funding. :P

[ben0x539]

It sounds like the authors' motivation is to create something that doesn't need a central hub to compete, to fight centralization.

I expect their idea of success is also very different from github's.

[chriswarbo]

> Does AGPL prevents some company creating Github like services for Pijul?

Not at all, if their service is AGPL licensed.

Of course, many companies may not want to use AGPL, and there's a whole lot of discussion on this page regarding what might/might-not be allowed to work around the AGPL. However, I didn't see anyone mention the possibility of, you know, using the AGPL, which is the entire reason the authors chose it ;)

[Avshalom]

Not really it just means the ticket tracking/wiki/etc... features can't get so cozy with pijul that they become 'derivative works'.