As a consultant, your primary goal should be the well-being of your client. Not criticism, it's just hard sometimes to remember that amoung everything else that you're doing.
As such, recommendations you make on licensing should work in their favor. So, first up, dismiss your "beliefs". This isn't about your beliefs, it's about your clients beliefs. If they believe, well and good. If they don't, put this one on the sideboard. Secondary, contributions etc is a tricky one. It has to satisfy a few points before this is worth trying for: 1. The client has limited resources with which to hire people to make improvements themselves. If they have large resources to spend, they are unlikely to see any compelling benefit from the majority of potential contributions vs what they could achieve simply by hiring people. 2. The software in question would be valuable to others who are also likely to respect the open source methods (Remember, a web application only needs to have the changes made available if they redistribute it, if they just run it on their server, you'll never see their work) 3. Self re-use. Dismiss this *immediately*. If you did not negotiate up-front to be able to re-use code from the project as part of the contract, give it up. It is not in your clients best interest. There is a gray area when it comes to generic routines or library functions, I strongly recommend advising clients at the start that they will recieve the benefits of your library of code, with the quid-pro-quo that any improvements to that library remain yours, with an unrestricted license passed to the client. You may need a lawyer to sort this out depending on your juristiction. 4. GPL compatibility. This is probably your main compelling argument. A business case can be made for this, by finding the appropriate projects you would build on, and providing solid estimates for how much money would be saved. An appropriate way to do this is to compare the GPL project, a bespoke development by you (estimated), and at least one commercial equivalent. Your problem is basically that you're approaching it too late in the day, things sound like they have already been agreed to one extent or another. Certainly if any money has changed hands, you want to focus on doing the best for the client, and comfort yourself by being sure that you'll do better next time. The belief issue is a complex one, because those of us who use open source projects and benefit from them (such as turbogears) like to feel that we could give something back. The way my company deals with it is that we offer a 20% discount on your custom development if it will be released under an appropriate open source license. Nobody has taken us up on this yet in 5 years of business, which is probably an indicator of just how much most clients want to "own" something at the end of the process more than anything. In the end, if you focus on doing what's best for the client, you will create a better product and you will earn their trust. Time will go by, you will probably do more projects for them, and in the future they will listen to your considerations more, and you will understand them better. As a result, when they do decide to go with open source as an option, it will be because it will benefit them either financially or personally, and not because they were tricked or forced into it. This is the best place to be. Your clients are the lifeblood of your business. We all have additional ethics to work with, it's not just "what client says goes", but its "the best interests of your client" which is the critical phrase. Plan for the long term, set up incentives to help your clients follow what you believe is te right way to do things, and be ready to refuse work when you see a mis-match in what you believe is right and what the client may demand of you. But be up-front about it, don't try and manipulate or trick people into things, and don't try and change direction in the middle of a project. If you commit to something, deliver. If you absolutely cannot do it (for whatever reason), be up- front and honest with the client as early as possible so that you do the least damage to them possible. At the last, remember, a decision to close source today, can change to a decision to open source tomorrow. Licenses are not set in stone, and people can change their minds later (and indeed, are much more inclined to if they believe they've covered their development costs at some point). On Mar 8, 8:01 am, "kuom" <[EMAIL PROTECTED]> wrote: > First, apologies. I know this is not a TurboGears discussion, it is > really more about open source software licensing. I am just figure > people who hang out at the TurboGears group should have more > experience in this area, and may be willing to answer my question... > > I am an independent consultant (new at this), and I am building a web > site for a client using TurboGears. The issue at hand here is, the > client feels that since he is paying for the code, he should own it. > I am trying to convince him to use some sort of Open Source License > (GPL, MIT, etc.), mainly for these reasons: > > 1) I am a believer of Open Source (okay, so there is no business case > for this one) > 2) Client will get contribution back if others use the same code base > and made improvements > 3) I can re-use some code for future projects to save myself time > 4) If I picked the correct license, I can build on other existing > projects (GPL compatibility) > > Obviously, some of these may not apply, depending on the license we > pick. > > The web site is just a generic insurance quote site. > > Instinctively, I want to go with GPLv2, but there is a possibility > that this site may end up using some closed-source extensions or plug- > in... then in which case I guess I am better off with MIT... > > I have not had much experience in developing software for clients as > an independent contractor, so I want to hear what others have to say > about this... > > TIA. > > -Josh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
