Sad news. I moved all of my repos from GitHub to Gitorious in order to get away from proprietary software, and now I'm (almost) back at square one. The public GitLab instance at gitlab.com runs the proprietary version, so I cannot move my repos there.

I like GitLab more than Gitorious on a purely technical level, but GitLab unfortunately has a CLA[0] and uses the MIT expat license, whereas Gitorious used the AGPL.

>We have the CLA to ensure this we're on the right side of copyright law.

I appreciate that. I think you have good intentions. The author of the article is Bradley Kuhn, who works at the Software Freedom Conservancy. He's an expert when it comes to the legal aspects surrounding free software projects, so perhaps having a conversation with him about the CLA would be a worthwhile experience.

"We have the CLA to ensure this we're on the right side of copyright law."

The CLA is only a license, another license than MIT, but doing _almost_ the same things. IIRC, the difference is that it gives you okay to make proprietary distributions without respecting MIT conditions.

You do not need it to be "on the right side of copyright law".

Using MIT-licensed code is on the right side of copyright law just as well. (unless what you want is to disobey poor old MIT)

> I moved all of my repos from GitHub to Gitorious in order to get away from proprietary software

> I guess I will just self-host my own GitLab CE instance now.

I moved from Google Code to a forked version of indefero[1]. I would be happy to post the link but I don't want to be a shameless post. Indefero itself actually has some problems that I fixed (such as a scale problem), but otherwise it's pretty stable. I have over 100 projects in my instance and it's working really well.

I used Rhodecode for awhile before they sold out - and while it was nice looking - it seemed like every new version introduced a new bug or issue. It was also a pain upgrading.

A lot of people dislike google code because it doesn't have the "social" aspects of pull requests - but the pull requests I've offered have not been pulled or the author of the project wanted to keep requesting modifications that it just wasn't worth my time. The later was actually an important fix because his project was just completely broken...

I like google code because it's just simple no frills. Uploads/wikis/source all right there.

Plenty of alternatives are not necessarily a good thing. Repository/project software (and hosting even moreso) seems to be subject to tremendous network effects. One of the exciting things about gitlab is it seems the first such software (and with gitlab.com, service) since github took off to make a serious run at massive adoption. I doubt there's room to make an impact for another open source (excluding enterprise version) github-like that merely happens to be written in another language. The next next such project to make a serious run needs to innovate in some fashion.

GitLab.com runs the proprietary GitLab Enterprise Edition (EE). This is mostly to allow us to performance test EE features at scale, for more context see https://about.gitlab.com/2014/06/27/gitlab-com-runs-ee/ You can use the open source GitLab Community Edition (CE) to start a SaaS similar to GitLab.com. We hope people will recognize that CE is not crippleware and will be OK with hosting their code on GitLab.com. If not there are alternatives based on CE such as https://modernrepo.com/

Yes I've read that context and it makes sense. I was just observing that some people would want an absolutely pure (ie 100% free software) option rather than critiquing what you offer.

That said I do hope you take steps to reassure people who want to be using an option which preserves their software freedom, for example that the CE will not be slowly deprecated, more features moving into EE.

I admit that making a fully credible commitment is challenging: options include multi-copyrightholder-copyleft which presumably you don't want at all as an MIT licensed project + some proprietary bits in EE, and a variation on the Fiduciary License Agreement used for Qt. But those two options are copyright-focused; there are probably other mechanisms to be thought of.

We try to reassure people by adding more features to the open source version every month. In fact, since we released the proprietary enterprise edition, the pace of development for the open source version has accelerated. We never moved any features from the open source version to the enterprise edition and plan to never do this (except in edge cases with overlapping functionality). We're happy with the current MIT license. We tried an MIT license for the enterprise edition before but that was very confusing to customers.

I've been running Gitlab CE for a few years on a linode instance for a couple of dozen repos and it's really quite excellent; performance is very good. You do need to keep up with the monthly upgrades to get the new features (there's an upgrade script).

Recently Gitlab CE has undergone some quite significant UI updates along with very noticeable performance improvements. Excellent work guys!

If I read that uncharitably, (except...) looks like ample room to lead to the eventual demise of the open source offering.

But adding more features to the open source version every month is great. Hopefully that and a massive userbase sums to making it obvious that any substantial move towards deprecating the open source version will lead to a successful hostile fork, as there will be tons of people able and interested in doing that if necessary, resulting in you never making it necessary. :)

It is sad that enterprises are confused by freedom rather than demanding of it, but that's an issue for the software freedom movement to solve.

I build and admin a public RPM repo for our product. After installing gitlab's RPM, I was blown away. I have never seen a single RPM that large work that perfectly on the first shot. Either I am lucky, or more likely, you really put a lot of effort into your packaging. Cheers to you for a brilliant demo.

It didn't quite fit into our workflow - I think we would like to use gitlab as a beautiful web client, but then push our code there back into our own vanilla git repo on https/ssh. Gitlab seems as it is a turnkey product, repo hosted internally. It was certainly very easy to import our existing projects into it.

Good to hear that! We put a lot of effort into packaging GitLab to make it a 2 minute install even though it is a Rails application. We could not have done it without the awesome Omnibus packaging system that Chef so kindly open-sourced.

May I ask what the reason is you don't want to host the repo's in GitLab itself?

First I want to thank you and the developers for your work on GitLab. Currently GitLab's binary packages are distributed as a big rpm/deb with every package needed by GitLab (like PostgreSQL, Redis, Nginx etc.) inside it, and there are no official repositories, so one must manually download and install the Big package. Why can't we use the more traditional way with package dependencies?

I want to piggy-back off this: PLEASE all projects, continue to offer monolithic packages as an option. It takes an act of Congress to get some servers internet access to fetch packages; being able to download a VMWare image or a blob to install makes testing a whole lot easier.

That is possible, but you need to either need to mirror all gems or pick the 135 ones used by GitLab. And you need to set up a Debian package mirror as well. This might take a lot more time than the 2 minute Omnibus install :)

You're welcome. We're working on an official repository by using the awesome packagecloud.io software. This will be a big package but it will be easier to update (just use apt-get). Making a small native package is pretty hard but we're open to contributions http://feedback.gitlab.com/forums/176466-general/suggestions...

Thank you for coming forward in many discussions (not only HN), and giving time for people's questions.

I resent the way things went down, such as removing people's repositories, and paying gitorious developers to shut down the project. Those are history now, and I can't say they prevents anyone (anyone paying attention, that is) from taking a different route - fortunately, both projects are freely licensed and data is in git repositories.

They raise questions about the future though: next time people's code would be also removed? Will there be at least three months then, or less?

Why exactly doesn't Gitlab move freely licensed projects?

Since it bought the gitorious.org site, it's like you have two hosting sites, and want to close one down. For freely-licensed projects, making a copy is easy (whether people use it or not) - if Gitlab wanted to.

They will have to import their repo's into GitLab. This means that all their urls will change. This is quite unfortunate but we hope they'll appreciate the improved interface and features that GitLab brings such as a great merge request flow. Please let me know if you have any specific concerns.

I'm concerned about losing access to public projects that are not actively maintained, and thus won't make the transition to GitLab. Is it possible to leave Gitorious online in read-only mode after the May deadline?

Unfortunately that is not possible because of the hosting costs for Gitorious.org. We're reaching out to archive.org to index everything but it is probably not easy to git clone from there. Feel free to create mirrors of things that are important.

We don't want to move people's code without them agreeing with that move to another organization. But I agree the broken links are not nice. I'm not sure how practical it is to redirect projects that moved themselves.

Might it be possible to at least store copies on gitlab - say, have a project/user/organisation called gitorious with every gitorious project under it?
I can't admit that I know just how much stuff is hosted on gitorious, but it might not be too onerous.

The main reason for the acquisition is to give and communicate a clear upgrade path for existing Gitorious users. If someone wants to pay for the hosting costs to keep gitorious.org running longer we'd be happy to do that. Please email me at sytse@gitlab.com or comment here if you're interested.

>The main reason for the acquisition is to give and communicate a clear upgrade path for existing Gitorious users.

That's a pretty disingenuous thing to say when it seems like the only reason an "upgrade path" is needed in the first place is because of the acquisition and shutdown.

Edit: Even with Gitorious being "no longer sustainable" in its current form, there are other methods that could have been used (price adjustments, fundraising, etc) rather than an outright and very short-term shutdown.

No problem, thanks for asking. With the 1GB RAM Pi coming out running GitLab is a lot easier. It would be nice to have a precompiled Omnibus package for it (like the ones for other platforms on https://about.gitlab.com/downloads/). We hope someone will contribute this.

Thanks for raising this, we'll look into it. Some of our team just got a RPi2 in our (very delayed) christmas gifts. So we'll be trying to improve the situation. But if someone knows why precompiling fails only on Rpi's please comment in the issues.

I've got a few small projects on Gitorious, mostly because I wanted to avoid a GitHub monoculture (and the Gitorious software being AGPL'd helped too). Having an easy way to import from Gitorious to GitLab is nice, but I'd like to check out GitLab's public hosting features first. I had a poke around GitLab's website, but every page seems dedicated to selling GitLab-as-a-product. Are there any publically-visible projects hosted by GitLab?

meh, gogs doesn't inspire confidence. There is some serious issues going on, resulting in the inability to handle more then one request at a time. I brought it up to the dev, and did some explorations that found lots of data race problems, and got this lovely gem back from the dev:

"In my point of view, as long as no deadlock..data race is unavoidable."

Why does GitLab have to kill the AGPL instance of Gitorious they aqquired? Most of the people I know who use Gitorious.org did so so we could use an AGPL service to host our repositories. GitLab simply does not do this as it uses a lax permissive license. In addition to this they impose CLAs on any contributors :/ sigh

It is really a shame that GitLab feels the need to remove the only AGPL service that fills this need. I do not know where I will be migrating my repositories, but it will not be GitLab unless they wish to offer the community an AGPL instance.

Thanks! We have no plans for a mobile app at this point. We try to make GitLab work really well on mobile screens. There are also native mobile apps created by the community https://about.gitlab.com/applications/ but I'm not sure if they support working offline.