If you have written an HMI app in VB, let's say, and the end user accepts the final application, does he own the source code??

If the customer wants the source code would it be a chargeable thing? Any thoughts on the pricing structures??

Thx in advance all.

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesign.com
Manufacturing Automation www[.]automationmag.com

 

Surely it would depend on if he paid you to development it. If you worked on it your own time he only has the right to use it on the one application you sold him.

What did he hire you to do?

Roy

 

We have not done a system to date where we have not supplied the source code to the end user. That does not mean he owns it.

 

It depends. I would say that if it is custom software you wrote for them, at their direction, they should own it or you should negotiate ownership. If it's pre-existing and being sold to others as well, you might quote a price to own source.

I personally think you should also consider either dual licensing or GPL licensing. Unless it's something that can be sold several times, it makes absolutely no difference monetarily as 99% of the world's software is not written for sale and would be better shared than locked away until forgotten.

When I write software for a customer that would be of general interest, I ask if I can release it under GPL. For some reason, this doesn't fly very often and I can't see why. Unless it embodies know-how or trade secrets, it wouldn't make any difference for their use if I published it. But, I do think people have an expectation that they should own works that they commission.

Regards
cww

 

It could go either way, depending on the terms of the contract. The safest thing to do is to specify up front in your quote whether or not the client will have the rights to the source code.

Robert Scott
Real-Time Specialties
Embedded Systems Consulting

 

I think unless the customer explicitly requests source code, then it belongs to the programmer.  There is much more involved than the time to write the code, the software involves years of the programmers experience and quite possibly also uses software routines that they have previously written. 

I think if sourcecode is to be delivered, then the programmer should charge more.  How much more?  I don't know.  Most programmers, IMO, don't really get paid enough for their actual time.  I chalk up many hours to R&D or education.  This enhances my value as a programmer and is worth my while in the long run, but most customers won't be willing to pay for that.  In my experience, they expect that you know just what to do.

There are, of course, many exceptions.  If you are using existing code and/or processes from the customer and adding code to their product, then of course they should get the source.  There are issues of programmers "disappearing from the face of the earth" and the source code is lost. 

The programmer can use the source as a revenue stream for future software maintenance.  It can also be a potential liability and the programmer may prefer thast the company has the source and doesn't have to contact the programmer for every little issue.

This a big topic and I expect a long and healthy thread has been started   I don't even want to get started on "open source", although it does have it's place in our world.

Bill

 

My opinion is that this is a negotiable item. It should be covered off in the functional design.

On the other hand I find it un-scrupulous to "hide" this detail from the customer (unless it contains some proprietary code on the developers part) and usually will lead to this being your last job if you try to "own" the logic built for them.

Bring it up and charge approprietly so that the "air" and repeat business are kept intact. This is the "ethical" thing to fo in my opinion.

Dave Ferguson

 

>If you have written an HMI app in VB,
>let's say, and the end user accepts the
>final application, does he own the
>source code??

That depends. If nothing is stated in the contract, then I would say possession is 9/10ths of the law. In other words, if you've left (or deliberately sent) a copy it's his. If you haven't, he probably has no recourse.

Note that I'm not a lawyer, and I'm not giving legal advice.

Moral of the story: the "ownership" of the source code should be in the contract.


>If the customer wants the source code
>would it be a chargeable thing?

Absolutely it can be a chargeable item. Again, this should be up-front in the contract.


>Any thoughts on the pricing structures??

Not any HELPFUL thoughts. Picking a random number like ten times the cost of the app is fun, but doesn't really have a basis in reality. How important is it to the customer? How important is it to your business? My company throws it in for free. Not because we're charitable, but because it's a business decision. We do business with very large companies, and giving them the code is a way of convincing them to do business with a 100-man outfit in South-East Texas. On the other hand, if software sales is your primary revenue you can't afford to give away the farm.

How much is the code really worth, anyway? We don't care if our customers copy our code, because it really won't do them any good. It's all one-off stuff. If you sell a "traditional" application like Word, then you really don't want to let that code go. Sounds to me like your application is more on the "one-off" side.

What's the customer's expectation? Will he ever do business with you again if you don't give him the code? Is he expecting a number like $47,983,214.00, or is he expecting $19.99?

Part of the problem here is that you've asked is a business question, and it's roughly equivalent to "How do I control a conveyor system?" There's just not enough data to give a real anwers.

-James Ingraham
Sage Automation, Inc.

 

My guess is that it will depend on the negociation and the terms of your contract. If you are a believer of open source and free software then you may choose to offer the source code as part of your delivery and charge only the service related to this software. This way you may offer no warranty at all since you do not control any modification that the customer or other third party may have done on the code.

On the contrary if you decide to go with the propietary software scheme, you then must tell your customer in advance that you own the intellectual property of what you have developed and in turn you are offering warranty and perhaps maintenance of such code for the future.

Pricing policy will vary greatly depending on many issues of course. Open source is a service centered business, closed source is licensed centered.

 

It really depends on what the contract, PO, or agreement says. If the issue isn't addressed, then the creator of the work owns the code.

Now, if I work for you as an employee, then the most likely interpretation by the courts if we get into a battle is that the employer owns the work, since it was work for hire. The employee works at the direction of and under the control of the employer, not independently. So the employer "creates" the work.

If I work for you as an independent contractor, then it's probably mine, but that's easy to defeat if you have lot of money for an army of lawyers and I have a mortgage to keep paying. In theory, if you aren't directing my activities then I am my own boss, and my work is mine. It all goes back to the concepts of property rights and the definitions of labor probably best explained by Locke in the "Second Treatise of Government" just before the English revolution. It sounds wonderful and flowery, but as I said, if you have a few hundred thousand for lawyers and I have a mortgage payment due on the first of the month, you win. In the western courts, might makes right more often than not.

What I normally do is look at it with these common sense rules. First, I have almost never been able to take much from an HMI from one plant and utilize it in another plant, so even if it is "mine" what good does it do me to tick off the customer by playing hard ball. If I've already ticked him off to the point that he wants the code to let someone else works on it, then I've probably lost the customer anyway, so I may as well give it to him unless I'm sure he's got a way to sell it, thereby screwing me out of my work. While I'd love to make a dozen of the same system once in my life, I don't see it happening this year.

My standard letter for quoting states explicitly that I will retain ownership of any novel and innovative solutions developed for the job, and that in the event such developments are present in the final product the pieces that are proprietary will be clearly identified. I have yet to see anyone's PO standard terms that nullifiers that explicit a statement in the proposal letter, but I'm certain some lawyer somewhere will come up with one eventually. After all, it's the PO's "standard terms" job to be restrictive enough to protect the purchasing company from harm. (In reality, if I do come up with anythign that whizbang I'll stick it in a library and call the function, only providing a compiled version in the distribution package. It's only happened once, frankly , and much to my disappointment it never turned out to be as reusable as I originally thought. Ergo, I wasted the time making the library and never recovered a cent on it. I guess maybe it wasn't as great an idea as I thought it was.)

MB

--
Michael Batchelor
www.IndustrialInformatics.com

Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418

843-329-0342 x111 Voice
843-329-0343 FAX

 

In most countries that are signatories of the Berne Copyright Convention, the author of a work holds the copyright in it unless it was done as a work for hire.

To put it simply, if company A hires company B to produce a piece of software, then company B automatically holds the copyright in that software unless the contract was explicitly worded to state that copyright was vested in A. Regardless of the contract, it may (depending upon the circumstances) still require a written copyright assignment for copyright to transfer from B to A. Consult a copyright lawyer if this really matters.

If however company A hired employee C, and employee C wrote the software as part of their normal duties, then company A would automatically hold the copyright in the software. This is a simple "work for hire" relationship. If you are a temporary consultant working in company A's office and being paid by the hour, then this would probably still be considered as a "work for hire". If you are in a grey area somewhere in between an employee and an independent company - then it gets tricky.

So the answer to your first question is, it depends upon the contract and the details of the relationship between the author and the "end user".

As to your second question, what did the customer expect going into the contract? Why *wouldn't* you give them the source code? Are you expecting a royalty from further copies? Are you trying to lock in any future business from updates to the software? Do you just want the right to sell copies of the same program or derivatives of it to other parties? How valuable is this piece of software? What are your objectives? Are they going to tell you where to stick your software and also tell you to not set foot inside their door again?

If this thing is going where it sounds like it's going, then you will need to draw up a software license agreement with your customer. You'll then have to face the fact that since you aren't a copyright lawyer, the license probably won't stand up in court. And if you're not willing to go to court over some VB MMI program that you cranked out for someone, then what is its value to you?

 

Yes, I think agreement is the important point. I hear of far more damage from customers having only one source for support than from programmers whose customers have hijacked their source. It should IMHO, be a mandatory point of agreement before work begins.

And since I personally undergo a great deal of grief trying to repair black boxes with no source, when minutes with the programming tools would save days of downtime, I have to side with the customers on this one. The real world problem is not that we want to cut the vendor out of the picture. it's that they tend to be available when they d*mn well please and I still have to fix it in the meantime.

With downtime in the thousands of dollars an hour, it's untenable to be without the means to diagnose the problem. The vendors lose far more revenue to their tardiness than to my having the tools needed for minimum mttr. I have completely taken over some systems out of absolute necessity, having them down means everybody goes home.

Regards
cww

 

As the end user of software that was written for a variety of applications by different suppliers for a wide variety of power plant equipment, I can say that we're nuts to not have the original source code for all DDC equipment. To me it's a basic maintenance troubleshooting tool that I can't do without. And I've seen too many system integrators go belly up, leaving us holding the bag.

I don't mean to imply that it should be free. To me, there's no difference between paying a programmer for his time vs. paying me or an auto mechanic to fix something. But to avoid future conflicts, this issue should be addressed up front.

It doesn't matter to me if we "own" the code or not, as long as I am licensed to use it and modify it as the need arises. If we owned the software we could sell it, which is of no interest to us. We sell power, not software.

Although our purchase specs often don't address the issue, in almost all cases our equipment vendors have quickly emailed me the code when I needed it, even on fairly sensitive applications like duct burner management. (Thank you, Forney.)

However, I did run across an English made lube oil vacuum degassifier skid that was having problems. The PLC was password protected and we didn't even have a printout of the ladder logic, and the reps in the US knew nothing about the thing. The supplier would not even sell us the source code or give us the PLC password. All we had was a sequence of operation.

Were they worried that an electric utility was going to into the business of cloning their equipment or sell their precious code on Ebay? It's hard to understand where they're coming from.

After weeks of emails and phone calls and a rather pitiful email I wrote them that apparently tugged on their Kevlar heart strings, they finally gave us a hand held device that provided us access to tunable parameters, but no source code, not even a printout, and no password.

I will do everything I can to keep us from ever purchasing another product from this vendor.

 

In reply to Curt Wuollet: There's two ways of looking at this whole problem. One is the "practical" angle, which is what most of us look at. This is where we more or less ignore the whole issue, get the job done, and hope it never becomes a problem. I will admit that the "head in the sand" approach seems to have worked pretty good for me so far.

The other angle is the "legalistic" angle, which is where the whole thing becomes kind of messy. If you are doing a project for someone, do you sit down and start from a completely clean slate and type every line fresh and unique from your fertile imagination, or do you copy and paste code in from other projects where you did something similar? I don't mean just linking in a library. I mean intermixing old code with new code. This code is scattered throughout the project, not isolated into a few well defined libraries. Most people are doing the latter.

So now you've copied code from projects 'A', 'B', and 'C' into project 'D'. Who owns the copyright on what? How do you transfer copyright to someone when you've already done this on the same blocks of code for someone else? The customer is not unreasonable in expecting source code (try writing a PLC program for someone, and then tell them they don't get a copy of the PLC program). But how do you do this while still re-using code from previous projects?

From a legalistic standpoint, the most practical solution would seem to be to retain copyright and grant the customer a license to the source code. Put a GPL, LGPL, or BSD license on the project as a whole or on portions of it. The customer then has no practical restrictions on maintaining or copying the software while you don't have to worry about the legalities of reusing portions of the same code over again. I will admit that I haven't tried this (having practised the ostrich solution to the problem so far).

I think the problem you may have had with this in the past is that you posed the question to the customer as being something "extra" that they don't really need to do. If the point was rephrased as this is normal and necessary because they are getting tested and proven code that was previously created and used in multiple projects for other customers, it becomes more understandable.

Putting a GPL license on something doesn't mean putting a copy of it up on SourceForge. It probably wouldn't be much use to anyone outside of the original customer else even if you did. The GPL, LGPL, and BSD licenses however are widely used licenses that are intended to protect the interests of both the recipient and the author (GPL more so than BSD). I don't recommend that anyone try writing their own custom software license, as none of use are lawyers and we'd probably just botch it. It's better to just go with an existing proven license which is meant for this purpose.

The above refers to one off custom projects that are of no interest to anyone outside of the customer they were created for. That probably covers 99% of what most of us would ever deal with though.

 

Hi Michael,

> In reply to Curt Wuollet: There's two ways of looking at this whole problem.
> One is the "practical" angle, which is what most of us look at. This is where
> we more or less ignore the whole issue, get the job done, and hope it never
> becomes a problem. I will admit that the "head in the sand" approach seems to
> have worked pretty good for me so far.
>
> The other angle is the "legalistic" angle, which is where the whole thing
> becomes kind of messy. If you are doing a project for someone, do you sit
> down and start from a completely clean slate and type every line fresh and
> unique from your fertile imagination, or do you copy and paste code in from
> other projects where you did something similar? I don't mean just linking in
> a library. I mean intermixing old code with new code. This code is scattered
> throughout the project, not isolated into a few well defined libraries. Most
> people are doing the latter.
>
> So now you've copied code from projects 'A', 'B', and 'C' into project 'D'.
> Who owns the copyright on what? How do you transfer copyright to someone when
> you've already done this on the same blocks of code for someone else? The
> customer is not unreasonable in expecting source code (try writing a PLC
> program for someone, and then tell them they don't get a copy of the PLC
> program). But how do you do this while still re-using code from previous
> projects? <

I wish that were the case. Our management refuses to take that into account and continues to buy from vendors who won't provide the source, even I've fixed several problems that either had the builders stumped, or was something they simply weren't interested in fixing for us. The objects in question were conveyor systems and paper stackers where I fail to see any trade secrets or other rational reason for being so uptight.

> From a legalistic standpoint, the most practical solution would seem to be to
> retain copyright and grant the customer a license to the source code. Put a
> GPL, LGPL, or BSD license on the project as a whole or on portions of it. The
> customer then has no practical restrictions on maintaining or copying the
> software while you don't have to worry about the legalities of reusing
> portions of the same code over again. I will admit that I haven't tried this
> (having practised the ostrich solution to the problem so far).
>
> I think the problem you may have had with this in the past is that you posed
> the question to the customer as being something "extra" that they don't
> really need to do. If the point was rephrased as this is normal and necessary
> because they are getting tested and proven code that was previously created
> and used in multiple projects for other customers, it becomes more
> understandable.
>
> Putting a GPL license on something doesn't mean putting a copy of it up on
> SourceForge. It probably wouldn't be much use to anyone outside of the
> original customer else even if you did. The GPL, LGPL, and BSD licenses
> however are widely used licenses that are intended to protect the interests
> of both the recipient and the author (GPL more so than BSD). I don't
> recommend that anyone try writing their own custom software license, as none
> of use are lawyers and we'd probably just botch it. It's better to just go
> with an existing proven license which is meant for this purpose.
>
>
> The above refers to one off custom projects that are of no interest to anyone
> outside of the customer they were created for. That probably covers 99% of
> what most of us would ever deal with though. <

That's why the ostrich approach mostly works. I doubt that you could find anybody interested in most stuff if you were to steal it. But some vendors are rather dogmatic about IP. The difference on the maintenance end can be dramatic. Like 90% less time to diagnose a problem when you can see what term is missing.

Regards

cww

 

That assumes that the end user has someone who can understand the system and the source code. I find that they frequently do not, at least on PC based systems written in VB or C.