Having gone through 3 Hackathons in the past 2 months, I’m a little shocked about how little clarity there is about IP or legal grounding. It’s good to have an open collaborative environment, but it also leads to exceedingly mushy situations, in which people don’t have footing on who owns what — or what rights and claims are outstanding, that may throw a huge wrench in down the road.

Law could potentially be major cold water at any Startup Weekend or Hackathon — cooling off the openness and optimism of a newly formed team. But legal agreements could also set the right tone and expectations, and prevent small issues from spinning into huge, expensive headaches in a year.

I’ve culled together some good writings on what can go very, very wrong without some legal activity at a Hackathon (read IP battles and collaborators holding companies hostage) and what precautionary measures can be taken during a Hackathon to prevent these later headaches (perhaps, collaborator’s agreements — check some out in Docracy, which has a Hackathon bundle and also various ‘Collaborators’ agreements).

If your Hackathon goes well, and (some) of the team wants to move forward, you may have IP issues from the hackathon experience. See Scott Walker’s blog post on the danger of outstanding Intellectual Property Issues that can doom a venture:

IP Ownership. There are three deadly mistakes that relate to intellectual property (IP) ownership, all of which usually surface when the investors conduct their due-diligence investigation:

1. You must confirm that none of the founders’ prior employers has any rights to the venture’s IP because he or she was “moonlighting” while previously employed. This is a particular concern if the startup is in the same space as a founder’s prior employer.

You should carefully review all employment-related agreements (e.g., offer letter, non-disclosure and inventions assignment agreement, etc.) and the employee handbook to determine if there are any provisions that may give the prior employer rights to your startup’s IP. If there is a problem, some employers will agree to execute a waiver, which you can show investors down the road.

2. Any IP created or acquired by a founder (e.g., code, logo, domain name, etc.) prior to incorporation must be assigned to the company. Usually this is done as part of the founder’s restricted stock purchase agreement, pursuant to which the IP is contributed as full or partial consideration for the shares of common stock issued to him or her in a tax-free transaction under Section 351 of the Internal Revenue Code.

Similar to the vesting issue above, a huge problem arises if one of the founders leaves prior to incorporation and takes his rights to the IP along with him; or if the assignment of IP is not properly made and the founder leaves prior to this issue being cleaned-up. In both cases, the company is once again in the difficult position of trying to negotiate with a departed founder.

3. You need to make sure that any IP created by outside developers (i.e., non-founders) is assigned to the company. Sadly, this issue comes-up all the time — just ask the Winklevoss twins. Indeed, had Mark executed an inventions assignment agreement, there probably would be no Facebook; or if there were, the twins’ (or their company) would own the IP.

This is a particular problem prior to incorporation. The IP created by the developers often never gets assigned to the company either because there was no written agreement or because the company was not a party to the agreement (because it didn’t exist at the time). Then when it’s time to fix the problem because investors are requiring it, the company needs to chase-down the developers (some of whom may be outside the U.S.) and start negotiating with them.

Docracy, the open legal document repository, has some documents, and some advice on good legal health practices for the Hackathon environment. Veronica on Docracy wrote a great post & conversation, quoted below, that goes through some of the strategies and responses to dealing with the chaos of Hackathon IP and legal issues.

What should you sign at a Hackathon?

Docracy’s prototype was built in two days, at the TechCrunch Disrupt Hackathon. Matt and John would have benefited from a hacker’s hand, but asked themselves: what’s going to happen to the work that this guy will do for us? What should we sign with him, without looking like the uncool kids? So, they worked alone and won the hackathon anyway. Every lawyer that hear this story tells them they did the right thing. Legally, the IP rights to the code belong to the developer, but authors of joint works can’t assign IP without consent from the other authors: that’s why, right after incorporation, the IP is assigned to a newly incorporated company via a specific contract.

But what happens in most cases? Likely, the classic “let’s forget about it, and hope for the best”, even though failing to assign IP is one of the four deadly mistakes that startups make. How people that want to turn a weekend project into a company cope with this pre-incorporation issue? I asked first to Niko Pipaloff, that started developing his idea for Tagify at the NY Startup Weekend, with some other entrepreneurial people.

Niko:

I am a first time entrepreneur and really had no particular expectations when I pitched at Startup Weekend. It wasn’t until the end of the event when I decided to pursue the company full time did the issue of IP arise. It ended up working out fine since team members generally were committed to continue on the project or had other interests and had no problem assigning the IP. I could see it going another way, however.

The “another way” it’s not just the Zuckerberg/Winklevoss story. It’s the lost value of a startup that doesn’t own its technology, and the risk of having to share profits with someone that didn’t put any stake in the company. For this reason, most angels and VCs enquire about the legal risks around the product before financing a company.

I had good legal counsel which helped me to ensure all IP issues were resolved quickly. I think it is very important to tie up any legal loose ends before engaging with investors. They want to know that you have thought through all that and minimized the risk.

Niko also points out something very true: most code from hackathons gets thrown away, and is rewritten from scratch anyway. For this reason, coding events always overlooked at the problem. With one notable exception: Seedhack.

Seedhack is an hacking event hosted by Seedcamp, a micro-seed investment program based in London. For the first edition of Seedhack, with more than 100 hackers participating, Carlos Eduardo Espinal, partner and co-manager of the fund, asked a lawyer to draft a simple, one-page “Founder Collaboration Agreement” that was presented to the participants at the beginning of the hackathon.

Carlos:

Our mission is to foster entrepreneurship, eliminating risk and the fear of risk as much as possible. That’s why we wanted to solve the problem of company formation in advance. Nothing is worse than disagreement amongst founders on splitting the pie, that’s why we suggested a “fluid” document, which can be adapted to the founding team’s needs, without legal technicalities, and only covering the major issues: IP, founders’ equity, vesting and exit. During Seedhack, we didn’t asked people to sign the contract, of course. However, we explained the benefits associated with it and we encouraged teams that were interested in entrepreneurial ventures to have a conversation about it. This kind of legal education can help avoid costly mistakes.

Discussing about splitting might look silly when there’s no pie yet, but maybe that’s just an impression. Charlie O’Donnell of Brooklyn Bridge Ventures suggests a reality check:

Charlie:

Hackathons and Startup Weekends have really risen in quality over the last few years–so I’m not surprised that there are real companies coming out of them. The problem is that one of the biggest things I see going wrong in the early days of a startup isn’t the technology or the market–it’s nuts and boltsy startup stuff like not getting along with your co-founder. Co-founder issues around equity and expectations around time commitment sink a ton of companies before they get off the ground, which is why it’s important to get that stuff squared away early.

While some developers still feel awkward at the mere thought of having this conversation, Carlos said that hackers understood the value of the document, and more than one team ended up using it. Some participants wished the document was available to other hackathons, too. For sure, Carlos’ educational effort would be easier if major coding events recommended the same standard document (hint: you can branch and sign it using Docracy).

It’s hard not to like Seedhack’s agreement: short, simple and in plain English. But are there better ways to fix this problem? For example, including the IP license in the generic “hackathon rules” that everybody signs to enter the hackathon, so nobody needs to be the uncool guy? Phil Weiss, a grad student and clinitian at BLIP (Brooklyn Law Incubator and Policy), offered an alternative view and branched the document:

Phil:

I applaud Seedcamp’s efforts to try and alleviate this problem, but the Agreement, unedited, seems to lead to results that are practically irrational and normatively troubling. First, the timing of signature has to be perfect, and it seems presumptuous to set percentage equity–a process usually requiring several, careful negotiations–in the sometimes-frantic setting of a hackathon. If the agreement is drafted too early, a coder that later provides only meaningless contributions could receive an underserved windfall. If the agreement is signed too late, the team is in the same state as if they hadn’t drafted the agreement at all; an early, but necessary contributor that later left the team could be left out. Second, part of what makes the hackathon a great mechanism for building great companies is its openness. If teams have individualized agreements in place, the overarching generativity of the setting is diminished because a team may be more inclined to reject the input of non-team members.

Indeed, splitting the pie with people you don’t know, and that might end up working with another group in a couple of hours, is hard, and it’s pretty obvious that most teams won’t need to sign anything. But it’s never too early for writing down basic principles like IP assignment and vesting. Phil liked the idea of delegating the decision to the organizers:

A derivative to a mandatory licensing regime may adequately address these problems. Hackathons themselves could claim temporary ownership of all IP created at the event. Upon a showing of contribution to the project, collaborators could purchase the rights to their works back from the hackathon at a nominal, flat rate. Although this may create opportunities for hackers to squeeze out their partners before launching a startup, at least potential ventures can bargain over IP rights pre-launch and avoid the uncertainty of a wandering, unknown author.

Check out Phil’s version here and, in the spirit of collaboration, let us know if you have a better one!