I can't read a lot easily on my phone, but two observations:
A) they don't name the license they're using and I don't recognise it. They claim it's open source but the wordage I saw references lots of "personal use" "no reverse engineering" "no redistributing without explicit permission".
B) their faq and comparison pages are inconsistent - faq says ldap/oauth is in both editions, comparison page says those features are enterprise only.
> you must also publicly release any code that connects to an AGPL piece of software over a network. I fear the day that an HTTP server is built using AGPL. Think about it.
I don't think this is true, which part of the AGPL license implies that? It is my understanding that AGPL means that even if you don't redistribute the software with that license - you still need to put the sources online. Nothing about interaction of 3rd part software.
After all database servers are released under AGPL - like mongoDB among the popular ones.
RhodeCode was already Open Source once and it then went "closed source"[1]. That event resulted in creating a truly Open Source fork called Kallithea[2] (GPLv3) held under Software Freedom Conservancy[3] umbrela.
I wonder if they tried to cooperate with SFC, as it seems they have choosen an Open Source license incompatible with Kallithea (AGPL vs GPL3)? Would those two projects try to work together?
There is not much choice if you need Mercurial self-hosting unfortunatelly, so this move is much appreciated.
Agree, Mercurial definitely lacks a self-hosting platform. Not quite sure about _truly Open Source_ though: AGPLv3 is also Open Source (http://www.gnu.org/licenses/agpl-3.0.en.html).
Regardless of the license compatibility, RhodeCode seems to be developed much more actively (looking at https://code.rhodecode.com/).
We're in constant contact with SFC, we also talked to Bradley about OpenSource RhodeCode.
We picked AGPL since this is what we believed would be the best option for us. RhodeCode 4.X is totally different project now, and as for Kallithea, we will see how this works out. We're of course open to cooperate with other projects.
10 comments
[ 3.0 ms ] story [ 10.8 ms ] threadA) they don't name the license they're using and I don't recognise it. They claim it's open source but the wordage I saw references lots of "personal use" "no reverse engineering" "no redistributing without explicit permission".
B) their faq and comparison pages are inconsistent - faq says ldap/oauth is in both editions, comparison page says those features are enterprise only.
you can find its full text here along with the source code: https://code.rhodecode.com/rhodecode-enterprise-ce/files/946...
Being AGPL means my interest in this is now extinguished anyway, but the information on the site doesn't inspire confidence either.
> you must also publicly release any code that connects to an AGPL piece of software over a network. I fear the day that an HTTP server is built using AGPL. Think about it.
I don't think this is true, which part of the AGPL license implies that? It is my understanding that AGPL means that even if you don't redistribute the software with that license - you still need to put the sources online. Nothing about interaction of 3rd part software.
After all database servers are released under AGPL - like mongoDB among the popular ones.
I wonder if they tried to cooperate with SFC, as it seems they have choosen an Open Source license incompatible with Kallithea (AGPL vs GPL3)? Would those two projects try to work together?
There is not much choice if you need Mercurial self-hosting unfortunatelly, so this move is much appreciated.
[1] http://ebb.org/bkuhn/blog/2014/07/15/why-kallithea.html [2] https://kallithea-scm.org/ [3] https://sfconservancy.org/
Regardless of the license compatibility, RhodeCode seems to be developed much more actively (looking at https://code.rhodecode.com/).
We're in constant contact with SFC, we also talked to Bradley about OpenSource RhodeCode.
We picked AGPL since this is what we believed would be the best option for us. RhodeCode 4.X is totally different project now, and as for Kallithea, we will see how this works out. We're of course open to cooperate with other projects.