I'd just like to add that since Git supports SSH, it's pretty easy to set up git repos on any server. `cd ~; mkdir myrepo.git; cd myrepo.git; git init --bare`. Then you can just `git push username@server.com:myrepo.git`.
This of course doesn't give you a web UI for creating repositories. And everyone with access to `username` on the server can access all the repositories.
http://git.meyerhome.net:8080/ is my little arm box that is running it that you can at least check it out (warning: it is just a low end arm dev board, it probably will go down). I let GitHaven.com elapse when I realized I wouldn't be able to continue working on the project.
Edit: fyi GitHaven supports private repos which are the majority of the repos on my home server which you can't see (sorry!). The others were more tests or repos that are too huge (above the 300MB limit) to put on GitHub.com
My work legal department decided it was a conflict of interest (we use Git) and forbid me from working on it anymore.* So I open sourced it in the hopes that others besides just me (I run it at home) could find some value and maybe they would fork it and continue on with it.
* Ironically GitHaven's original goal was a solution that could be installed inside corporate firewalls, but without the cost of GitHub:Fi.
I started to get involved with the Git Servers at work (Not the primary admins or anything, just helping them not make the wrong choices <cough>gitorious</cough>). After that legal said if I do any GitHaven stuff on my own time from then on they would own it.
I have a long laundry list of issues, but it really came down to: Every few months I ended up spending a whole day fixing the server for one reason or another. I wasn't expecting the server to go down so much. Gitolite is a excellent counter example of something very simple you can set up, keep upgrading and it just keeps working.
After the fact that it was more effort than expected to keep it running I found the UI frustrating and annoying. This was all part of the reason I started GitHaven.
This is common in almost every mid to large size corporation in the US with a legal department. If you're working on a side project, it might be best to clear it up with your employer and make sure it's not a conflict of interest.
It's mainly an issue of copyright. The company wants to make sure it owns the IP to every line of code you write. For example, if you do some work on the weekend they want to make sure they own the copyright to that.
Every company I've worked for had a clause in my hiring contracts. Some will enforce it more than others.
What is shocking to me is that if I were working in say the automobile industry and I make a highly customized bike, these kind of clause would mean that my employer owns all of that.
Some may argue since I have paid for the components and not the company that would save me, but to be fair the programmer paid for his/her laptop/desktop, servers (if any), maybe even some programming tools. Does having most of the stuff to make a side project come for free make me eligible for giving up my IP to my employer? This is just insane.
In the video game industry this is rather common -- developers can be contractually forced to hand over their pet projects to the company they work for.
I don't understand why people don't reject their employment contracts when they include this sort of dumb shit. An employment contract is a negotiation.
I signed a similar clause, and while I probably could have balked and gone elsewhere, it is literally the only aspect of my employment that I don't like.
The people I work with are brilliant (which I knew going in), I am paid very fairly, my bonuses are tied directly to my personal performance, I have flexible hours, and complete autonomy to do whatever I need to get my job done.
If I _need_ to purchase a $10,000 server to do my job, I just buy one and expense it at the end of the month. I _might_ have to explain the need when someone sees the expense, but that's par for the course. If I need to buy a USB drive to get my work done, or a relevant book, nobody will bat an eye at it.
Also, I haven't chanced it, but I'm guessing that my employer would only exercise control if I built something related or tangential to our core product. If I made an IOS game, I'm pretty sure I get to keep it... but if I build a widget that makes the support or administration of our core product more efficient to use, I'm guessing I'd have a hard time starting my own business around it without my current employer pulling out the lawyers.
Not everybody here at HN seems to realize that negotiation is not always appropriate when your first priority is to get a job.
Thankfully I've never been in that sort of situation, but I've certainly been desperate enough in the past where I would have happily signed if it didn't look like they would be willing to "bend the rules" for me.
Or maybe they just love the job and think that the legal dept is a dick but that does not overshadow their love of the work being done at this company.
That's usually my first reaction to the AGPL -- Because most open source projects I try to file away as "This might be useful for XYZ client, or in a project that does UUU"
I'm not sure that this fits in that criteria, I could imagine installing this on a server, unmodified, and just for internal use. You're not breaking the license from my understanding, and you got some use without selling or modifying it.
This seems like the only time that I'm interested in something that's AGPL. I get most frustrated when things like libraries or widgets are marked as AGPL.
If I write a git pre-commit script for my repo in githaven, is that forced to be agpl?
I'm using githaven and yes.
If I want Geckoboard to show a chart of how many githaven commit per day I did, do I need to agpl geckoboard.com?
I don't know.
I'm not a lawyer. This is my interpretation and I would like comments.
<gnu.org> In AGPLv3, what counts as “interacting with [the software] remotely through a computer network?”
<gnu.org> If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online.
This of course doesn't give you a web UI for creating repositories. And everyone with access to `username` on the server can access all the repositories.