Hacker News Reader

Comment by jbk | Hacker News Reader

Thanks a lot for the answer and the proposal. But we do not want to have anything critical that is not open source. We try to promote OpenSource, so using non-open-source software is hard to do.

1. Thanks, but see above :)

2. As I said, custom labels are way too limited, as people on the open-letter-to-github said, so I will comment on the issue.

3. Will do.

4. same as 1 :) But thanks a lot.

I will contact you :)

View on HN

Thanks, I get that you don't want to be on proprietary code. I'm look forward to your email. And we're open to discussing open sourcing features if that is needed.

I don't know if that would apply to GitLab too, but maybe consider switching from the CE / EE model to just one "product" and a free for non-commercial model? Like e.g. http://3t.io/mongochef/download/ does it? I like that model way more than a feature-reduced version.

We considered that but we value having a completely open source version for all projects more. For more information about how we see the difference between CE and EE please see https://about.gitlab.com/about/#stewardship

What about having a single product, and charging for a proprietary license + support? This may work better with GPL as many large orgs are allergic to it.

With MIT license, many sites probably just implement the branding changes etc in the CE product on their own.

We want to give large orgs the option to run GitLab without having to pay us. We don't mind having people add features to CE, these are the same people that will send enahancements upstream and make GitLab better for everyone.

Have you ever considered using the AGPLv3 for the Community Edition, rather than the all-permissive MIT license?

I'm pretty sure they take outside contributions for CE, so if that was AGPL3 they wouldn't be able to use it in Gitlab EE, which sounds like shooting themselves in the foot.

They could require a CLA for outside contributions. Many organizations do that.

Reply on news.ycombinator.com