Slashdot Mirror
How to "Open Source" Custom, Contract Software?
customWorks asks: "I've been approached to write a piece of custom software for a small business owner with the promise of autonomy in its design and implementation. I do not intend to stick around for incremental development after I've delivered it, and so I feel strongly that open sourcing the software would be prudent for the both myself and prospective client. That said, I still expect to be paid for the developing the software. The issue of course is over convincing the client of the benefit of giving away the source to something they've just paid to have developed. I'd like to know if any of you who've done similar contract work have had experience (success?) in presenting an argument for open sourcing the end product? What were the major concerns/misperceptions that you had to overcome in making the case for open source?"
I am unemployed but doing contracting and I feel lucky if I have enough work to pay my mortgage, so consider yourself lucky that you have the luxury of wondering about whether you can convince them to go open-source...
graspee
If the guy wants his software given away (he paaid for it, it is his), I am sure he will do it. Just give him the code when you are done and that is all you are responsible for.
Michael Loves Me!
I spent a year in Iraq looking for WMD and all I found was this lousy sig.
In any contract work I have ever done, I have made sure that I own the copyright, and give the client a perpetual license for the resulting programs.
If the customer insists on owning the IP, then there is a great reason to raise your rates.
And of course the whole wanting the end result to be open-source but you getting paid your fee is so totally a "have your cake and eat it" situation, that words escape me...
graspee
The client is paying you for your time in developing an application. For that money, they should get at least:
1) The binaries
2) documentation
3) support
If you can't give them support, the ethical thing
to do would be to let them know, and give them the
source code so that they can have someone else
maintain it. But THEY should choose whether to
open source the code or not. They paid for it. It's their decision, not yours.
You'd do better to leave them well commented code with a few backups. Leaving it up to the OSS community and expecting them to produce something useful to your client (i.e. you're getting paid to serve them, not the OSS community) is a gamble at best. Not a dig on them, they're just not looking out for your client.
So lots of comments and documentation are what you would produce if you truly have your client's best interests at heart.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Dude, I think I can see my house from here.
In this case, you could make open sourcing the program part of the development contract. Just squeeze it in there inconspicuously. Much like so many EULA's we've seen.
Or say that the custom app will be based on your own technologies so that you can open source say the main engine, and not give out proprietary stuff, such as database data.
If I were a customer wanting software written then :
1. I think if the software is an implementation of a patent, then it could open source it (like a reference implementation).
2. If the software aides some other software that makes the money, then you could open source the software.
Otherwise, I'd be very opposed to the idea for the fact that it's a special purpose software that wouldn't have much use in the open-source community and would only serve to inform my competitiors.
that great of a thing unless other people find the project interesting. It will loose any resale value, so if its something they'd like to sell, they could only make money as support.
OTOH, ih its something people will enjoy enhancing, then they get value from free enhancments.
Explain to the the philosophical reason for opening source. Or just GPL it.
The Kruger Dunning explains most post on
I'd say just give your customer the source code and let them worry about it. They can do with it what they want. Open source doesn't have much to do with this because no one is distributing the application to a larger audience anyway.
You must not have contracted much. Or to real companies.
If the contract with the client states that all the IP you create belongs to the customer for whatever he wanted to do with it, then there's little point forcing the customer to do something specific with it.
Either way, the customer will face the problem of later support and evolution. If he cannot get hands on you, he either has to hire someone for hard bucks, or he donates the stuff to the public and crosses his fingers that someone will take care of it. Which does not necessarily mean the necessary work is done then - this depends on how 'hot' that piece of software actually is. You might have problems making some 08-15 applet Open Source in the hope of getting volunteers.
--Ben
Use The Source, Luke!
i've never coded a piece of software in my life, let alone opensourced one, but i can tell you right now the single major objection or concern you will face.
The dialouge will go something like this:
Coder: Let's open source this after you pay me to write it.
Buyer: Wait. So once we pay you to produce this for us, you want us to let you open source it, in effect giving it away for free?
Coder: Yeah. It's neat. Information wants to be free.
Buyer: But you want to be paid.
Coder: Yeah, I gots ta get paid.
Buyer: They don't require computer science majors to take economics, do they?
Seriously here. A buyer who is paying to get a custom piece of software made for them will be very very reluctant to let the rest of the world have that software for free once they have it. Especially if they have competitors. Especially if that software is mission critical at all.
In summary, best of luck. But perhaps opensource idealism should get a bit more used to taking a back seat to harsh economic reality.
*ends post, dons flame proof suit*
--Use this space for notes--
I've done only very limited contract work and at that, it wasn't Open Source. I think it really depends on the client, as the people I was working with hired me specifically because they were a Windows firm and didn't want to bother themselves with some Unix stuff that came their way from an existing client. For them, of course, it would have been impossible. But I can speak in regard to how some companies would react in general.
:)
If you're working with a firm that's more familiar with the a community or is part of a larger scientific community, it's another matter. Some firms view releasing open source software as almost a promotional effort and you might egg them to develop an "open source policy" to satify their concerns.
Board of director types have bazaar stigmas and FUD like "won't we have to support it," "won't it give away our business model," and so on. You can address those questions by suggested an OSS policy. The policy basically comes down to how and when they'll open source software. For example, they won't open source software that would be directly useful to their compeditors. When they do, putting the employee email addresses won't be allowed, as it will burden them with emails. Open Source projects shall be included on another website, etc etc etc.
But they will be more warm to a policy than simply deciding to open source things adhoc -- so if you give them a policy to address their concerns, you might have better luck.
And of course if your Philip Greenspun good, you can TELL them it'll be Open Source.
2 cents.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
and make sure your source doesn't either in case it should reveal "interesting" information about their systems, environment, transactions, etc.
If I were paying someone to write code for my business I would want it as customized to my needs as possible while making it modular for further enhancement. What I would not want is for the entire open source community to know what network OS, database version, hardware, etc. I am using since that would reveal too much useful information to potential intruders.
Tell them that by allow you to open-source it, they will no longer be dependent on you for maintenance; they can hire anybody to do any revisions. Remind them that without this move, the IP will still be yours and they will have to negotiate with you for improvements and further development, and that if they want the IP themselves, that will mean a cost increase for them.
As a second, less important, benefit you can mention that there is a possibility that others will pick it up for use in their projects, and those improvements will benefit them without it costing them anything at all.
When they ask why they should pay you to write it in the first place if you're just going to turn around and open it, point out that without a developer under contract to write it, it won't be written at all in the first place. Emphasize that the open sourcing is about the maintenance of the software after it's been written, not about a different model for the development.
/Janne
Trust the Computer. The Computer is your friend.
Depending on what you're attempting to develop, you may be able to develop the code faster using code fragments from other developers. Of course, if those bits of code were GPL'd, you'd be obligated to make your code available.
Depending on the scale of the project, and the odds that the code segments you need already exist, you have to determine how much time savings you'd have by researching previous GPL'd projects over writing it on your own.
Although many companies wish to retain the rights to software you write, there are very few people who don't re-use bits from project to project. [Hell, it'd be downright foolish not to use already written and tested code]. As such, on any programing project I take, although there might be an NDA, I still retain the right to re-use the code in any further projects. Otherwise, I run into the risk that my common code library will be locked down once it's in use in this project, and I'd rather not take the project.
[even if they paid me more than my going rate, I'd be worried about using knowledge that I got from the project towards another project, and getting sued.]
Build it, and they will come^Hplain.
I assume you told him the part about not supporting the software you write, correct? Open sourcing software is not the magic pixie dust you apply to a half assed job. Look through Sourceforge at all the abandoned projects -- the world is not interested in finshing the job.
I am not a number! I am a man! And don't you
The Penguin, comprising of black and white, shows us that the two can get along!
CustomWorks, I would offer a price difference so
that client pays more if they dont allow you to
offer the same to other similar small businesses.
Next, you'd have to show me that releasing the code would not open me to any liability nor to any security breach. Saying that "more eyes see more bugs" is not an answer either, because I'd still have to pay someone to integrate fixes or, at least, re-install on my system each time an eye found a bug.
Finally, you'd have to show me that I couldn't profitably sell this as a product - probably not a big deal, as software doesn't appear to be your customer's area of expertise, but small businesses live and die on cash flow and, if I can keep it proprietary, not do anything to support it, and still charge money for it (i.e., the Microsoft strategy :-), I'd still do it...
That is all.
just give it to them under a BSD type thing, then they can modify and conceal all they want.
And you have a different branch, do whatever u want with it.
Works for Gates.
Find a few open source projects, preferably GPL'd, that you can build off of for your clients product. Then use the angle that by using these open source projects, which require you to open source your project, you will significantly reduce development time.
If you can convince the business owner that there is a benefit in open-souring the application, then they will go for it. Do you mean true open source (everyone gets the code), or shared IPR - in which the business owner gets the code, so at least they can hire someone in the future to update it?
:-)
I'd guess the arguments for true open source would be:
1) That the software doesn't form a part of their competitive advantage. If their key selling point is that their service is better - and because of this software, they CAN make their service better, then they'd be mad to give it away. If it is only used to satisfy some pain in the ass regulation, then they might consider it.
2) The advantage of opensourcing (if you get through (1)) is that other people might contribute to bugfixing and maintenance - this will reduce their costs in the longer term. However, running an open source project demands time - which will increase costs. If there is likely to be some form of community spirit, then there is more chance of this happening - i.e. there are lots of businesses with the same problem.
3) Open source is better than closed source. They won't care about this, as they will have the source already if they've written your contract correctly.
Binary with documentation/training
GPL the source...and give them a copy.
badda-bing badda-bang,
all parties involved are happy!
"Just Smile and Nod." --Huck
Don't give them an option. This does pre-suppose that your contract gives you full rights to the software of course. I own all the rights to every database and utility I've ever written, and while none of them have been sufficiently general-purpose enough to actually be worth releasing I have the legal right to do whatever the heck I want with them.
Now I wouldn't go shoving it in their faces. Heck, I wouldn't mention it at all. But if you release it six months or a year after it's finished - A. They might never know, and B. Even if they do pitch a fit there's nothing they can do if you own the rights to it.
This makes no sense. If you have no intention of sticking around after roll-out, why do you care at all? If you cared about the product continuing on to become better you would stay in the development loop.
Open Sourcing a company's "custom" software is fairly pointless as they own it and the only reason they paid to have it developed was that there wasn't anything else that did what they want. This means one of two things. Number on that no one else will find it that useful, or number two that they've just paid for their competitors to have a great piece of software for free.
I've been writing custom softweare for years and I have yet to run into a company that didn't want to own the source code -- and rightfully so! I don't expect someone to pay me a large sum of money to develop a *custom* piece of software and they not own it!!!
Everyone in the software industry owes their having a career to commercial software so there is nothing in the world wrong with it!!!
Whoa.. well, all I can say is that I hope that gets appropriately modded down and tagged as flamebait.
People who spend all their time trying to find things in places they don't exist are doing nothing but creating problems for others, and they probably think they're doing it in the name of enlightening those around them.
Firstly, I do not believe you would be asking this question, if you knew yourself why you want to opensource it.If you know it, really know - and the reason really is that opensource based development benefits the customer - then I do not believe you have any problem in convincing the customer.
:)
To answer the first question, think:
- If the software that you are developing is "generic" and publishing it yields no losses in the competitive edge of your client. Good.
- If the software is "just" for a support process of your client's organisation. Good.
- If you have clear plans on how the software you will develop could be enhanced so that it benefits the customer. Good
- If you quess the total price will be cheaper. He gives out something, that grows into something bigger. Good.
- If your customer has too much money and is an opensource evangelist
Seriously, it should not be that hard, if you can show clear benefits.
...and besides, if you use any GPL'd code then they are forced to provide their modifications to anyone that asks.
If you used GPL code and they don't want that, then you cheated them.
Start from scratch and do some honest work; allowing them to keep the software they bought in a safe place where no eyes may see, unless you then could convince them to GPL the code they bought from you.
Don't be a cheat, honesty wins out, they could argue that you didn't make them anything and you don't get paid for someone else's GPL'd code. Sux0r to use GPL. Can't prove an exchange of goods and services when it is already provided
If it's just an in-house application, there's not much need, as I see it, for making it open-source, (except of course to donate your code to other worthy causes). Of course, it would be nice, but open-source or not, I expect they'd want the source code for future work to be done on it.
If it's a freely-distributable client to coincide with services that the company provides, it seems like it'd be an easy sell -- a lot of the IT community will be much more excited to use their services if they can customize the client.
In short, having it be "open-source" would be most helpful (and easiest to convert them to) if it's software that they're going to be distributing free of charge. If it's just for internal use in the company, the line between it being "open-source" and just their having a copy of the source code gets fuzzy, but they would certainly need one or the other. If it's going to be a commercial product, I don't know how you'll convince them. (Better write REAL good documentation. :)
Any sufficiently simple magic can be passed off as mere advanced technology.
Present the potential customer a list they can choose from like this:
If they take the software with a non-exclusive license, you still own the copyright and are free to release it under GPL or whatever other terms you like.
No offense, but this is one of the stupiest ideas I have ever heard. When you develop code for a client, the client then owns the code. Simple. If you cannot support your own code, at least they have it so they can give it to somebody else to support and maintain.
Remember though, that your name is going to be associated with that code for all future developers to see. You better take some time and carefully document everything you do. Your code is a personal reflection of you and your work ethic, so you don't want people to get the wrong idea.
Im currently in a similar situation, I havent signed any contract with the person but it is an informal agreement that I will work for him developing the engineering application he requires.
The trouble for me is that allot of the stuff I am intergrating with is code that could potentially benefit competitors. Appart from that the front end for the code, which i am primarily employed to write is in vb and as vb goes it is getting pretty hectic.
I think open sourcing the front end would be pointless as the application is obscure in the needs it requires. But other than that, I open source in my head, programming is always a learning activity and if I learn how to do a neat trick or two it will probably be used in a differant form in the code I write for myself which is usually released completelty open.
Most business that contract, without being explained what open source is and having the benfits of os licensing explained to them would just see it as a free way for others to get hold of the code they have paid for.
And the person who is buying the binaries from them would probably not bother and just compile the source that has been released, hire someone like me to give support when they run into trouble and save them self a whole lot of money
Maybe this is one place where open source can not be used? After all, it is a business/money making environment...
(yeh yeh, I know about the arguments towards the fact that you can make money from os, not on a short basis I beleive though)
I've worked for companies that have paid HP and IBM hundreds of thousands of dollars to have features placed in products. Never, ever, was there even a question who owned the source. HP and IBM.
But I've been in this guys position. Small companies are control freaks. They aren't willing to pay the money that a larger client is, they don't understand the debug cycle, they are usually more of a hassle to deal with, and to make it that much more irriting they want to own the IP.
Stick it to them straight. You'll provide them the solution, and the source, you own the IP and will do whatever you want. Don't be rude, but be prepared to walk.
er, I meant to say I have no right to the source for that copy of windows... :o
I have to say one thing about your notion - If I were the company thinking about hiring you to write the software, you wouldn't be far enough along to be asking this question.
I'd have fired you long ago because you won't continue to support your work. (Of course, writing an app so good it never NEEDS suport is another matter altogether.) It's completely ridiculous to assume that publishing the source under whatever open license will instantly give you an army of developers willing to continue to support and continue developing on the application for free.
Normally what you'd do is write the opensource app, and then a compnay would hire you to extend and support your own application inside of their project - in that case, then you could start talking with the compnay about whether the changes would be opensourced or not. In this case, you're turning the whole thing on its head.
Still, you may be right in that opensourcing the project would be a good idea for the company - but that is a decision that should be made INDEPENDENT of the development itself. The company should approach the decision with the assumption that the package is already developed, or even better AFTER the package IS developed. Most importantly, do not give this company any kind of false hope about what opensourcing the software will do. If you are a developer who actually runs any opensource projects, I don't really know why you would even think of recommending this so soon.
Why do you feel compelled to persuade the customer to open source the software you intend to deliver?
... Sorry, I take option 3 -- I have enough hassles in my life.
1) Moral objection -- then do or do not (sorry Yoda). You may choose to express you moral view or not to client depending on whether proseltyzing is worth the effort/benefit ratio. If you fail to persuade, do you turn down the job?, if not, see point 3
2) Don't want to support -- then don't support, let customer know this, and why (at least if they ask). If you feel OSS makes a different in support, see point 3.
3) Anticipated benefit to customer -- explain your view of benefit, let customer choose.
4) Want to use exising OSS, see #3
If all you want is additional bullet points for #3, I'm sure you'll get plenty of opinions on slashdot. But, I would recommend sticking to things I believe in and understand (preferably have experience with) when making the case for OSS.
Hmm, point 3 seems to be pretty important. Give the customer a rational (or emotional) basis for making a decision. And let them make a decision. It's their money, their project, not yours. Of course, if its a moral issue with you, don't violate your morals. Don't come crying to anyone if you have to sacrifce though, high morality requires that you be consistent and be willing to accept the sacrifice it may involve.
My life is complicated enough without having to convert others. Matters of religion, politics, etc. are very similar to the arguments we coders get into -- We believe strongly in what we believe, for waht we believe to be good reasons, others believe just as strongly differently. You may convince some, other's you just make mad.
I may believe it's worth arguing religion (save their soul, or save the waste of their time/beliefe in myths, not saying which i follow). Politics -- you get morality and economics. But coding
What's the problem? You sign over the rights to use, or modify the code. You don't sign over the rights to distrubute it.
*OR* Sign it over to him under the GPL and restrict yourself from distributing it.
Any body he hires to modify it is restrained by the contract they sign with him as it is an internal project (to his company), and -if- he ever decides to release it he can do so.
And no future developers can take any rights away from him on the code, or modifications to the code. (ie: they couldn't hand him binaries without sourcecode).
If you want to get paid to develop something you have to expect that you won't have full rights to it when your done. If you client says 'sure, no problem', great. Otherwise you won't have a choice.
Remember, open source does not necessarily mean free as in beer or free as in speech. A lot of business software licenses allow purchasers of the software access to the source code, but it strictly forbids redistribution of the code. Such a license is open source yet not free as in beer and certainly not free as in speech.
Your best bet is to give the client the source code. You need to choose whether or not you want to retain rights to the source code, or give all rights to the client. Most contract programming jobs I've ever heard of require that the client not only gets the binaries and documentation (and sometimes training) but also the source code and complete rights to the source. That way, you don't depend on you for incrimental improvements. They can hire their own developers to do that if they have the source.
Honestly, if this is a custom job that is likely only of interest to the client (and perhaps the client's business competition), you are ripping them off by not giving them the source. But again, it's your job to choose whether or not you want to retain the copyright to the code for yourself, or give all rights to the client.
The contract jobs I'm doing lately, I'm plugging in as much open source as I possibly can, and then essentially charge the client for the "glue" code that puts it all together.
;)
;)
Most business problems have been "solved" in one way or another elsewhere -- extol the virtures of sourcing in something that they will be able to get support for, using the old "if i get hit by a bus" scare tactic
Otherwise, through good architecture, you can compartmentalize the proprietary bits to a few files, thus allowing them to have something of their own at the end of the day.
And again, BE OPEN UP FRONT -- you are probably not in a position to identify on your own what the client may or may not consider proprietary -- lots of businesses have "grey-matter" or "raw experience" when it comes to processes and methods that are not obvious to their competitors.
But basically we get a lot of mileage becase I stand on the shoulders of giants everyday!
and remember, work = force * distance
Old age and treachery almost always overcome youth and skill.
Are they paying for him to deliver a solution, or are they paying him specifically to develop code for them. There is a difference.
If they are paying the hourly cost of development, then it is absurd, even rude, to expect them to let you keep the copyright.
On the other hand, if they are simply paying you a flat fee for a solution, and it is up to you how you attain that solution, then it's another story. You can write the code and license it to them and keep it yourself.
This is wrong. When you pay for Microsoft Office, does it gives you the right to choose what Microsoft does with it ? No.
:
:
Therefore when you code something you can do WHATEVER YOU WANT.
The only restrictions are
- if the customer gives you secret/breveted/etc solutions or ideas or private methods related to his area of business
- or if he spends a lot of time with you and is also author of the program
- if the customer and you signed a contract of exclusivity and closed source before starting the project
But in any other case, you can do the following
- sell it to other customers
- make it GPL
- make it open-source
- etc
Of course, morally, you must simply ask him for a price corresponding to what you do. You cannot ask him to pay you royaly (high price) and make it GPL or sell it to others. But if the price is quite modest and simply pay your time, maybe you can...
It's up to you and your client, and to the relation you have...
The Price of Freedom is Eternal Vigilance.
You almost always give the client an Unlimited Non-Exclusive license to the stuff, but you certainly dont give away what you can sell.
If a client adamantly wants exclusive rights to whatever you produce, then you certainly raise the rates. And if you bring any preexisting code in an the product, which you will always do, you have to be clear that they dont get exclusive rights to that as well.
But, I am not asking MS for custom sofware and this guy isn't selling software that he makes available to the public. I wonder how this guy's customer is going to react when he finds out he is funding software that is going to be given to his competitors for free.
Michael Loves Me!
..that is a diferent situation, you are not writing code specificly for someone. if they pay you for the code its thiers, as if they wrote it, you don't have any say in what happens to it unless you arrange that beforehand. and there is really no benifit to a company opening thier source:
-it could be used for free by competitors
-malicious people will find security holes in it
-there is no reason they cannot just hire someone to change the code later(unless your code is crap and noone can read it)
The Truth: There is no string:)
Score +5 Insightful.
Just like blacks were towards the back of the bus.
Michael Loves Me!
The character of this question bothers me on a number of levels.
...
Firstly I agree with one comment that replied this person must not have contracted very much. I tend to agree. Is this really a query that's going to come up with major players? If you're contracting for a Fortune 500 company, that has its own overworked and underpaid IT staff, are they going to let you open source something they just gave you $80,000 to develop?
Don't think so, probably not at best. Sure, it's POSSIBLE, depending on your relationship with your client, but many of the large clients are going to have you sign NDAs and/or non-competes and you can go to the High Church of Principle all you want about signing agreements, but if someone is paying you a boatload of cash and you've got kids to feed and a mortgage to pay, well
The reason this question is even posed is because, as you stated, you're servicing a small client, one that may not be able to strongarm you into any kind of enforceable agreement. Or if they can, their ability to enforce may be limited, or their awareness level surrounding your line of work may be limited. You may feel you have recourse, or an argument to pose with a little (or smaller) guy than you do with, say, a large, truly powerful client.
So what is the nature of your query then? It sure isn't of the nature of, say, "How do I convince my 50 billion-a-year client to let me release the source code they just paid $100,000 for to a SourceForge slot?" Because they won't be wild about it, and there's so much abstraction in the management that you'll have a helluva time trying to end up talking to anyone with any real definitive control over that decision. Even top-level IT managers have to report to Standards and Practices and Legal in large organizations.
So you're really posing this question for small clients. And the answer really should be simple. You should be pretty up front about it before you start coding. Because if there's a chance you may end up arguing about this later, and your client hasn't clearly understood your intentions or philosophies in this matter, then you haven't been fair. If they do agree up front, then great. You're clear, they're clear and if they balk later then you can produce that paperwork they signed that gives you explicit rights. No arguments, no problems.
There's only a potential issue if it's after-the-fact and they're small enough to argue with.
Offer them a discount if they let you open source the software... or find another business that is willing to share the costs for development. My company shared development costs with another company on an open source project for several years until the lawyers got involved and killed the whole thing.
How long does it take a palestinian whore to make a bomb?
9 months.
What does a black woman get when she has an abortion?
$1000 dollars from crime stoppers.
If that client wants to open source it, fine. But you are being paid by him to write the source code, and therefore you don't own it when you're done - he does. The decision about whether or not it should be open source rests with the owner of the code, i.e. the client. If you don't like that, either accept no payment or tell him to go elsewhere.
Don't convince the client of anything. As an independent contractor, your work isn't work for hire. You hold copyright. So, just don't sign a contract which stipulates that it will be work for hire.
Disclaimer: IANAL, TINLA
Become a FSF associate member before the low #s are used
I think you're confusing providing source to the business owner and open source--they're not the same. If you're planning to wash your hands of the project after initial development, I think you're morally obliged to make source available to the business owner. (Even if the business owner doesn't know enough to ask.) Depending on how the contract is written, the business owner letting the contract could either own or license the source. (You are planning on having a written contract, aren't you?) If there's some compelling reason why the code should be truly open source, and the business owner balks, you might sweeten the deal for him by offering to charge $X/hour for open source, $1.5X/hour otherwise.
1. I am an Open Source advocate.
2. I played college basketball -- thus, contradicting your moronic little point of view about athletics.
3. The names of the commands in UNIX goes back to the early '70s when it was originally written -- commands had to be short b/c computers were slow and keystrokes needed to be brief.
4. You are a sad strange little man. You have my pitty.
I think the real factor for the business, will be deciding if this software can be used by their compeititors. If its a customized piece of code that wouldn't really by helpful to the compettion, they are much more likely to make is OS. However, if they feel that their competition could use this code against them, then they probably would want to keep it closed source.
Just something to think about.
If the client agrees to make the work open source, then their competitors will be able to use it at no cost. How is that in your client's interest after they paid you to develop it?
What makes you think that the open source community has any interest in supporting the custom application that your client is paying you to write?
Your client will already own the code, so they can give it to whomever they want. Why would it be in their interest to obligate themselves to give it to any more people than absolutely necessary?
I've been doing software consulting for 20+ years and, forgive me for being blunt, but you sound like some kid on one of his first consulting jobs. You seem to have this naive view that you can write code, throw it over the wall, and run. You can -- once or twice. Then the word will get around that you don't support your clients and the work will dry up.
If you want to participate in the open source movement, do it on your own time. What you're trying to do is like someone who volunteers with Meals On Wheels and then expects to make the delivery runs while he's on the clock at his job.
I could not immediatly find a link to a story.. but Cygnus was very successful at making money "selling" gcc. Basicly companies paid cygnus to port gcc to their platform.
shrugs
you don't know the difference between contracters and employees. Generally IP to software written by salaried employees is owned by the company, but software written by contracters usually isn't, for a pretty simple reason.
IP to software is useless to a company that isn't planning to resell or profit directly from the software. Companies that hire contracters are usually looking for specific peices of software that will perform a specialized function, so they wouldn't have much use for the software IP, only for the software itself. Perhaps some contracters do hand over the IP rights as well, but most certainly don't.
I'm sorry, but you are trying to say that the guy doesn't know much about "real companies", when it actually seems he would be more justified in drawing that conclusion about you, if indeed your post was not a troll.
Cedric Balthazar Rotherwood
Sun Certified Programmer for the Java Platform +
System Admin. for Solaris
Just because something is Open Source/Free doesn't mean it must be available gratis.
You could tell them that since your potential client would be the only paying customer the nyou have no financial motive to provide the source to anyone else. You could also remind them thatjust because it's free software, doesn't mean they can't hold it hostage until someone else pays for it.
That way you get your money for providing the service and the company can at least try and make up for some expenses by reselling.
But in all honesty, such a model can be achieved without "Open Source". Companies relicense and cobrand software all the time without it being "open source" and they get the same benefit. And IMHO, it's not your decision to make, i'd suggest it though.
How about instead of writing something from scratch, and open sourcing it; you find an existing OSS Project and extend it to do what your customer needs? There is a better chance it will be maintained when you are done with it, because it is already being maintained. If we all did this we would have a few enterprise level Apps that kick ass instead of a bazillion that are half written.
But please don't bother open sourcing anything if you (or no one else) plans to maintain it.
There are enough dead projects out there already. Don't add to the graveyard.
If the software is not seen as a huge direct advantage (the secret sauce) and is not sold by the company, then there is a big advantage in having the source open if it is a generally useful set of functionality. In this case it is likely the company will benefit from ongoing free maintenance and debugging. They also get often more talented and interesting programmers involved if the result is OS than they would get to come do maintenance on a piece of proprietary code. If it is fairly popular they can also more likely find talent when needed that already knows that code.
It sounds to me like you want to have your cake and eat it too. Isn't the typical Slashdot argument to paying for software, "All software should be free"? And yet, you still want to get paid to write it? That doesn't seem to compute to me. This seems like the big problem with the open-source methodology. Nobody likes to work for free, and yet people often voluntee their time and skills for certain efforts they appreciate/support/believe in. If you want to open source the software, then open source it and don't expect any compensation for developing it. If you want to be compensated, then don't complain when companies like Microsoft, Sun, etc. want to be compensated for their work in developing their products.
Your client could be convinced to open-source something if:
On the last point, they might agree if you can show the client that what you will be writing will indeed be picked up by some other people/companies. These other people would be interested in what you wrote because they would also need what you wrote, and the improvements made by others can provide a direct benefit to your client.
I realize that the logic is somewhat circular here. You have to prove it's good enough for everybody, and then everybody else would do something that's good enough for your client. Presumably then they would also need the technical expertise to actually use what you did.
The other problem is convincing the client that there is nothing proprietary to them in the software. If they hired you, it usually means they don't have enough in-house expertise to decide this, and their decision will be no.
If this gets open sourced, your name would be on it, and that means you would be on the hook to _everybody_. It does not absolve you of the responsibility of maintaining the software and defending your design decisions. In fact, it makes you more responsible.
I have worked with companies who thought about this long and hard, and typically did not do it. The exception was software that was end-of-life, with maintenance being cut, and the costs amortized. At that point, unless one of the points above applies, it can make sense because open-sourcing internal software is a hedge for maintenance provided several others start using it and work on it.
On the IP-side, the work you are doing is considered "work for hire." This means your client owns the IP, all of it. It's like being an architect: you draw plans, and if the client goes ahead with building the building they have full rights. Yes, your name is on it, yes, you have liability exposure, but they own the work, because they bought it from you. The only way to get around it is if the agreement between you and the company states clearly that you are giving them a license as opposed to performing work for hire. If you want to be really clear about what you're giving away, get a lawyer - your client likely has one too.
just my half-cent.
- - - Non Caffeine Drink or Drink Error
It doesn't seem like he was neccessarily looking for the OS community to work on the project, just that he would like the code to be availible OS after the contract is finished.
Spencer Ogden
not the code. Develop the code under GPL/Open Source. Then charge them to implement it on their system.
Re-organize it so they are paying for your support and service while you are paying to write the program.
Frankly that is what you are trying to do anyway. You want them to pay you for your services not for your code or you wouldn't have even considered open sourcing your SW.
-- Mean People Suck
Wow, although this seems to be the work of a troll, I find this feature quite interesting. See, I can't cook but I want to learn and I'm always interested in easy to cook recipes. And imagine, finding recipes on Slashdot! A good interruption from the usual on-topic discussion. Is this part of the enhanced service from subscriptions?
What time is it/will be over there? Check with my iPhone app!
> Leaving it up to the OSS community and expecting
;) Letting people do whatever the heck they want with the code.
> them to produce something useful to your client
There are many more reasons to open source something than to sit back and let people hack at your code while you just absorb the patches, you know.
Sometimes the code is dead to you. But you make it available just in case someone else wants to use it. Sometimes a hack you made would serve as a great example to help teach someone else. Sometimes it tackles a problem in a totally new way that someone would just love to incorporate into their program.
I make a habit of tarballing everything I write and tossing it up on my website. I don't clean up the code, I don't turn it into a distribution.. I just let the people have the code because it serves no purpose to let it rot on my HD. Has anyone ever sent me a thank you email? No. But watching my http logs, once in a while someone does download something, and it feels cool to know that someone somewhere might be learning something from it.
THAT's what open source is about.
Will you be assigning the copyright to the client, or retaining it for yourself? Answer this question, and your question falls apart. If they own the software then they can license it (or not) however they want, and you have no say in the matter. If you own the software, then it's entirely up to you.
If you can't answer this question then you have bigger problems than whether or not to open-source.
As a consultant it is in your best interests not to alienate clients with "political" arguments. If the code is theirs, say nothing, let them do with it what they want. You can perhaps suggest that they open-source it, for the reasons you outlined; but don't push them if they are resistant to the idea. If the code is yours, say nothing; re-use it, or distribute it, however you like. There is no need to convince anybody of anything either way.
Our contracts are written to be result oriented. In other words (this is software, right!), the client does not own the code but they own the rights to use the product. Since a lot of development tends to be requirements analysis, design, testing and production implementation, we have no problem with this. They are paying for a service as opposed to when they buy a car they are paying for a product that they can touch and feel.
I would have a problem selling code to the client, because that would likely involve also giveng up any copyright and patent protections to what we have written. Since we tend to modularize code and reuse things in our Web software business, this could potentially create a lot of problems. We decided to just write into contracts that we own the code in the final product. If it is extended or enhanced later by anyone else, those changes must stand on their own.
With this type of agreement -- and this is possible only with certain clients for obvious security reasons -- we can open source the code we have written at will.
The poster should have clarified whether the customer believes the software provides competitive advantage or whether it merely simplifies some administrative steps in their operations. I assume the latter, but it's good to clarify in this type of situation
Don't present a smoke and mirrors handwaving routine. Just plain speaking will do you fine, I'd guess.
I'm going to assume, perhaps incorrectly, that you are developing an application which will be deployed in a GNU/Linux or BSD environment. I'd simply say "I'm able to provide this solution for you because other people have provided free license for use of their software. In exchange for my services you are paying me money. In exchange for the contributions (which are 99.9% of the total package) provided by the free/open source software community, you are simply agreeing to contribute something back."
--Lawrence Lessig for Congress!
Even worse, look at "Apache." As a native American, Ivomit projectiles thinking that a proud race of people is associated with a poorly performaing web server. Additionally, it's "free", which reminds us that the white man often raped our women when they couldn't find a chicken or a goat to have sex with.
should not be used under any circumstances. It supports terrorism and child rape.
If anyone has ever had to deal with a Lawyer you know what I mean. Call the man to chit chat for 15 mins and you get a bill in the mail for his $450/hr rate divided by 4. No kidding. Why should your time be worth anything less?
Don't give your software away and don't sign away your ideas if you can help it(i.e. IP). Every idea in your head is worth money to someone even though you may not realize it. Telling your client that you recommend giving this software away will make them feel insecure and they will also be reluctant to hire you again to maintain and extend the software. Also, If the software truly is 'unique' it is another feather in your hat that the next contracter DOESNT HAVE. Don't work yourself out of a job. Know the difference between what is work and what is your hobby.
Regards,
Peter
www.alphalinux.org
Why does a business hire someone to write code? Either to save money on a rote task or of more interest to gain some type of competitive advantage in the marketplace. So the real question is why would I pay you to develop this advantage and then let you give it to my competition?
No shit. I can smell you all the way across the internet. Take a bath, already!
2. I played with myself in college -- thus, contradicting your moronic little point of fiew about masturbation.
Au contraire, you're validating his thesis.
3. The names of my alternate personalities goes back to the early '70s when I was originally overdosing on LSD -- jack off sessions had to be short b/c I wouldn't remember it in 5 minutes and would need to clean up my briefs.
Thanks for sharing!
4. You are a sad strange little man. Can I have your phone number?
First, base your project on an existing Open Source project. Show the client how much value s/he gets from starting with the project(s), not limited to the fact that others have reviewed the code.
Second, once the client sees that h(i|er)s project will benefit and that the total project will cost less, explain the need for continuous updates and maintenance. Explain how costly it will be to maintain that work totally and solely in house.
Then, propose a solution to 'leverage' the Open Source community to assist with the project by releasing the changes, with the client's approval, back to the project. Explain the benefit of many eyes and many users perfecting the codebase.
This is exactly what I and a colleague have done with a very properietary-minded client. Now he's onboard for releasing the modifications and enhancements we will create back into the project community. Actually, he's excited to do this.
The way to your client's heart is through the bottom line.
-- @rjamestaylor on Ello
Not so, Mr. Coward. Look at RedHat's Interchange. No gamble there.
-- @rjamestaylor on Ello
Heat 1 cup milk to just under boiling. Add 3 tbsp sugar. Mix 3 tbsp corn starch with cold milk. Add to the milk, and stir.
Can be eaten hot or cooled off and eaten cold (It's never lasted long enough to cool off when I'm around, though!)
You can add vanilla extract to make it vanilla, melted chocolate chips (or chocolate syrup) to make it chocalate,
All our bid specify that the cusom software is GPL'es and it's help us squish the competition after we explain the benefits to them:
1) If we die, then they arn't left up a creek without a paddle.
2) Their data can be easily migrated over to a new peice of software if need be.
3) They can extend the program if they later decide that we suck.
It wins contracts, and we don't low-ball our bids.
Aside: Never low-ball a bid, it looks syspicious and makes the prospect nervous.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Rob Malda or Roblimo?
Or both?!
PS - I hope your herpes clears up. But, hey, I told you to stay away from Hemos.
In particular, I'm curious about Asynchrony because it might be effective for a self initiated community project to acquire the use of Asynchrony's sales and marketing arms. But I find what seems to be a contradiction in their terms of service.
Here's an excerpt from Asynchrony's FAQ:
However, here's another excerpt from their Intellectual Property FAQ: The second statement appears to be contradictory to the first. I sent an email last night to the CTO of Asynchrony and his response today was that they're still trying to resolve that issue. I can't think of any upstanding and highly marketable open source project in its right might that would reassign copyright ownership to a foreign company just for a sales and marketing service. However, my cursory glance of their web site leads me to believe that their business model and corporate behavior are fully within the spirit and intent of licenses such as the GPL, so maybe we can come up with some ideas for them to solve this dilemma.Why should a third party need to own the copyright of an open source work (GPL, BSD, etc) in order to effectively market and sell it?
I contracted for years to several companies, developing custom solutions for them, and never once did I have to give them the source code (lucky, they were a pack of twats!). IP rests with the developer unless the contract specifies it belongs to the company who hire you. They have a clear right to the binaries, but access to the source code is up for negotiation.
What is the point of open sourcing the code? Put it in escrow if the company requires that, or negotiate code release into the contract if they want that, but make them pay for it. Remmember, it is always more expensive to contract someone to produce reusable code for you, than it is to have a system built.
All those moments will be lost in time, like tears in rain.
I wouldn't be open sourcing random projects under the GPL. Why should I pay for development, why should my stockholders pay, when ultimately, our competition will say, "Hey! That's neat!" and snag it for free? Corporations don't like feeding free cash to their competition, and this is pretty much the equivalent.
;)
But then, that's assuming my imaginary corporation (We'll call it Taco Corp) has the resources to say, "No, thanks." and shove the development onto in-house coders.
Even if Taco Corp didn't have those resources, I'm all but certain that they could find someone who would agree to their terms.
And, in truth, this is all FUD, but FUD that is not often rectified. By shoving the program under the GPL, I'm not obligated to release the source code. If the program is ultimately being used in-house, the only binaries being distributed are with the company - and they'll most likely have the source anyway. (And I assume this is what we're talking about - in house programs. I can't see why a company would be outsourcing coders for a product they're going to sell!)
There are benefits to this sort of thing. When the program ultimately falls into disuse, the corporation can gain some flag waving from the open source crowd by easily releasing the source and binaries to the public. The company has no use for it at this point, so where's the harm there? They'd just delete it anyway, but instead, they toss it to a foaming community that will shout "Taco Corp ROCKS!". Free publicity/good deeds and whatnot.
Even if they make severe additions to the code, and the final program is still in use, they can, AFAIK, release an earlier version to the public provided they're not shipping out binaries of the changes they've made.
Let's face it; we are foaming lunatics. We have to be - we have to support companies who even toy with the idea of releasing the source to products. We have to show them that they can gain from the good PR they'll get from doing things like this.
While it seems like they're getting the lion's share, in the end, we win.
A lot of Open Source licenses DON NOT prohibt you
when redistributing your modifications. I keep
reading OSS this, OSS that, but you newcomers to linux
instead of using the corrected definition of
of GPL when appropriate, or "Free Software" in
the cases when also appropriate, you continue
to say Open Source instead in all cases. Even when you totally wrong!
If there is an existing GPL or LGPL project then try to convince the client that extending/modifying the product is more efficient than you developing it from scratch. Of course if you get paid by the hour your kind of screwing yourself, but hopefully the client will appreciate your efficiency and hire you to do more work.
It's irrelevant to rant about who should own the software, you or the business owner. It's been said that in business you get what you negotiate, and if it's important to you that the code be open source, and if your client is a small business owner with no interest in selling the software in the future, then I'm sure you will be able to negotiate with him very successfully.
The tactic to use is to tell him that it will be easier for you to write this software, and therefore less costly to him, if you can use GPL'ed component libraries in the software, and that the GPL requires that the resulting software must also be licensed under the GPL. Point out to him that this means that he will get all of the project source code, even the source code to component libraries, and that he will be free to hire anyone at all in the future to maintain, modify, or update the software - he won't be "locked in" to you or anyone else, as sometimes happens with vendor-proprietary software.
If he balks at the idea of releasing to others for free the source code that he will have paid to develop, point out that he is benefitting from thousands, perhaps millions, of people who have already done the same thing - paid money or contributed their own valuable time to develop tools and components that they have given away for free.
And you can point out the possibility (although it's admittedly remote) that if the software turns out to be generally useful to others, the open source software community might take the software, modify it to suit their needs, and release the modifications for free, so he might benefit by getting free improvements to the software in the future.
Again, in terms of answering the poster's questions, the issue is not whether the above points are valid, but whether the above points are likely to convince the business owner that GPL'ing the software is in his best interest.
"To be absolutely certain about something, one must know everything or nothing about it." -- Olin Miller
We are a custom software development shop using our own framework as a basis for delivering custom applications to customers.
We have an arrangement with our customers which works out very well for both of us. Once you factor in the incentives of both parties, this arrangement naturally leads to a happy situation for both parties.
We come into the relationship with a substantial framework, which we license to the customer under the GPL. As the relationship progresses, we build many components. Some of these components are specific to the customer's business process, and some are more generic. We retain all IP rights to the generic components, which we integrate into the framework and license back to the customer under the GPL. The customer retains all IP rights to code that is specific to their business process.
We maintain a code repository for each customer which contains their business specific code. These are typically workflow definitions, business specific data models, entry screens and reports, etc.
We also maintain a common repository for the framework, which contains all the reusable code (whatever we define to be reusable). We usually have a few projects going on at the same time, and this repository receives contributions from all of them.
The benefits of this arrangement for the customer are:
* Customer owns specific business process logic, UI elements, data models for their business, which means that they control their trade secrets and we can't go to their competitors and sell them the system they payed to custom build. In return, customer is solely responsible for paying someone (usually us) for maintaining and enhancing these components as their business changes.
* Customer does not have to pay to build a major system from scratch. They get a tested and tuned framework for free upon entering the contract, and only pay for customization, which is a process we excel at. In this fashion, we can deliver a return quickly and with minimal expenditure, since we don't have to build much infrastructure.
* Customer gains the benefit of framework enhancements for other customers. Over time, as contributions are made to the core framework, more and more reusable functionality is available to incorporate into our custom solutions. This has the effect of bringing sophisticated functionality into the customer's price range. In effect, all our customers indirectly share the cost of maintenance, tuning, and additional generic functionality.
* If we go out of business for some reason, the customers have all the source code they need to achieve continuity.
The benefits of this arrangement for us are:
* We gain a powerful framework that is tested and tuned across multiple production deployments.
* We can out-bid competitors who need to build things from scratch, who base their work on proprietary software which they cannot enhance or control, or who must recoup massive amounts of R&D , marketing expense, and capital risk.
* We spend our time solving unique business and technical problems, as opposed to re-coding functionality for multiple customers simply because we don't own IP.
* We spend very little time on maintenance because most of the difficult code is maintained in one place- application specific code is mostly declarative.
* We do not have to pressure customers to buy upgrades. We keep customers current as part of the development process.
We have been modestly successful using this model, and people who work with us, both developers and customers, are happy and getting good value.
Once caviat- our customers tend to be in a line of business other that software development, thus they care less about owning software IP than than do about streamlining their business processes.
Hopefully this will inspire some ideas.
Mike
I am doing this at my work, we have a solution on blocking Spam and
Viruses, using external virus checkers but basically the rest in C
and open sourced. My employer understands that now they will never
have to worry about changes and updates when I move on, and they
find that to be a good thing. It is a great solution and I have
gotten to work on it as a job, so it is really robust and am lucky
to be allowing people access to something free like this and
solve their problems with Spam and Viruses. If anyone wants to
see our software, called BlackHole, check it out, it is an example of
the product of this whole topics concept.
http://www.freshmeat.net/projects/blackhole
bitbytebit
The question makes a wrong assumption about Open Source. It assumes that you have to give the source away to everyone. That is wrong. There may be some licenses that require this, but they are few and far between.
Let's take two examples, the BSD license and the GPL. The GPL only requires you to give the source code to the recipient. In this case it happens to be your client. Once they get it, it's up to them as whether they want to distribute the source further. The BSD license doesn't even require this. But you're going to give your client the source code anyway. So it makes no difference.
That said, I think it would be extremely rude if you charged your client for the code and then turned around and posted it on your website. If you're going to do this, let them know ahead of time.
A Government Is a Body of People, Usually Notably Ungoverned
Actually he's right.
If your hired to provide a solution, you own the code.
You don't even have to give, or even *show*, the client the source. It's yours.
The best way to assure this (and avoid legal action, which is unlikely to be taken by any small company at any rate, unless you are clearly ripping them off to the extent they belive they had a VERY good chance of winning) is to simply state in smal type 'all IP and origional work remains legal property of the author'.
The onus is on the client to show that he has purchased - or prove that he belived that he was purchsing the source.
An author whom writes custom code for a particular client wants to own the IP rights is like an Architect walking into your home to use the restroom any time he likes because he designed it.
I still don't get why people around here are so big on open source. Besides the usual "information wants to be free", what's the draw? Is there any economic benefit?
put it in the contract from square one. if they have a problem then they dont get the software or you do a BSD style licence.
I have written software for clients, anything from simple shell scripts to large web applications.
Typically, If I intend for the software to be OpenSource, then I only charge for the installation of the software.. and not the development of it. I will normally charge for the installation of opensource software which I did not create, why should I not charge for the installation of software which I have created?
I have worked for some clients who have requested, at the completion of the software.. for it to become Opensource, for the sole reason that the software meets their minimum requirements.. but would like continued support after the end of my contract.
If you have any doubts, discuss it with your employer/contractee.
But did you make it to the NBA? No? Therefore you weren't actually good enough at basketball to make a living at it. Thus, contradicting YOUR moronic little point of view about athletics.
If your client is needing something generic such as file sharing between Unix/Windows (SAMBA comes to mind) then making it GPL might be a good idea. You get it working, or almost working and others imporve upon it. Others benefit from your work, you benefit from theirs and all is well.
.00000001 dollar/lumme (example only) then maybe going OSS is not such a bight idea :)
But if you are contracted to produce something extremely proprietary such as how to simulate/produce white light diodes for
Gizmos Gagets For Ninjas
Oh. One more thing. Are you white? Yes? You are no doubt racist because you harbor resentment to the black players who COULD make a living playing basketball.
Looks like you prove his thesis on TWO fronts.
thats beautiful, really it is
- The contractor owns everything; customer gets license to a binary
- The contractor owns everything; customer gets license to binaries and the source code under some circumstances (such as contractor unavailability)
- The contractor owns everything; customer gets license to use and modify binary or source for any internal purpose
- The contractor owns everything; customer gets an unlimited but non-exclusive rights to binary or source.
- The contractor owns everything, but agrees on limitations on reuse or redistribution; customer gets some license from above
- The contractor owns nothing; it's a work for hire, since the customer contracted for the work rather than a service
- The contractor owns nothing, but the customer grants certain rights to the contractor, such as limited reuse of modules.
- Ownership is mixed, with some parts retained by either sides.
It sounds like what you need to do is agree with your customer what their expectation is on licensing, and get that in the contract. For example, if you own the work but agree not to disclose certain modules dealing with business process, it's clear to both sides what you can and can not disclose later. That may mean reuse on other contracts, provision to their competitors, or release to the general public.In general, the more restrictive the customer rights to work performed, the higher the rates.
Well, say I can use a lot of GPL code as a starting point for the customer's project.
In this way, I don't have to code everyting up from scratch or buy a lot of possibly expensive libraries and modules.
Or, I may have written a similar package in the past and can use that as a starting point.
There are many reasons why a client will pay me to do custom work for them and still be happy to let me GPL the result.
If you happen to not run into these situations, so be it, but others (at least I) do all the time.
A Nony Mouse
You are the author of the work and therefor have the copyright unless the you assign it to the client or unless it is a work for hire. Since your are not an employee, and it is not a collective work, etc. (See http://www.loc.gov/copyright/circs/circ09.pdf, warning: PDF) it is not a work for hire. So, in theory you can do anything that you want with it.
That said, you have an ethical obligation to work out a resolution with your client.
(Assigning it in the contract is also considered a work for hire.)
In theory, theory and practice are the same, in practice, they are not.
>>> I will also be willing to sell them a copy of the source code in which they own all rights
Wrong, moron. if you sell them gpl software you must GIVE them the source.
Go back to grad school. We in the real world don't have time for this foolishnes.
so you are advising this guy to pay you thousands of dollars to create a new system instead of paying $500 to change the old one? it's a great deal for you, but this guy would have to be a terrible businessman to see it's a terrible deal for him.
you must be green. get real dude. there's nothing wrong with propriery software. If your getting a 100 an hour, you do it the way they want and you don't try and push your softpoli beliefs on them.
do the damn contract and fight your os fight
with your os projects.
jeesh. what an idiot.
-- "The best way to predict the future is to invent it."
So you wish a client to pay you a lot of money to
develop a product that will give him some sort of
comptetive advantage I assume.
It makes sense in a capitalist society that he
is willing to pay you for your services because
he figures he can make more money, or spend
less time doing it.
Now does it in a capitalist society make sense
that this individual would be happy that you
after he fronted the entire cost, give it away
to all of his competitors?
Yeah that seems like a great suggestion.
I've been thinking about this a lot in the last couple of years. As another thread here pointed out, much of the code in a standard custom business application (and I've built many custom ones) is not particularly specific to that business. There are many levels of application code for managing client processes, logging, demon processes, transactions, connections, etc.
Also, for some sub-domains within the larger problem domain, the data structures may be fairly generic as well. For example, the structures to manage customer accounts, mailing, payments, billing, things like that.
My argument is that there is no reason for a customer of mine to "own" those really generic portions of the app. There is no value in rewriting them for another customer, apart from an hourly rate. What the customer does "own" is the specifics of how they do business, and the data for their business.
Of course, there will be some businesses that will need fancy logic, for example routines to forecast inventory or sales; and those routines might be specific to them and a real competetive advantage.
So my new strategy, which I've used successfully once so far, is to contract with the customer to say that I (or my business) keep and reuse any parts of the code that are not specific to their business. To make it easier, I also put customer-specific into well-identified directories, packages, modules, etc.
I believe what customers are paying for is not the software (in the case of business applications) but my ability to understand their problems and model these into solutions on a software platform. The software is free; I bill for thinking.
p!yaya
"I honestly would vote libertarian if their candidates weren't usually total cooks."--slashdot poster
Amen, brother. :)
iocat is spot on with this one.
That said, if you are doing contract work already you should aready know. Get thee to Nolo before you get yourself into trouble.
~~ What's stopping you?
As the developer, you own the copyright to the code, and therefore the full right to do whatever you want with it, unless you explicitly sign away those rights (which you shouldn't do).
So if you want to open source it, go for it.
Michael
Do you have ESP?
IANAL. I do own a business and have written applications in the past for clients among various other "kitchen sink" responsibilities.
Normally, contracts are written where the developer retains ownership of the code. For a situation where they want ownership of the software, they should be paying very big bucks. If the developer chooses to give it away, to the customer or the world (as OSS), it's the programmers perogative.
The anology I use is artist prints. When you buy a print, you but the right to look at the print. You don't buy the original nor do you get to charge a fee to for others to view it or get the rights to reproduce it or the rights to the original. As with the print and the artist, the rights to the software remain with the developer.
If the developer chooses to give away the source code to the application, the customer benefits but so does his competition (possibly). We don't know what the application does so we have no way to gauge here if it benefits the competition. Even if it does, when the developer owns the source code he/she is within his/her rights to give it away. And a strong argument can be made for benefit to the customer in this situation because there is the potential for maintenance of the software by a third party, possibly getting free or "for pay" support.
I don't know about Open Source ~;-) but there is nothing wrong with getting paid for Free Software.
People making these eat cake and have it too comments are either blowing smoke or seriously without a clue and I am not trying to fan the flames here.
Most of life moves as a result of making deals. There are some deals that are illegal to make. There are some deals where the law says how things go if they are not spelled out to the contrary.
You make the best deal you can to get what you want, let the client do the same. So long as both parties know the deal they are making (no hidden surprises) and agree to it, what is everyone's problem?
A Nony Mouse ~;-)
That MS doesn't own any of it's code, that the programmers they hired do.
I wonder why I'm not collecting use royalities on all the cabinets, exhibits and corporate theater sets I've built.
I have thought about hiring someone to write some code for a project that would be GPL. Am I somehow prevented from doing so because psuedo software engineers want all the rights and control over something they didn't figure out but only implimented?
It shouldn't be any wonder why Microsoft wants to dominate the world, for it is apparently the mindset of programmers in general.
re-inventors get paid way to much!!!!!
And that includes Microsoft.
Irrelevant. Interchange is not contract software geared toward a specific business. The previous Coward has a good point in that no matter how much you open source your software, hackers won't touch it if they aren't interested in it. The chances of finding OS coders who want to play with that specialized building supply inventory management/accounting software is much slimmer than finding KDE, Apache, or kernal hackers.
I myself do custom work for small businesses for a living. I'm a Java guy who's into open source, here's how I typically work:
- Gather requirements duh. You gotta find out what they really need, obviously. Not always clear, but that's part of
the job - translating their requirements on a business level into concrete development action.
- Sell the Client on pre-existing OSS frameworks In my case, server-side web development w/ Java, this almost always
includes Tomcat. Not GPL'd, but hey, certainly better than the other, proprietary
crap. Lately I've been doing more involved projects, so I've been pushing JBoss as well, which _is_ GPL'd and frankly fantastic as well. I
try and run these on Linux w/ Apache if possible. I find this is not a hard sell - the main points being no licensing costs
for them, more stable tools than the proprietary solutions, etc. These are also popular well-known systems which always makes
business types feel better than unknown sketchy things.
- Use pre-existing OSS libraries for the general parts For me this means class libraries - if I need logging I use
log4J, if I need XML processing I use Xerces, etc. (well bad examples since they're APL, not GPL, but you get the point). I also make this clear to the client, they usually like the idea as
it saves development time and thus their money. I also let them know that any code I write to improve these libraries goes
back to the project and is not the ownership of the client. This is also not a hard sell - my client doesn't care about
owning parts of a logging system, it's not his business. This is how I get to contribute to OSS on the client's dime.
- Write the custom bits Given the above, all that's left is business logic and design. For me this means
incorporating the client's business logic in a bunch of servlets of EJBs, and their front end design into a JSP page or an
XSLT template. I typically give them full IP ownership of this - yes, I charge a higher rate b/c of this, and frankly this shit
is useless to me outside of the current project anyway.
Bottom line: if what you're coding for your client has general value and is thus worth open-sourcing, you're probably reinventing the wheel which pegs you as a beginner in this business.Those are all nice reasons for Open Source code. The problem is that none of them apply to a business that is about to pay thousands of dollars for a person to develop software tailored specifically for that business.
He thinks he's buying a product from you, not subsidizing your personal open source development. I'm curious, how do you feel that this will be in his best interests? His best interest would be for you to become his hire, develop the product, and walk away leaving all your work in his posession.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
All other things being equal your customer will want to be able to fix and improve the software. You have the ethical obligation to either remain in a support position (which you have stated is not an option) or to make sure that the customer can arrange for support themselves - this means they get well written, well-documented source.
As far as the customer is concerned it is absolutely irrelevant whether or not the code is open-source; indeed, I can hardly see how that would help them out.
If you want to support open-source try to use as much of it as you can in your solution for the customer's problem, and sell them on that. That actually helps them out, support-wise. Your idea, which creates a developer community of precisely zero around a special-purpose one-off codebase, helps no-one. It may not hurt, but it sure doesn't add to the equation.
As a complete aside, this entire discussion has been a complete eye-opener to me as to the different viewpoints that exist out there. Some peole sound like craftsmen, some people sound like artists and authors, some people sound like technicians, and some sound like professionals (engineers). Not saying that any of those viewpoints are wrong, but boy, do we ever have a disparity of perspectives when it comes to what we think we are.
If the client has an idea and a project that plans to launch, he will seek someone to make it and pay for it. The client wont pay something and others will get it free,
I dont think there are companies that will pay for a specific software and give it to everyone for free, it doesnt make sense.
The developer can also tell the client that the more they want to own the code the more it is going to cost them. A completely closed app that a client owns ALL rights to means that the developer has to reinvent all of the little wheels and gears in it. The developer cannot even use his own private stock of functions much less anything GPLed.
Ironically, a developer coding such an app could use LGPLed libraries as long as he didn't have to patch the libraries himself (absolute ownership again). For that matter, the developer can also use the BSD and X stuff as long as all copyrights are acknowledged. The personal toolbox however would be completely out unless LGPLed or using one of the acknowledge copyright licenses.
It also means that the developer cannot add anything to his personal toolbox that comes out of an absolute ownership job. The developer is also in peril if he codes anything else that looks like something he did on an absolute ownership job.
That might be the best angle: "I can only give you a non-exclusive license to certain parts of the apps as I cannot put myself out of the market from having worked for you." This is a purely business argument and may go over better. Don't say "open source" at all. Just negotiate space for you to retain ownership of your generic functions and license them according to your inclinations be them Open Source or Proprietary.
If you really want to release open source but your client does not. You could discuss making it a requirement to open source it after they have had propietry use for two or three years.
This means that not only will it eventually be open sourced, but your client could sell consultation and support for those who wish to use the now open sourced programme.
even if the Bunny could, it would not
The reason why your customer is paying you is that he wants something unique written for his benefit. If his competitors can use it, it is worthless to him. And if you attempt to deprive the customer of the work he has paid you for, you're cheating him. The GPL is a "booby trap" license; see Stallman's "Why Software Should Not Have Owners. Spring the trap on your customers and they not only should not hire you again but would be justified in suing you.
Oh god. Next thing we know you lunatics will start arguing that calling white "white" and black "black" is racist because black, we are told, means "absense of light" and white means "all light"
::shrugs:: Don't give a damn- you still annoy me.
Let me put it this way. If a black person wants to pioneer an opensource movement of any damned sort, all they have to do is DO IT.
I know. You're being "humorous" or "sarcastic" and most likely you're white yourself.
The whole reason programmers are paid to develop custom systems is because there isn't a shrink-wrapped software package that does exactly what they want. A custom system is not generalized, documented, or supported well enough to be resold as a packaged product to a mass market--because that's not the point!
The client pays you to build them a system that is tailored around their business. If they didn't want that, they would've bought it from Microsoft already.
The client should care if his rights to the code mean that he can fire you at any time and hire someone else. There is no reason they should ever expect to possess sole IP rights to it.
It might mean that their competitor gets their hands on it one day. I say big deal. In all but the most contrived cases. their competitors are likely not to have the same systems, access to developers who can easily work with it at their disposal, or a desire to use code written by their most despised rivals. In the remote chance that their competitors do gain from it, the benefits of open sourcing it will far outweigh anything bad that their competitors may have gained.
Open sourcing the project does have the obvious benefits. A community may develop around the project and support it long after the original developer left it behind. With this comes positive feedback, as the company (to the seemingly uninitiated) has committed a wanton act of charity--but they know the real truth, that software is not a zero-sum game and that by giving up nothing they've gained so much.
Or they can naively hoard code because they think their assortment of bits has an intrinsic resale value, but will in the end gain them only the loss of the benefits of open source.
I am currently hired to write some custom software and should be doing that now.
Anyhow I give the impresion I am customizeing a software not createing one. The clients don't even think about IP when thay belive that you alread own the IP. Also you can milk more money out of it.
A few $$$ for the application, customization, Support, etc. Oh just don't have anything on paper that you sold them an application, I am not sure about sales Tax but I belive you(i) would have to pay it.
OK I see all these post about the client wonts the source and so on. Most of you must be in the larg corparet world. 90% of the people in the Small Biz world don't know what a GPL is nor do thay care. Nor do thay know what source Code is. Nor do thay know what a computer is. Thay just wont something that works and don't care how its done. Unless of couser is a software firm but then what would you excpect.
I'm not expecting many comments on this, but there is the .nz domain SRS project. There's been a lot of discussion on it. From InternetNZ:
I'm interested to see how this pans out. - Jonathan
Jonathan Ah Kit - Lower Hutt, New Zealand - jonathan@metalab.unc.edu
Scenario: I pay $200 and buy Office XP. A few days later Microsoft decides to make it 'open source' and puts it up on their website for free download. Is it legal for them to do it? Probably Yes. Am I going to get pissed? Defintely Yes. The client in this situation is similarly unlikely to be happy about open sourcing software they have just paid to develop.
The last several big jobs I've done, I've agreed in advance with the customer that the software produced would be released under my copyright under BSD license. I've had no trouble getting big corporate customers to agree to this. The next negotiation, I shall try to get them to agree to GPL. It has some benefits for the customer: it guarantees that they have access to the codebase in perpetuity, whatever happens to me.
I'm old enough to remember when discussions on Slashdot were well informed.
Umm, no. Crowheads point stands. Any company that hires someone to write software for them, and then gives away the ip/code to the developer is being run by idiots
You've never done contract work, have you? If they have no use for the IP, then they have no reason to take it from the developer.
. There is no reason to allow this, especially the market being what it is nowadays
The market for what? Software? Didn't you read my last post? If they company is selling the software, then obviously they would be more concerned with IP rights and so on, but the fact is that most companies that hire contract workers are looking for specific peices of software to help them with their businesses, they are not looking to resell the software, software companies usually hire their own programmers to write software. Admittedly, there are probably some cases where specialist programmers are contracted to augment their own in-house skills, but there are a lot of companies whose business is not dealing in software (developing and selling), but who nevertheless need custom software to aid their businesses.
I would imagine it would be easier to convince them to open-source it than to allow oneself to own the ip, since if it's open-source at least they are assured of indefinite free access to it
You don't seem to know the difference between IP and source code. Source code files are instructions written in any number of programming languages used to create computer programs. IP is the rights on what to do with this source code. Unless the company is a software company, they would have little use for the IP. They might, at a stretch, want to keep the code, not for reselling, but for further customization, but if they aren't a software company, in other words, if software isn't their core business and they don't have in-houes programmers (presumably the case since they hired a contracter) they would need to hire a contracter to make any further changes anyway.
The only catch to this is if the developer has some remarkable leverage in negotiating that would persuade the client to give them the IP
With respect, I don't think you know exactly what you're talking about. Unless otherwise strictly specified in the contract, the IP goes into the hand of the developer. Programs written by contracters are generally used to serve a specific function, not to be a product in and of themselves that the client would use as a seperate, marketable product to resell to their own clients.
As for a company just giving it away to the developer with no compelling reason or significant balancing contribution by the developer, I would say you are talking about a very naive/incompetent business.
Again, with respect, I think that you should get some real-world experience of how companies operate before coming to this conclusion. If we were talking about employees of a certain company getting IP rights, I would agree. Contracting one company or individual to do work for another company is not the same scenario.
Cedric Balthazar Rotherwood
Sun Certified Programmer for the Java Platform +
System Admin. for Solaris
The poster forgot to mention what OS this software is for. I'd laugh pretty hard if it was Windows.
Compromise.
The client gets exclusive rights to the software for two years at which point the software becomes open source. This would manifest in the form of a clause in the contract stating such.
This would give the client room to breathe against competitors or enemies seeking to compromise their software, gain from their expense, etc. while still allowing for the continuation of the code in the open community. If the code is interesting enough to still be viable in two years then it will persist.
This is very similar to having someone license technology but instead of losing their rights to the tech they merely have to share with everyone else, though not any additional modifications they have made to the code in the meanwhile.
This would also mean that the code would have to be put into escrow in order to meet the requirements of the contract for both parties and as an insurance measure for both parties.' Escrow 'meaning that a 3rd party would have a copy of the original code and would release it into open source according to the contract despite any intentions of the two parties otherwise.
Seems like a lot of effort but if you think your code is important enough to the community at large then this would be worthwhile because of the checks and balances it imposes. The client would of course pay for everything.
A fool throws a stone into a well and a thousand sages can not remove it.
The reason your customer is paying you is that they want software, either to run or to sell. If they just want to run it, it's not at all obvious whether they're harmed by anyone else also being able to run it, and in fact more users can make shared enhancements and user groups possible.
Well,
g
don't know how common this practice is.
But for my company it is.
An example of a piece of software paid by a single customer and now released as Windows freeware:
Remote Service Manager.
Another heap of php code, that is going to be released as opensource and has been developed for a customer:
Systems Intranet Contruction Kit.
In both case we did what was necessary for the customer and felt like we had to release the work also as opensource/freeware.
With different nuances there could be this Linux administration course (in italian) which can be freely visited on web but for which we request a fee for commercial courses in classrooms.
The intention is always:
- to produce something that the customer has requested;
- to sell its customization/implementation/installation/trainin
- to opensource it ("cos we received so much from the opensource world and it's time to compensate").
The underlining issues are always the same: how to make the production of opensource software profitable enough for a business company.
It's not always simple, but I think it's just a matter of finding the right approaches. We are trying some of them.
Sorry for "self promotional linking".
But actually nobody wants to sell you something at the other side of the link.
If I was a company looking for a custom in-house app based on GPL code - say.. a custom frontend for the pov-ray rendering engine(I think its GPL).
If I were to pay a freelance Dev the going hourly rate to write said gui and integrate with our systems - then GPL the resulting code...
Is this a legal approach? - even tho money is changing hands.
"Cheat me once, shame on you, cheat me twice, shame on me."
....
If the businessman pays the $500, he still has no rights to the source, and has to pay another $500 next time, and the time after that, and
If I'm writing something useful as a general systems tool, i.e. it somehow could advance the art or science of computing, then I request/negotiate that my employer or client open source it/assign me rights, in writing/contractually.
:-)
If the code I'm writing is specific to the systems or business of my employer/client, then I would not even consider doing it other than as work for hire.
In the first case, they are paying you to make better tools, usually so you can move on to the second case...building their "house" or software specific to their business and/or industry.
The first case gains me reputation, the second gains them competitive advantage.
That's just how I view things philosophically for myself
You suggest that giving it opensource will guarantee support. I dont think so. At its best the project will become another unmaintained project at sourceforge. Maybe it will even get on its unmaintained section (http://unmaintained.sourceforge.net/). For your customer this will bring no benefit.
And if your clients competitors get the program and find it useful: do you think they will give something back? Only if they are very moral people. Most people will simply conclude that they have no benefit from giving it back, that you - as copyright holder - won't sue them and that if they would give their code back there would simply be two versions - confusing further users.
Managing an OS project has to be taken serious.
so below.. gates. Now what place has a lot of them?
Oh, now the open source guys actually are starting to want money? Wow, you mean you are growing up and having real bills and wanting something in return for your time? Welcome to the real world. You think someone is going to pay you a million dollars to develop a piece of software so that you can give it away to all their competitors for free? How stupid a question is that? All I can say is HAHAHAHAHAHA you are clueless.
"The key to eating a black and white cookie, Elaine, is you want to get some black and some white in each bite. Nothing mixes better than vanilla and chocolate. And yet, still, somehow racial harmony eludes us. If people would only look to the cookie, all our problems would be solved.
In The Cathedral and the Bazaar, Raymond mentions a case where he spoke with a small company about some peculiar software they used for their product.
The company asked him if OSS'ing their software would be beneficial. His reply was "no", since the software had a somewhat limited application outside the context of this company.
The situation cited in the article sounds similar to the one ESR mentions, so I would have to say "Nay" here.
-PS. The story was in his book, The Cathedral and the Bazaar, so I am not certain if it exists in the online white paper of the same name.
I've tried convincing my chief for making our "yet to be developed" free software and failed. Many people here never think of making their software "free" (as in freedom and/or price) just because they think lotsa guys gonna look into your code, they'll probably use your code, write a better version of it and sell obviously becoming a competitor for themselves. You can't try to convince these people, you'll fail. So, the best thing would be leaving the decision to your client and incase you like to help the community by writing free software, do it in your free time. All the best.
Gopalarathnam V. Registered GNU/Linux User #218746 http://counter.li.org Please avoid sending me Word or Powerpoint
All the geniuses I work with?
.com and we didn't go under, though we came close. Am I an idiot for working at a .com? Is that judgement based solely on whether the company succeeds or fails? Even though that success or failure does not always reward the best companies and does not always punish the worst companies? Those who work at the worst companies that nevertheless manage to stay in business are lucky, those in great companies that went under are unlucky. You can't predict the future, the best product and the best business model is not always a guarantee of success.
Come on, luck has a lot to do with it. I work at a
We're talking about a small piece of custom software for a small business. WTF would anyone else know or care about it, let alone invest any time in fixing bugs or whatever?
The company suffers no benefits since no-one else will look at it, but potentially suffers a massive competitive disadvantage, since their competitors can now see exactly what they're using, find the bugs and capitalise on them, provide new features in their own products that would be hard to add here, and so on.
Come on, there isn't a single convincing reason to OS this project, and it's a massive liability. No-one in their right mind would consider it for more than a nanosecond.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Once it's open source anyone can redistribute it. Any disgruntled employee at the company could redistribute it, and we all know disgrunteld employees are the biggest security risk in any company. As do the companies themselves. Companies don't want to give angry geeks more ammunition. Anyone finding it in a shared network folder could copy it an redistribute it. A hacker who got into their system could redistribute it - you might be able to charge that person with a computer intrusion, but once they were in the system they'd be allowed to redistribute the code, the only restriction being that they'd have to redistribute the source along with the binaries. I'm not aware of any provision in the GPL that would disallow 'unauthorized' visitors from copying the code. Point it out to me if I'm missing something.
Simply hoping that nobody will redistribute it is, to put it mildly, completely retarded. Digital technology makes it incredibly simple to copy anything, and multiple copies tend to proliferate on most corporate networks I've seen. While if the code was protected by a conventional copyright, the copyright owner would be free to decree that the program could not be copied onto competitor's machines. See why they might like that legal power over pie in the sky hoping that nobody gives it to them?
Check this guy out "Well they can just not give it to anyone". Yeah, that's SUCH a rock solid legal plan. Let's remove any ability for our company to prosecute others for having our software and then just pray to god that nobody here gives it to them out of spite. Companies just make thousands and thousands of decisions just like that every day. Hey mr. 'open source' guy, have you ever noticed that management doesn't trust geeks because they don't understand technology? But they do understand the law. Then again... you've probably never dealt with management, have you?
What I can't see is the value to the open source community. I just finished coding my company's customer care application. Who the fuck in the rest of the world would want this? Would anyone else need to know how to call the specific stored procs that get called? Custom internal software is usually useless to anyone else because so many business rules are embedded in it, and it's tied so specifically to talking to THIS database on THIS box using THIS method, etc. Now I have some clever code tricks in the application, but nothing that someone else couldn't figure out themselves, and not many that apply to general cases.
What's to stop the binaries from getting distributed? Posted to fuckedcompany or put up on 'my company'-really-sucks.com? Then the source will need to be distributed to all those people.
If he built the application using GPL's components and never discussed it with the client, then there are serious legal issues and this guy's career is probably fucked, unless the company is stone-dead stupid, and what are the odds on that, maybe one in two?
If you give the source to the company, you have "open-sourced" it. The people who have the binaries have the source.
Are you wanting to do more, to put it under a free software license so that if the company redistribute it further they have to bundle the source code with it? Because that's what it sounds like.
"Explain that restricting access to information is immoral"
followed by:
"just post the code online with a copy of the GPL and don't mention it to them."
Wow, you really know how to stick it the the man, right? Take that! Ah ha, now anyone in the world can check your company's inventory. Well, assuming they can connect to the database, which is firewalled off from the outside world.... so yeah, let that code rot in public and go home and pat yourself on the back.
"2) I have to let them give copies (or modifications) away if they want to - but they're hardly going to give copies to their competitors, are they?"
Uh.... yeah they are if they're pissed off at their boss or something stupid like that. And if the pissed off geek gives away a GPL'd piece of software, the original company can do nothing to stop it spreading. While if the pissed off geek gives away a traditionally copyrighted piece of software, the company CAN stop it spreading. See how that might be in the company's interest? The only way I can see a company being interested in allowing a piece of custom software to be GPL'd is if it can be built from GPL pieces in 1/8 the time at 1/8 the cost of having it written from scratch, and then only if it's the kind of thing that the rest of the world wouldnt' be able to use anyone, internal accounting or fulfillment or something.
Sure, like your client's competitors.
Sure, like your client's competitors.
Sure, like your client's competitors.
Intellectual property laws exist precisely to protect the investment your client makes in paying you to spend your time developing a solution for them that is of value to them. If they/you release the source code resulting from your efforts to anyone interested, your client's competitors can immediately benefit as well, and your client's investment pays a much smaller return. This is not good business, any way you dress it up.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
That's why nobody else will ever touch this 'open source' code. The competitor will be more likely to write their own proprietary software. If you run Oracle and your competitor runs SQL Server, the amount of effort that would be required to re-tool the application would exceed the amount of effort to write an app with the same functionality, but based around SQL Server, from scratch.
Open source makes sense for generic pieces that provide a big chunk of functionality, not for an inventory management application running on one specific database.
But hang on a minute... Isn't the gpl-faq just one interpretation of the GPL anyway? And isn't the GPL itself just a licence agreement, no more tested in court than any other?
If I were contracting out some development work, and the result wasn't intended to be openly available, I wouldn't even consider letting the contractors use GPL source anywhere. It's just a legal minefield waiting to sink my business if I do.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Every point you make also holds if your client is buying the source and IP, not just the resulting binaries and such. Any sane client will want such things under most circumstances. If you are advocating the GPL on the basis that it confers extra advantages beyond this, what are they? If you are advocating the GPL purely on the basis of these advantages, you are misleading your client.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Everything open source costs money. RedHat, Mandrake, and Suse aren't volunteer organizations.
If the client wants a project built to their specifications they have to pay for it. If open source is acceptable to them they can pay me what it costs to take an open source project and tailor it to their needs.
Project from scratch: $100,000
Project from open-source with customization: $25,000
I still get paid for the work I do but in the 2nd case the customer gets a much better deal and I make a much better impression for creating a better working product at a lower cost.
(We recently had a customer select the first option because they wanted the product built from scratch and they wanted full rights to it. That's OK too. We'll take the money.)
Coding Blog
Part of the big advantage to Open Source consulting is that your clients are benefitting from those who have gone before you. Now it's their turn to pitch in. The other option is much more expensive for them: go proprietary and start over from scratch rather than standing upon the shoulders of giants, or so the saying goes. This example also illustrates one of the beauties of GPL over BSD--it forces cooperation so that clients can't own improvements to the codebase.
Of course I think the real answer to this is much simpler stated: provide solutions, not software! ex.) "I will take whatever steps necessary to set up your computers to perform x, y, and z to your specification for a total cost of $n." Then it's up to you how to meet those specifications, be it free or proprietary software.
It's not about being 'scum' it's about doing business.
Unless the client starts out clearly stating that he expects to own the source you produce you don't have to roll over and get screwed (Why should you? Software is *expensive* to develop and small companies simply can't afford to pay for the rights to have software build exlusively for them, the development of sophisticated packages costs tens of thousands.)
I'm not advocating misleading people, if they are paying you many thousands of USD or UKP then one would expect they want the source, but don't think for one minute that you won't get screwed if they can do it legally.
It's not a tea party and your clients are not always your friends and companies arn't pulling punches, it's business. MOST companies are happy to screw you when it comes to paying your fee (as most contractors can testify to).
If they have a problem, say the software doesn't do something they expect it do, but they never explicitly asked for it, they will quite happly withold part of, or your entire fee. Or sue you if they think they can (even if only to get out of paying you). They are justing being smart and doing business, it's what capitalism is about.
It's very often NOT in his best interest to pay you to develop software that he then exlusively owns. That may cost him 20,000 UKP or more, when you can do it it for about 5,000 but you retain the rights.
To hand over the rights to the source of a non trivial app when you don't have to and just because they can't afford it makes you a fool. Giving the companies full rights to your work on the cheap just because they can't afford it and you feel sorry for them is bad business and certainly harms you (as a developer) and in the long run may very well harm the company you did the work for too (as you would always have to write *everything* you do from scratch, which would take much longer for you to do and so would cost them much more).
Why lower the cost? Just keep the fact that you have all this code a secret and claim massive fees from your "extensive knowledge and experience".
Welcome to slashdot, Mr Jackson. We're humbled that you chose to visit our little corner of the Internet.
CmdrTaco will be sending you the check very shortly.
Don't anthropomorphize computers, they don't like it.