Open Source/Proprietary - An Issue of Two Codebases?

g00mba_b0y asks: "For the past year I and a small team of developers have been working on an open source targeted, general business application framework. I say targeted because we have not yet selected a licensing model and placed the code in the public domain (we are working on some specific functional targets). I recently demonstrated the framework to a potential client who liked what they saw, and wants to use the software for their flagship product. In addition, they want to hire me to further the development of the framework as well as participate in the development. The sticking point is the structure of the legal agreement. I'm really interested in two things: the experiences of developers who are doing something like this (how did you address the IP issues); and links to any information on this subject."

"We agree in principle that the framework related development that they will be funding should be available for open source licensing, while code related to their business should remain proprietary. The tough part is coming up with a legalese definition of where the boundary lies, and a means of addressing disagreements when they occur.

I've done my homework and found a ton of information on licensing strategies, motivations for OSS, etc., but nothing so far that addresses how companies, who are funding open source initiatives alongside commercial development efforts, draw the line between the two."

Comments

negotiation and specification

[hormiga]

We have done this sort of thing for several years, and never found an acceptable broad license and contract provision to cover it. The only things that has worked well is to base the agreements on specifications, saying "implementations of interfaces marked A are ours, implementations of interfaces marked B are yours". Of course, the specification always changes (evolves, matures), so there is a constant review and negotiation process. So you end up saying (in the agreement) something like "the parties will from time to time meet and confer to extend the specification, and set the licensing for new or modified interfaces in the same manner as has been done already in Exhibit 1".

It is a good idea to specify the general principles by which the code will be covered by this license or that, but the explicit division with a list of interfaces (or modules or components) should override the general principles. You can always amend the agreement later. If the relationship has broken down to the extent that you can't amend the agreement, then there is probably no point anyway to amending it. Then, at least what you have done up to that point is covered by the explicit decisions already made. Just don't go too long without a review and decision process. (It's good engineering anyway to review the specifications and agreements periodically, so that the customer gets what he wants and you have a consistent, considered design.)

In the end, if you don't have a good relationship, all the contract language in the world won't necessarily save you from grief.

Keep the code bases separate. There should never be any doubt what you claim belongs in one category or the other. Put a clause in the agreement that has the customer waive rights to protest the decision if he hasn't done so within some specific period of time from having become aware of the way you have classified things. Of course, during the review period you can't release any of the code to the public (or GPL or whatever), in case it turns out your decision was inappropriate, else you will have released your customer's proprietary code which might be a breach of contract or trade secret law.

How we handled this exact situation.

[davesag]

I was asked to build a commercial b2b exchange a few years back and simultaneously to that I had been devoting a lot of energy to thinking about building a better app-server based around xml, jini and javaspaces. So when approached I said yes - as long as I can pick the development team and get cut in on the deal. In retrospect I would have not gone for the equity but that's a political issue not a technical one.

I put together a small team of people I knew who were also interested in the same general thing, and who were all fleeing like lemmings from the boo.com meltdown, and we thrashed out a rough design and worked out a budget and, issues of funding and business admin aside - sheesh startups - we built a bespoke sattelite reinsurance exchange based on cocoon, tomcat, apache server, outrigger and the jini1.0 stuff. we built it in three layers. the first, as the end result was to be a web app, was in retrospect not dissimilar to apache struts but tied cocoon to the javaspace (you can see more detail on this at O'Reilly's OnJava site) and used xsl to render the pages. The little bit of bespoke code we wrote to shuffle objects between cocoon and the space we dubbed Crudlet and declared it to be open source targeted, and registered crudlet.org. The package name was org.crudlet. The next layer provided the generic b2b exchange and negotiation layer. We called it tennis because it represented a series of exchanges across a net. It too provided very generic functions and so was also open source targeted as org.curdlet.tennis as it builds on crudlet. The final layer contains the actual business knowledge - What is an offer of capacity on M$300 worth of Ariane 5 launch. What's the launch schedule for the next few years etc etc. What's a reinsurer? These things all went into a com.risk2risk package that extended the classes in tennis and crudlet and was considered to be proprietary to the company.

We recruited developers from the various OSS projects we used when we could, and made ot very clear to new recurits how the code layers were structured. We also got complete approval from the Board of Directors to pursue this strategy. The fact that I was one of three like-minded technical directors also helped of course. But we were well outnumbered by the suits who were very sceptical at first. A further project grew out of the team - a kind of javasapce backed version of hibernate or castor - called javastore but it never really went anywhere.

Much of what we open sourced was rapidly superceeded by things like Struts and Hibernate and Karajan (which grew out of crudlet) and when the whole reinsurance industry melted down post Sept 11 2001 and the whole project was put on ice by the investors, the only code that was really iced was the proprietary layer. The developers showed incredible loyalty, committing bug fixes on their very last day of work that kind of thing, and I still keep in touch with many of them.

The business arguments were all around costs. OSS == cheaper. Developers will work for less if they get to keep their code after the project is done. Developers can be excited by things other than money. As long as the basic rate is comfortable for them, and that's always a subjective matter. Sure there are other good reasons for OSS, security, corporate tranparancy and accounability, due dilligence etc, but the bottom line with investors is always the bottom line. Anything else is just woolly for most of these people. Also the ethos of open source permeated the team - everyone worked on the inside of a huge oval shaped ring of desks. lots of power mac g4s running osx, a nice rack with some great hardware in it, a groovy office in soho, cvs servers, a network admin who loved his job. and everyone being paid to write code 90% of which they would get to keep afterwards.