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.

Re:Strange that no one has mentioned...

[bizard]

and a rough analogy would be the BSD underpinnings of Mac OS X. Keep contributing to the underlying open framework while creating a proprietary extension.

IANAL

[sterno]

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

Re:IANAL

[C_Kode]

Yes he does need a lawer. However, I don't think there is any harm in asking Slashdot. There might be people on Slashdot who have expierence in this sort of issue, and his lawer might not. He can take their suggestions to his lawer, and discuss the posibilities with him.

Then he should ask a lawyer that does. I wouldn't ask a criminal lawyer about a divorice. I would ask an IP lawyer about software licensing. While asking slashdot could give you some good ideas, it could also steer you into a horrible mistake. Like they say. Advise is like assholes; everyone has one and most of them stink.

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.

where the boundary lies...

[jstoner]

Is subject to negotiation and specification. It's entirely up to you and your client to define it. I think the real sticky point is defining it well, and conducting the conversation in a non-confrontational way.

I think if you approach them in a friendly and open fashion, and talk about your concerns and commitments, they'll listen. You sound like an honest person, you're clearly not trying to rip them off, otherwise you wouldn't be troubled by this.

One guideline is special purpose/general purpose, which is vague. A more specific one is what gives your client a competitive advantage, versus something they wouldn't care whether their competitors had it or not. An example of the latter would be things like payroll software.

Your client probably has a pretty strong attitude on that subject. It would be important to know what it is before deciding how to proceed.

Re:where the boundary lies...

[oakbox]

The good thing, the really important thing, is that you are working on this now, before you become an employee. I made the HUGE mistake of going to work for a company to further one of my projects. The project got further along, but there were some major disagreements in management and the company split.

So now, who owns the code? WE DON'T KNOW. Make sure that your contract covers all the bases. Who owns what and for how long and what enhancements in the proprietary code can migrate back to your code base and how can those things be audited. What happens when the business relationship ends?

The company has a legitimate interest in having full value from the code they are paying to have created. YOU have a legitimate interest in not having your hard work sucked up into an IP litigation nightmare if things go south. Draw lines, talk to a lawyer, cover your ass.

Seperate projects

[gr8_phk]

I'd GPL and release everything you have to start with. That way you clearly define that part. Make it a library or dll so it remains separate and you don't mix code with thier business stuff. The legal issues here may force you to partition code in a clear way. I'd also make sure they are required to specify which things are to be proprietary and have everything else open by default (else they start claiming more and more).

Remember, you are holding all the legal cards regarding the code at this point. They are just holding some money.

Think as a business guy, not a techie

[PinglePongle]

Licensing is tricky, and it fundamentally affects what you can and can not do later on - once it's Open Source, it's hard to go back.
Here's what I'd do : hire a lawyer !
Work out why you want to go the Open Source route - it's morally good, and can make good business sense.
But if you're building an application that is very specific to a particular industry, it may not make sense. For instance, if you're writing software to automate the day-to-day running of a law firm, you prob. won't get much community input; you say you have a framework (check out www.jcorporate.com for ways of dealing with the "framework/application" licensing issue), but how much of the framework is generically interesting ?
As a business, Open Source is a very powerful way of getting traction with a piece of software. But you also have to feed it, keep the community happy, administer the rights of people to commit to CVS, ensure the project retains momentum - it's no free ride. And we really don't need another projet on sourceforge with a "pre-alpha 0.001 release" checked in 3 years ago, and a .plan file indicating world domination in 3 releases...
Open Source is absolutely right if your project makes sense to the OS community, and if you can expect significant contributions from the community in return. Don't go Open Source because you feel you should to retain street cred.
If you do decide to go OS, I'd suggest taking your code base, and take each source file - write the names on index cards - and split them into "Open", "Proprietary", "Not sure" (ideally with your sponsoring company). Hopefully, this process will help you decide where the boundary lies - it's a lot easier to decide when you're looking at concrete source files than discussing it in the abstract on slashdot...
That should make sorting out the rest of the files fairly straightforward.

Oh, and get a lawyer.