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

Mozilla

[Anonymous Coward]

Would this be anything like the difference between mozilla and netscape?

Mozilla is open source, and is what Netscape is/was based on, however Netscape added additional features like AIM.

Hired or not hired...

[Anonymous Coward]

Wouldn't it make sense to open source the code that has been developed BEFORE you've been employed by the company? At that point, you own the code.

At the point where they hire you to write MORE code, it is legally theirs, as they paid for it.

Wouldn't that be a reasonable solution to the problem? After all, as a mechanical engineer anything I develop while I work for a company they own. I don't see why software "engineers"... should be any different.

Strange that no one has mentioned...

[Frothy Walrus]

the BSD License.

IANAL

[sterno]

I Am Not A Lawyer... You need a lawyer. Hire one and ask him, not Slashdot.

Re:IANAL

[Aapje]

I Am Not A Lawyer... You need a lawyer. Hire one and ask him, not Slashdot.

That's true, but he still needs to know what to ask the lawyer. It's very helpful to have some idea of the basic solution (and have the lawyer work out the ugly details).

I have five points of advice:

1. Make sure that there is a clear division between the open source code and the custom glue. You might want to state in your standard contract that closed code must always be in seperate files* (not intermixed with open source) and that your framework can function 'properly' without those files (you need a lawyer to write that down in legalese). This will prevent contamination of your open source framework and will help avert/settle disputes ("I won't pay for that plug-in architecture", "It's much cheaper if we just [awful hack], do that.").
   
   *It's even better to place all custom code in a single package/library per client. That way, you can very easily argue what is theirs and what is yours.
2. Choose a standard license for the open source part (if possible). Reading custom licenses sucks and a potential user will have to ask a lawyer for advice. Because of this, a non-standard license will decrease the appeal of your open source solution significantly. The LGPL is a good option if you fear that someone else will close your framework and push you out of the market. It will also enforce the seperation between closed and open source code. The BSD license will increase the appeal of your code. The GPL doesn't seem suitable in your case (because it doesn't allow closed source libraries).
3. Only accept contributions when the copyright is turned over to you. This will simplify IP issues immensly (changing open source licenses, for instance). Of course, the same goes for your client. You probably should give them the copyright for their custom code though.
4. Make sure that the client understands not just the legal implications of the contract, but also the reasons for having an open source framework. If they don't understand open source, they may ask you to close all the code developed under the contract or to do other silly things. Invest in some preliminary client education.
5. Don't skimp on a lawyer. You will regret it later if you don't seek proper legal advice from a smart IP lawyer.

Close it up

[The Bungi]

And laugh all the way to the bank. The very fact that you submitted this shows that you're thinking about it, but remember this: idealism does not a car payment make.

Asking the people who read Slashdot about these things is like asking Martha Stewart about investment advice. What do you think you're going to hear? I doubt you'll get a lot of useful legal advice on how to handle licensing and negotiations. But you're sure to get advice on how to give away your work more efficiently.

Close it up. Make a killing. That is also a freedom.

(hope you read at -1)

Re:Close it up

[afreniere]

And laugh all the way to the bank. The very fact that you submitted this shows that you're thinking about it, but remember this: idealism does not a car payment make.

I beg to differ. I think mixed licensing is the way software is going in the long term: Robust, well-debugged, open-source frameworks (e.g. Darwin) with closed-source, well-researched, well-marketed apps on top of them (e.g. Aqua). Open-source and closed source have different strengths, and if you can take advantage of both then your proprietary product will be that much better off. Every case will be different though. Without knowing what this particular application is, it's hard to say which license he should go with. Seems like he thinks OSS is best for the framework though, which is consistent with its strengths, IMHO.

-Ansel.