You consistently fail to mention that your project isn't a real open
source project, but (in best case) a commercial company that just makes
a part of your product available under a "open source" license. But you
also sell a non-AGPL edition, meaning that all contributors must sign a
CLA that grant your company a license to use all contributions under the
MIT license, without giving contributors the option of using their own
contribution under the same MIT license (or even GPL). The AGPL license
is often problematic to use in companies, so contributors might need a
commercial license to use their own contribution. So, you basically want
us to work for you for free ... and pay for it. That could perhaps be OK
if you were honest about it, but now it just looks like we still can't
trust you.
Also, knowing the history of your product, I wouldn't dare to be
associated with (or use) your GPL-incompatible product. AFAIK, you
stripped development history from all the public repositories, so we
can't know if you really own or have permission from all copyright
holders to use their contributions under the GPL-incompatible license. I
understand your architecture has a separate GPL server process to work
around the incompatibility between GPL Mercurial and your
GPL-incompatible product. The validity of that approach is also highly
questionable. I suggest all users of the GPL-incompatible product do
thorough investigation and consult a lawyer.
If you say that close sourcing was a big mistake and you learned
anything, then you totally have the option of undoing it by dropping the
CLA and taking the product back to GPL. That would re-enable the
co-operation with the GPL community that you broke. If not, it just
sounds like marketing BS to please this audience.
But sure, a free and open community project around an AGPL non-CLA fork
of your codebase could also work ... assuming you really have a full
product available under AGPL. Anybody could do that ... and they could
continue to take changes from your AGPL version, while you couldn't take
anything back to the GPL-incompatible version. That would also test
whether you still will send DMCA takedown notices to forks, as you have
done in the past. That is however not something I want to get involved
in. Also because I find AGPL very problematic and uninteresting in general.
Finally, I find it very rude and clueless that you post your marketing
blurb here on this list, and again try to recruit users and contributors
from our community to your company. Do you want us to do the same?
/Mads
Kallithea contributor,
not a lawyer,
not talking for anyone
On 06/13/2017 10:04 AM, Marcin Kuźmiński wrote:
Hi All,
Given the opportunity of this email thread, i'd like to pitch in the
open-source version of RhodeCode CE again.
- A fully functional, free AGPL v3.0 software
- based on a modern web framework - Pyramid
- we had almost 20 releases in last 12 months
- introduced major features like Git LFS, Mercurial Evolve
- per repo settings
- web mergeable pull requests
- integration framework
- and many more
- a quickly growing community use base we currently have over 170
people on our community slack channel.
As a part of Management team i must admit that close sourcing the
project was a big mistake, however, we learned our lesson, and bet on
the new business model that is based on OpenSource Core and RhodeCode
will have a CE free edition.
We talked a bit about some co-operation, and i believe it's a good
time to re-think this. I'll be blunt, i think that it doesn't look
like there a sense of two such similar open-source projects to exist.
I highly valued contribution from this community that was done into
the RhodeCode codebase, i invite everyone again to join and have an
influence on the tool you or your company is using regularly.
Happy to chat about any options again, if someone is interested.
Best,
_______________________________________________
kallithea-general mailing list
[email protected]
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
