Open Source/Proprietary - An Issue of Two Codebases? 160
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."
Once it's in the public domain its there for keeps (Score:1)
Re:Once it's in the public domain its there for ke (Score:3, Funny)
The IP is an interesting issue. Once released into the public domain, the public will own it... that's what the GPL, BSD licence and SCO say. You no longer have exclusive rights over it...
Someone else could do what the hell they like with it because the GPL has never stood up in court, and the BSD licence allows it. Like the IP-stack in BSD... everyone knows it was invente
Re:Once it's in the public domain its there for ke (Score:2)
Re:Once it's in the public domain its there for ke (Score:1)
I can't tell whether you are trying to troll, or be funny. Either way, you can't seriously believe that BSD got it's TCP/IP stack from "Linux Torwaldis" (It's Linus Torvalds). Linux actually took the BSD TCP/IP stack, but later replaced it with their own versio
Re:gimme a break (Score:1)
Mozilla (Score:5, Insightful)
Mozilla is open source, and is what Netscape is/was based on, however Netscape added additional features like AIM.
So that means (Score:2)
In a related note: I've been playing around with Mesa lately, and thinking that once I get the knack of it I might build a 3dGL engine for myself (I've build a small one before on DirectX). Now, does this mean I must reveal where I call the Mesa functions, or just keep the Mesa modules themselves seperate (a non-issue in most case
mysql's approach... (Score:4, Informative)
Re:mysql's approach... (Score:4, Interesting)
Re:mysql's approach... (Score:1)
It is easy to see that individuals own cars and the state owns the road.
Re:mysql's approach... (Score:4, Interesting)
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 [apache.org]), 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?
Re:mysql's approach... (Score:2)
Re:mysql's approach... (Score:1)
It doesn't solve the problem because the poster has two stated goals:
License (under and Open Source License) the Framework which he/she developed. This is a separate, stand-alone, piece of software.
Provide development for a company which uses his Framework, while at the same time performing additional development on the Framework.
The problem is that part of his assigned duties to the company will be to provide further development on the Framework. So how do you decide that an enhancement, which could be
Re:mysql's approach... (Score:2)
Best Option (Score:5, Funny)
Re:Best Option (Score:2, Funny)
Hired or not hired... (Score:4, Insightful)
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.
Re:Hired or not hired... (Score:2)
Re:Hired or not hired... (Score:1)
Re:Hired or not hired... (Score:5, Informative)
Not if the code was written by himself. Derived code only needs to be GPL if the code was acquired by GPL in the first place. Look, for instance, on how Trolltech licences Qt: you can get it by GPL, in which case any further development has to be GPL. On the other hand, you can also buy it from Trolltech under a commercial licence, in which case you aren't bound by the GPL.
Re:Hired or not hired... (Score:5, Informative)
Now, if the developer is hired as an employee, the situation may be different; it still depends on the contents of the contract.
Slight nitpick - anything you develop on company time belongs to them. Also, possibly anything related to the company's business. Your own projects, on your own time, still belong to you. This is where the currently existing code fits in this article; new code depends on the contract.Is that guaranteed? (Score:2)
Re:Is that guaranteed? (Score:2)
Re:Is that guaranteed? (Score:1)
Watched a documentery on Tim Burton where he talked about it being a motivation for him quitting Disney. Didn't know he was former Disney employee did you...
Example (From a Disney executive contract) To the extent permitted by law, all rights worldwide with respect to any and all intellectual or other property of any nature produced,
Re:Hired or not hired... (Score:2)
But I digress. It is the same situation for a software engineer.
As for the original question, the determining factor will end up being what product the co
Dual license (Score:3, Informative)
As long as you don't have an exclusive agreement with them it isn't really an issue. License one to the customer however they want, license the other however you want to others.
Re:Dual license (Score:2)
Re:Dual license (Score:2)
The worst case is that the GPL version will be better then the closed version. The only losers are those who insist on using the closed version. Or the origional author if they can't offer competive service outside their closed product.
Is it a modular architecture? (Score:4, Informative)
Seems to me that if it's a modular/plugin architecture then the framework and some modules can be OSS whilst other modules are proprietary. As i understand it, this is how the netbeans [netbeans.org] IDE works. (let's try not to get bogged down flaming SUN's Public License - i'm sure this kind of thing could work under an Apache License as well)
Dual-Licensing (Score:5, Informative)
Never forget the power of dual-licensing. If the body of developers is small and you can get everyone to agree, you can always have the same code licensed under two difference licenses (similar to what the Qt people at TrollTech do).
However, if you ever accept patches from the general body of developers, you will have to make sure that author of the patch agrees to both licenses or redo the patch yourself.
Re:Dual-Licensing (Score:2, Interesting)
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 p
Re:Dual-Licensing (Score:2)
Before you do this consult a lawyer who is up on this kind of stuff.
Re:Dual-Licensing (Score:2)
Good point. Then company X can sell a binary to a customer, but they must give the customer the source code. Then the customer has the source code and binary (all GPL) for company X's version, and can at their sole descretion "give it to the world", without limitation redistributing it to anyone, anywhere, for profit or gratis as they see fit.
Strange that no one has mentioned... (Score:5, Insightful)
Re:Strange that no one has mentioned... (Score:2)
Re:Strange that no one has mentioned... (Score:2, Insightful)
Re:Strange that no one has mentioned... (Score:2, Funny)
wait im just kidding, dont hit me with the karma stick
Ask Linus (Score:1, Offtopic)
Dual licensing (Score:5, Informative)
You must be careful with the license you offer to your clients, can they change your framework's code? can they make derivative products? Depending on the ammount of freedom you want to give them you may need to create your own license for your clients.
Eclipse solved the same problem... (Score:5, Informative)
Open source != Public Domain (Score:5, Informative)
Repeat after me: placing IP into the public domain precludes any sort of licensing agreement.
Public domain means you have no claim of ownership.
You probably DON'T want to make it public domain (Score:4, Informative)
IANAL (Score:5, Insightful)
Re:IANAL (Score:3, Informative)
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.
Re:IANAL (Score:2, Insightful)
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 m
Re:IANAL (Score:2)
Not to mention that they're inclined to use them often as well...
Re:IANAL (Score:1)
Re:IANAL (Score:4, Insightful)
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:
*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.
Be careful with 'public domain'. (Score:4, Informative)
"Public Domain" has SOME restrictions (Score:2)
One simple example is artist recognition -- if Richard Stallman publishes and article and places in the Public Domain, he hasn't given me the right to strike his name from "by Richard Stallman" and insert my own name. He doesn't have the right to do give away that right, as it's inalienable.
"Inalienable rights" is a stran
Re:"Public Domain" has SOME restrictions (Score:2)
> depending on where you are, there's some rights
> that are inalienable, and cannot be transferred to
> the public domain even if you want to!
Which is another way of saying that you do not have the right to place your work in the public domain. Interesting how often laws forbidding people to do something are labeled "rights".
> "Inalienable rights" is a strange concept to
> Americans in particular...
ROTFLMAO. You really ought to learn s
Re:"Public Domain" has SOME restrictions (Score:2)
One person's right is another person's limitation.
This is a fact (and necessiry) of law. Live with it.
Moral right (droit morale), not copyright (Score:2)
The rights that the parent poster is talking about are what are called the "moral rights" of the author. Unlike copyright, they are nontransferrable and last in perpetuity. Many countries have strong laws protecting the moral rights of the author (France, I believe) while others have fairly lax laws (the US, for instance, and Canada).
Moral rights are often associated with (and in some cases protected by) copyright law, but in truth they are a concept orthogonal to copyright.
Moral righ
Close it up (Score:4, Insightful)
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 (Score:2)
If the poster can make a satisfactory arrangement with the client WRT licensing, I think he already has this covered.
Remember, it is possible to make money with open-source software (or even free-as-in-beer software). Accept payment for implementation of specific features. You can continue to do the work you want, and others are free to add their own features (in o
Re:Close it up (Score:1)
Re:Close it up (Score:2)
Re:Close it up (Score:2)
Remember, it is possible to make money with open-source software (or even free-as-in-beer software).
It's possible to make money begging for spare change in the street, but that doesn't mean I'd want to.
-a
Re:Close it up (Score:3, Insightful)
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 pro
Re:Close it up (Score:2)
If you are writting this for a specific customer then you need to figure out what they want. And as a number of people here have said, you need to talk to a lawye
Public Domain (Score:3, Informative)
If it is in the PD, you should still be able to copyright new code. However, you may be limited in the licenses you use. For example, public domain is not GPL-compatible (it doesn't have the GPL's added restrictions in the name of freedom).
As others have mentioned, look into dual-licensing. Have a lawyer write up a contract and license for you - it may save you headaches later.
Copyright and Open Source license (Score:5, Informative)
The key thing to clear up is who owns the copyright on the code. If you own the copyright then you can choose how and when you release the code (open or closed). But it's vital that you keep control of the copyright since it gives you the maximum flexibility. (This is achieved in my project, POPFile, through the POPFile License Agreement).
Specifically,
1. You should make clear to the employer that you hold the copyright and that the code is valuable property which you are willing to license to them in exchange for X.
X could be a job with them, or it could be $$$ or royalties. Exactly what depends on what you want out of the agreement.
2. The license to the company needs to be non-exclusive (giving you the freedom to license to someone else), or exclusive with an exception for an open source version of the code.
3. Once the agreement is in place release the code under the GPL. This will help protect the company's investment because anyone else using the code will be forced to release their code lowering the likelihood that someone else will try to make money off it.
4. When you get contributions from the community who are using the GPL code make sure that you get signed agreements from the contributors transferring copyright to you so that your source base is not contaminated and you maintain control of the copyright. (I've included the text of the agreement we use for POPFile below for reference).
5. Make clear in your contract with the company who owns copyright on the changes that they make or that you make while employed by them. The best solution is that you keep the copyright for yourself.
6. You should expect that the open source version of the code will make the company lower what they are willing to pay (they are after all sharing the code with someone else). You need to argue back that in fact you will be leveraging the open source community to improve the product free of charge to them.
The FSF has a page covering copyright issues here: http://www.fsf.org/licenses/gpl-faq.html
and here: http://www.fsf.org/licenses/why-assign.html
John.
Here's what we use for POPFile...
[snip]
POPFILE LICENSE AGREEMENT
CONTRIBUTION DESCRIPTION:
John Graham-Cumming ("jgc") acknowledges, with many thanks, the receipt by jgc
from Licensee of the above-described Contribution ("Contribution") to the
POPFile software and its related documentation.
Licensee confirms to jgc that, to the best of Licensee's knowledge and belief,
the Contribution is free of any claims of parties other than Licensee under
copyright, patent or other rights or interests ("claims"). To the extent that
Licensee has any such claims, Licensee hereby grants to jgc a nonexclusive,
irrevocable, royalty-free, worldwide license to reproduce, distribute, perform
and/or display publicly, prepare derivative versions, and otherwise use the
Contribution as part of the POPFile software and its related documentation, or
any derivative versions thereof, at no cost to jgc or its licensed users and
without any accounting obligation to Licensee of any kind, and to authorize
others to do so.
Licensee hereby acknowledges that jgc may, at his sole discretion, decide
whether or not to incorporate the Contribution in the POPFile software and its
related documentation.
EXCEPT AS OTHERWISE PROVIDED HEREIN, LICENSEE MAKES NO REPRESENTATIONS OR
WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE ABOVE-DESCRIBED
CONTRIBUTION. BY WAY OF EXAMPLE, BUT NOT LIMITATION, LICENSEE MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY
PARTICULAR PURPOSE. IN NO EVENT SHALL LICENSEE BE LIABLE TO USERS OF THE
CONTRIBUTION FOR ANY INCIDENTAL, SPECIAL OR CO
One on top of the other? (Score:1)
where's the dilema? (Score:1)
What u have developed thus far, you should open-source
What u will add to the framework that will be useful to other potential users of it, you should also open-source (this is why they r funding yer open- source development)
What u develop specifically for the clients' implementation of yer framework, Should be their's, propiatary, and not included in the framework.
I dont see a terribly large grey area in this!
just my
Sure it all works out, but what about subclassing? (Score:2, Interesting)
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 clas
Use strict, legible, obvious code boundaries (Score:3, Interesting)
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.
where the boundary lies... (Score:2, Insightful)
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 i
Re:where the boundary lies... (Score:2, Insightful)
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 b
Here's a few links that may help you. (Score:3, Informative)
Google Directory [google.com] [Software >> Licensing]
I personally have no experiance, or legal expertise. However, I'd say, to figure out your borders of open/closed source... If your code will run without the business software you're writing, then it's officially open source framework. It's it's "extra" and related to that business software, then that code is closed source. Just an idea. Good luck!
LGPL is an option. (Score:1)
It is relativelly easy decide (with you're benefactor) what modules should be LGPL and which not. If a module could benefit from the OpenSource movement LGPL it.
The rest you can keep nice and hidden.
You're problem of course is finding the balance. I would personally try and get the benefactor to agree to release eve
Interface boundries? (Score:1)
So the OSS framework remains OSS and has well defined interfaces that proprietary plug-ins can implement.
Language specific features would help too. For example in Java jar files (code archives) can clearly separate "my code" from "your code" and the Factory classes can instantiate plugins dynamically without being aware of their proprietary nature.
Hate to Sound Like a Broken Record, BUT ... (Score:5, Informative)
IP legal problems, like any legal problem, are highly fact-dependent. Yes, it may cost you some money to get a legal opinion. I guarantee it will cost you MUCH more if you don't and have a disagreement later. According to the latest AIPLA (American Intellectual Property Law Association) survey (2001), an IP dispute with $1-3 Million at stake will cost approximately $500,000 to litigate. On the other hand, you can probably get a decent legal opinion for about $10,000 depending on the complexity of the issues.
Recap: $10K for an opinion that minimizes the risk later vs. $500,000 to litigate plus all the headaches / publicity / business interruptions of litigation. You decide.
Re:Hate to Sound Like a Broken Record, BUT ... (Score:3, Interesting)
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 lawy
Re:Hate to Sound Like a Broken Record, BUT ... (Score:2)
No, yours is a STUPID COMMENT. How do you know this is a copyright issue alone? ANYTIME you deal with software IP issues, you have to worry about copyright, trade secrets, and patents, along with confidentiality and other contractual problems. NOWHERE in the original post did it say "copyright" - it said "IP issues." IP issues are much broader than copyright.
And for your continuing education, the AIPLA [aipla.org] does break it down further. Become a member [aipla.org] and they will gladly send yo
Give it to SCO (Score:1)
Let SCO fight your legal battles. They should have plenty of experience by then.
Sun's JCA (Score:1)
This allows Sun to defend against licensing violations as they come up (since there is no ambiguity as to who owns what). They also sell a commercial fork with some proprietary extr
Code seperation (Score:1, Interesting)
Missing The Point (Score:4, Informative)
The question is how to separate the two. The GPL is almost certainly inappropriate, as its purpose in life is to infect the "linked" code and force it to be released under GPL as well.
The LGPL exists precisely for this reason. It does not require the linked code to be released under GPL (or LGPL). If you can separate the framework and the app, then this may be the way to go.
(If you can't separate the framework and the app, then it's not really a framework! Maybe a bit of redesign would be needed to keep the separation between modules clean.)
Dual licensing doesn't really solve the problem. Or, rather, it only solves it for one single customer and one single release. You could craft a license for this user that allows them to keep their code, while also releasing the framework under, say, GPL. But then when the customer wants an update, they can't just go and grab the GPL version of 1.1 and use it without GPL'ing their code. And their original license wouldn't apply to any updates. Rather than try to track every customer and every release so that you can keep reissuing special licenses, it would seem to make more sense to adopt a license without the "viral" quality of GPL in the first place.
If you're willing to allow one customer to use the framework in a proprietary product, then it would seem that you don't have a major ideological free-software axe to grind, and thus don't need the GPL stick to go with your software carrot. So it seems you might as well be willing to allow anyone to use that framework in their code. In which case, any of the simpler and "really free" licenses such as BSD would do.
If you do want just this one company to have special access to the framework -- perhaps as some sort of competitive advantage, since they employ you, or the reverse, in an attempt to have a reason for them not to fire you -- then dual licensing with the public license being GPL (to try to shut down other commercial competition) might be the way to go.
Diebold: Fewer Trade Secrets (Score:2)
Get it straight! (Score:1, Flamebait)
<it><b><blink>NOT </blink></b></it>
in the public domain!!1!!!oneone1
Seperate projects (Score:3, Insightful)
Remember, you are holding all the legal cards regarding the code at this point. They are just holding some money.
negotiation and specification (Score:5, Interesting)
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.
BSD License (Score:2)
HTH
Rgds
Rus
open source the way I see its future. (Score:2)
Look at moddable games (Score:1)
Think as a business guy, not a techie (Score:3, Insightful)
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
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.
Referral (Score:1)
>>Fennemore Craig counsels clients on: Internet and e-commerce issues; protection and licensing of patents, copyrights, trademarks, and trade secrets; and branding strategies (collectively referred to as intellectual property). The intellectual property practice group includes attorneys with technical degrees and attorneys with business degrees. All have extensive experience with Internet and high technology issues. Clients include a ran
I think it depends on how you mean... (Score:2)
For instance, I've written a web content-management and application development API, and released (sorta) the API under the Library GPL agreement.
If I understand what I've done correctly -- and I think I do - - anyone can download my API, link to it, and build whatever the hell they want to on top of it, and distribute that application as they see fit, with our without their application's source code, for profit or not. They
Make Up Your Mind (Score:2)
> licensing model and placed the code in the public
> domain
Are you going to license it or place it in the public domain? You can't do both.
Take a look at Helix Community (Score:3, Interesting)
For Helix Community [helixcommunity.org], we have a dual-licensing model which gives the community an OSI certified license (RPSL) [opensource.org], and a more commercially focused license (RCSL) [helixcommunity.org]. 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 [helixcommunity.org]
How we handled this exact situation. (Score:5, Interesting)
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 [onjava.com]) 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 [apache.org] and Hibernate [sourceforge.net] and Karajan [jini.org] (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.
Re:How we handled this exact situation. (Score:2)
Artifex (Score:2)
I believe Apache also sells commercial licenses.
Basically, if you do the work, you own the copyright. As another poster said, make sure you don't lose that control.
Check out the Open Source Initiative (Score:1)
Dual liscense (Score:2, Interesting)
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 li
The question not asked (Score:2)
Check out Lessing's work on creativecommons (Score:1)
My simplifed take on copywrites.... (Score:2)
Public Domain - no copywrite, use however you like
BSD - use however you like, just say thankyou, please...
-Mostly Free-------
LGPL - use however you like but give back/make available changes made to this library (keep clear line between end of library and start of app)
-Limits Use--------
GPL - use but product must also be GPL
Open Source(tm) - look but don't touch, or touch but don't sell/distribute, or look but don't write anything remotely like this or we'll sue. (see: Proprietory, NDA
Possible solution? (Score:2)
-
Re:FREE THE CODE (Score:1)