Slashdot Mirror
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."
I don't think this really fits his situation. We're talking about two distinct parts here: an OSS framework and a closed source codebase on top of that. The question is where to draw the boundary. It's not one codebase with 2 licenses; it's 2 codebases that are closely related, each with a different license.
if(!cool) exit(-1);
dual licensin
I think we're missing the point. The question is not how to license the same code in two ways, it's how to differentiate between framework code and application code.
How does one define the difference between a framework (i.e. Jakarta Struts), and an application written with that framework? If there are enhancements made to the framework to satisfy issues related to or which directly impact the employer's application, where does that code lie?
This sig for rent.
If the code is structured to make it easy to differentiate between the proprietary part and the open source part, this shouldn't be a problem. If you don't, it won't just be a legal problem, it will be a mantainance nightmare.
Give the proprietary section and the open source sections clearly different names, place the source for each in different places with different file names, and use those names in the contract.
For example, in Java, I would have two separate code bases: com.thecompany and org.myproject. I would keep a separate source directory for each, including separate build scripts (although the proprietary one might call the OSS one.) The legalese would refer to the "org.myproject" code by name.
Finally, when in doubt, place new code in the proprietary base. You can always migrate it into the OSS one (I hope!), but once in the OSS one it's hard to get out. That's true of any library vs. application or private vs. protected vs. public (source, not legalese) decision: start restrictive, and migrate out.
I would recommend you to set up a small company with the co-developers of your software. It gives a lot of clarity about the ownership of the software and you can all become employees with your own company. In most countries the employer of a programmer becomes the copyright owner of the software that the programmer writes. And being your own employers... ;) You'll need legal advice in setting up the company.
The company doesn't have to live from licensing alone. Consultancy is another way of making money. Be sure to make it clear in every consultancy contract what the copyright status of written software is, your liabilities, etc. Legal advice will save you a lot of money in the long run.
extern warranty;
main()
{
(void)warranty;
}
In the past, one of the projects that I worked, we seperated the client from the server. The server side was to be GPL, the library to interface was LGPL, and then the client side was to be closed. We were also suppose to create a simple web front-end to the server using the library so that it would encourage development. However, that was 2.5 years ago in colorado, just before the tech meltdown (thank you govenor owens for such wise picking of tech companies to come here and then fold ).
And a suggestion -- get the company to foot the bill. They want you and your stuff, but are worried about their stuff being contaminated. $500 or a $1000 to have a 3rd party who is is experienced in this sort of thing might be expensive to you personally, but for a company that is willing to pay you 50 or 60 times this amount annually, it's cheap.
Then you'd just have to work out (in advance) if the IP lawyer is going to draw up a contract that everyone is expected to sign unchanged, or if it is just going to be advice that can be modified....
--
grnbrg
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.
For Helix Community, we have a dual-licensing model which gives the community an OSI certified license (RPSL), and a more commercially focused license (RCSL). Additionally, there are components that remain proprietary.
Where do you draw the line? That's always tough, but having the dual-license makes it easier to err on the side of opening up "too much".
Rob Lanphier
Helix Community Coordinator
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.
I used to have a better sig than this, but I got tired of it
I've had to deal with the same problem several times, as I've built a number of specific applications based on a common underlying framework, to which I retain the copyright etc.
Frequently, in the course of developing a specific application, enhancements to the underlying libraries are needed (thus the dual code-base and liscensing problem). I have always had good luck explaining to the firms who hire me that I can save a great deal of time (an money) when developing their application by utilizing my libraries. I agree to grant them a long-term liscense to use my libraries as a condition of the contract. My contract also spells out that any changes made in the underlying library are copyrighted by me, even though such changes may have been mandated by, and created as part of, their project.
I've had a couple of companies question this arrangement (huffy lawyer types mostly). I explain that I'll be more than happy to write a product entirely free of my libraries, but that doing so will doubtless add several hundred billable hours to the development/debugging cycle. They quickly conclude that as long as I agree not to charge ongoing fees for the use of my libraries they'll happily grant me the copyright.
So far, it's worked like a charm. If a feature is specific to their business, it goes in the application code, if it has broader application, it goes in MY code, I bill for the hours, and I have an even better set of libraries to dangle in front of the next client.
I agree, this is exactly what I've done at my work.
:=)) ), and it basically requires you to subclass my main class, one subclass for each table. Here, subclassing for normal usage is surely OK. But what about subclassing and replacing some of my methods? Would this form a derivative work or just be allowed use?
:=) ). A class could be subclassed to add new and specialized functionallity, like spesializing a database connect method to the weird set-up at work or just adding a closely related method which usage fits best within a subclass. To override a existing method to FIX IT or IMPROVE IT in some way, should be a violation of the license, as such changes should be commited back to the open source community.
I've developed (on my spare time) a python library for generating HTML text. I have released the library as LGPL on Sourceforge (the library is called forgetHTML, btw).
Now, as I started using the library at work, I found some bugs and small additions (more tags). Clearly submittable.
I used it inside the company product. Clearly company's property.
I then generated a special table class with support for sorting by column. As this is a general purpose class, with no interest at all for my employer (the project is for managing and monitoring network resources) this is submittable.
I then use this table class in a view to present services and sort them according to response times. No change of the LGPL-code, just usage. Clearly company property.
Now what I tend to wonder is the technical terms used in licenses like GPL and LGPL. They are clearly directed for code compiled from C and it's like, and linked together.
Now, the problem turns up with those libraries that are not just some compiled binary module to link with. What about python modules? Classes can be subclassed with proprietary code. Will that be legal? Will manipulating parts of classes from code outside (like changing the socket-module so a socket-call will go through your spesialized timeout-socket) be ok?
If subclassing is not OK, what about code that is meant to be subclassed? If it is OK, what about code that is not meant to be subclassed? Should authors of such software append to the license their view of subclassing?
I've also created a database abstracter library (named forgetSQL - as my html library is named forgetHTML
The issue here is if the author of the newly formed method is 'inspired' by looking at the original source or just looks at the API and 'guesses' what the method must do in addition to his addition.
IMHO users of my libraries should be able to use the normally, just as users of programs should be able to use them freely as the program. (Except for FrontPage, which explicitly tells in the license that pages created should not talk negative about Microsoft
My view tends to go with something that is disputable in court, what is really an improvement and what is just localization? Different people would feel different on these cases. Although, if you read the top of my post, honest programmers should be able to make a pretty good guess by them self.
What are your views on this? How do my license intension fit with my choice of LGPL?bAnd - which license other than LGPL could be best for my code according to my view (all patches are mine or my friends, it's easy to relicense any later versions)
How do Java-people feel about this? I'm technically capable of subclassing java.util.ArrayList and create a new version with the original behavour, but with say a improved indexing method. I might or I might not have looked at the source code (downloadable from Sun). I'm not looking in answers regarding Suns source license (I can read it my self), I'm looking for the general view from the Java developers, as Java products tends to come with classes and APIs freely available and usable, both with open souce and closed source versions.
Stain, vel! - http://stain.portveien.to/ Stian Søiland - stain@nvg.org - Trondheim, Norway