I have never thought of the code I wrote for customers was ever anyones but the paying client.
You should look into copyright law a little more closely then. Copyright is personal property. You have to agree to transfer the copyright of all your work, it doesn't just happen as a matter of course because money changed hands.
Paul
You should look into copyright law a little more closely then. Copyright is personal property.
Yes but who's. If you work for a company and you write code all day long the code you write does not belong to you but your employer. Likewise code written specifically for a contracted customer technically belongs to that customer. I think you would have a hard time fighting a customer in court over the release of code written specifically for them unless the contract they sign specifically says the code will not be released to them under any circimstances. Otherwise I would think they have an implied right to access the code specific to their job if they desired to do so. Most resi jobs simply don't. Commercial and institutional ususally do.
To me the grey area is the code that is not specific to a customer's job namely our module libraries which are not written for a particular customer but merely inlcluded to faciltate operation of specific piece of equipment. If they are only being charged for the modules use then they only have the rights to its use and not the source.
Many of the laws for songwriters follow programming.
If you work for a company - the code belongs to the company end of story.
If you worked for Thomas Edison at Menlo Park and invented something, Mr. Edison got the credit and owned it... like wax paper, among many other things.
Many of the songwriters from the early days got screwed out of all their royalties for this reason. The laws have changed for songwriters but not programmers. I believe Mr. Gates had something to do with this.
If you work for yourself or own the company you own the code. UNLESS you sign an agreement that gives them the rights.
You should look into copyright law a little more closely then. Copyright is personal property. You have to agree to transfer the copyright of all your work, it doesn't just happen as a matter of course because money changed hands.
Paul
If the money changing hands was a salary or an hourly wage for a job where your job is writing code, then it's considered work for hire. If a contract was signed stating a payment for services and product(s) then it's a work for hire.
If you sold the software wholesale or retail which would then it's considered the creator's property.
Work for hire is not copyright the code creator. Wholesale or retail sale of a hunk of code is copyright the code writer.
If you work for a company - the code belongs to the company end of story.
It is not quite that clear cut. There are many cases where a programmer keeps the copyright. It depends on the job description, employee agreement, where you work, and other factors. Only if the work is 'work for hire' and was created in the 'course of that employment' does the company retain copyright. If you are an AMX programmer working for an integration company and write a program that automates accounting procedures at the company relieving the accountants of hours of tedious work, you most likely own the copyright to that work. The company gets 'shop use' of it, but cannot sell or copy it without your permission in most cases.
Using the assumption that the client owns the copyright of all the code, if you used a module that was sold to a client, and then sold it again to the next client, you are selling something you don't own, since the first client owns the copyright. Talk about financial suicide!
If you worked for Thomas Edison at Menlo Park and invented something, Mr. Edison got the credit and owned it... like wax paper, among many other things.
Patents are different than copyrights. It sounds like you are confusing the two.
If your work is 'work for hire' and the code that was created fits under your job description and work environment then it belongs to the company, and you cannot hand the code over to a client without the companies permission.
In none of these scenarios does the client get implicit right to the code (as opposed to an implicit right to use the code), so I am not sure where people get the idea that since the client paid a fee to have software provided to them to use that they have copyright of the code. I cannot find any legal reason that this would be so.
Paul
In that link it says this about a ruling made by the Supreme Court:
Comment: CCNV was a major legal victory for independent contractors. It stands for the proposition that creators who produce work at the instance and expense of a third party do not necessarily give up their copyrights in the process. For hiring parties, it stands for the proposition that just because you paid for it, doesn't mean you own the copyright.
I'm not going to get into an argument about what is or is not "work for hire" with a bunch of Netlinx programmers. It would be like getting into an argument about nuclear physics with a bunch of economists. What I do want to address is this odd (so it seems to me) preoccupation with intellectual property rights for stuff that doesn't have much value outside of the system it was written for.
I've never written any Netlinx code the functionality of which couldn't be duplicated by any reasonably competent Netlinx programmer and I've never seen any Netlinx code the functionality of which I couldn't easily duplicate. I've never seen any trade secrets in Netlinx code and I can't even imagine what a trade secret would look like in Netlinx code.
I suppose there might be an equipment maker somewhere who has invented a unique method of calculating a checksum and wants to keep it secret for some reason, but I can't imagine that the secret would have much value outside of the context of that equipment. Same thing with Netlinx code in general. Surely there is not a thriving black market for bootleg Netlinx code, is there? Is anyone afraid that someone else will steal their method of turning a Sharp projector on and off and make themselves rich in the process?
Yeah, some code is better than other code and a clever programmer can get stuff to work better and more reliably than a programmer who is not quite as clever. But, I think, what makes one Netlinx program superior to another that controls the same equipment is not, in my understanding (and, unlike some, I make no pretense of being a lawyer), covered by copyright. You can't copyright an idea, you can't copyright (as I understand it) a programming notion.
So, what I am getting at is when the supplier of the program (programmer, integrator, whatever) restricts the ability of the people buying the system to make modifications to the program, arguing that the code for the system is not work for hire (even though it looks a lot like work for hire to me) it doesn't appear to me that much intellectual property value is being preserved other than forcing the buyer to come back if changes become necessary.
We work almost exclusively for corporate and government clients and I rarely come upon a situation where there is a system installed by someone else and access to the code is restricted. But, there are a lot of times when the code is not on the system and the customer has to try to figure out if they have it or whether they can get it from the original contractor. It's just a pain in the butt for everyone when the code's not on the master.
Had one this past week where the client was replacing one model of Samsung document camera with another -- also a Barco projector with a Sanyo. Easy change if the code is available. If there's no code, the easiest and cheapest thing would be to throw an NI700 in there and steal button presses via M2M. What a waste.
We always leave the code on the master, if possible. If they want to go hire a guy living under a bridge to make some modificatiions down the line, more power to them.
We always leave the code on the master, if possible. If they want to go hire a guy living under a bridge to make some modificatiions down the line, more power to them.
Do you warranty your work/code? If so, and someone else has modified it without your knowledge, causing damage (accidentally heating a vintage wine cellar for example) how is that sorted out?
Paul
Question A Riot Surely you can tell if its modified. Doesnt it get downloaded with a date stamp. So if someone else modifies a system you can always tell? Am I wrong?
Question A Riot Surely you can tell if its modified. Doesnt it get downloaded with a date stamp. So if someone else modifies a system you can always tell? Am I wrong?
No, you're not wrong, you're right.
As far as providing a warranty with my code, the answer, I suppose, is yes. The dealer that I contract to doesn't get paid until the customer accepts the system and I don't get paid until the dealer gets paid. Then, if it turns out that there's something that I screwed up, sure, I'll fix it on my dime. Sometimes when a problem develops that isn't caused by the code I'll end up helping the dealer fix it. I expect that on a decent job that I can afford to commit some time to customer service after the job -- no big deal.
As far as responsibility for damages caused by something the customer hires to be done -- or the customer does -- that would be like General Motors providing warranty service for an after market stereo or something. The wine cellar? Owner calls his insurance agent.
Question A Riot Surely you can tell if its modified. Doesnt it get downloaded with a date stamp. So if someone else modifies a system you can always tell? Am I wrong?
No, you cannot conclude if someone modified the system and when just from timestamps, assuming that someone has Netlinx administrator rights.
I change date on Netlinx controller back to time just BEFORE you left the job, modify all timestamps on my PC for Netlinx files as well - pretending the code I am uploading is yours... Then change controller's date back to normal, wiping out the log...
And, you know, heating a vintage wine cellar is what YOU exactly did, everyone may conclude that from YOUR code...
Well, I guess any contractor is danger of being defrauded by unscrupulous clients, but leaving the code on the master, as far as I can tell, doesn't significantly increase the danger nor does it create extra liability for consequential damages, as far as I know.
As far as responsibility for damages caused by something the customer hires to be done -- or the customer does -- that would be like General Motors providing warranty service for an after market stereo or something. The wine cellar? Owner calls his insurance agent.
Sorry, have to disagree. If damage is caused by buggy Netlinx code written by an AMX programmer... I think it is clear here who is taking responsibility for the damage - he who signed the contract with the customer (that would be either your company or yourself).
Ok, I tried to ask this question much earlier in this thread but got no replies so I'll try this again.
Lets say your code includes several modules w/ only .tko's for comms and possibly other modules that for some reason you only inlcude the .tko file in the workspace (you don't inlcude the.axs) and the rest of the code in the work space is your typical .axi & .axs files.
You compile and send to the master w/ the source code. Now I've only tried this once the other day to retrieve the source and I assumed I would get a zip file of my workspace but only received the .axi & .axs files. No .irl. .docs, .tko's, etc.
So is there a way to pull out the .tko files that were part of the overall compiling or not? If not what good is the ability to store the source code on the master in this instance since you can not rebuild the workspace and send it back to the master since this reconstructed workspace doesn't have access to the various .tko files that were in the original build. So the ability to modify the code that you do have access to is meaningless since you can't really send it back to the master and expect things to work as they did before since parts (.tko files) are missing.
Is this actually the case or am i missing something? Can you pull the .tko files off the master or are they just in the compiled code and therefore un-extractable?
...only received the .axi & .axs files. No .irl. .docs, .tko's, etc.
I recently retrieved the Netlinx Source Code File using Netlinx Studio. I got the Master AXS, the Master TKO, the Master .SRC, the Netlinx.axi, and an additional .axi.
Vining you are correct, recompiling would not work because there were numerous modules that were not retrieved (didn't matter for this project).
If someone were to pull the flash card and read that directly I don't know exactly what you'd be able to get, but I assume it wouldn't be any more useful that what you get retrieving via Studio.
And there are no options in the Retrieve dialog to get "Netlinx Compiled TKO file"....
HOWEVER, if the module source code is part of the workspace, and the "send source to master" is enabled, then the code is retrieved -- you DO get an AXS file for each module. So if you roll your own modules and have the AXS as part of your workspace, the project can be extracted and recompiled.
In 2007 I got a reply on that question from AMX tech support that "Unless source code was loaded to the Netlinx master originally, there is no way to retrieve source code or .tkn file from the Netlinx master.". However there are rumors talking about card readers or even ftp... Cannot confirm that, but you have the official words...
So I've been reading theis thread with interest, as I'm working with my lawyer right now to develope a new contract. Of course this argument is the center point of the contract - payment terms are minor compared to the IP issues.
It seems to me that this argument always comes down to the "what if the customer wants to change out a projectr" issue. But as the article that ericmedley listed points out, just because you have a copy of a piece of code doesn't mean you have the rights to use that code. This is true of both the end user, and the original programmer.
I got 3 cd's in the mail this weekend, I physically have a copy of these things, but that doesn't give me the right to copy them and distribute them on the internet.
So if you are leaving your code in the masters, and I usually do unless I know the customer to be a jerk, does that give the end user the right to extract and modify the code? Yeah they have the physical ability, but not necessarily the usage rights to do it. Now that is not going to stop them any more than it has stopped the internet free music services. But if you have the usage rights spelled out in a written contract, signed by both parties, then it might give some people a pause before whoring out your work. And it give you a clear line in the sand to void any warranties included with the system.
To me this has alway been more of a customer relations issue than an intelectual property issue. If your cusomter is not calling you back to change out a projector, then you probaly have done something wrong. There is no way to win back a customer by witholding information.
But I've also been burned by a customer who took all the code and documentation for a room, includeing custom equipment modification documentation, and handed them over to a trunk slammer to rubberstamp out 6 more rooms just like it at half the cost. Now that customer was insistent on good documentation for the project, and was always pushing us to do as good a job as possible as he had 6 more rooms to do. But in hindsite he never intended to hire us to do the additional rooms. Loss of customer - too bad, expierence learned but not forgotten.
The line in the article that I found most interesting, was that a work-for-hire, is not a work-for-hire unless all sides agree to that by signing a contract stating that.
Sorry, have to disagree. If damage is caused by buggy Netlinx code written by an AMX programmer... I think it is clear here who is taking responsibility for the damage - he who signed the contract with the customer (that would be either your company or yourself).
But, if the customer modifies the Netlinx code or if the customer hires somebody else to modify the code, it's not the original AMX programmer who is responsible.
But, if the customer modifies the Netlinx code or if the customer hires somebody else to modify the code, it's not the original AMX programmer who is responsible.
Agree, the same thing applies though. It would be the customer calling insurance or that company/person who made the mistake.
Agree, the same thing applies though. It would be the customer calling insurance or that company/person who made the mistake.
Even if the wine cellar was insured and the insurance company doesn't dispute it and pays for it, it wouldn't make your company look good or be good for its reputation. With some of the wine cellars we have controlled the wine is in the hundreds of thousands of dollars in value, some bottles being irreplaceable. Mistakes just can't happen in those situations.
How would you know if someone changed the code on the master if something bad happens? I don't know if there is a way to tell. If another programmer was hired to change some favs or similar and accidentally created a bug that caused an expensive wine cellar to overheat, it will look like its your fault. I just don't want/need that kind of liability. On a job we did a few years ago, the pre wire team drilled a large hole through a support beam and it needed to be replaced. Insurance didn't pay for it, the company did, and it was well into the 5 figures.
Paul
accidentally created a bug that caused an expensive wine cellar to overheat, it will look like its your fault.
1) Surely you would never have control of parameters outside of your design remit ? ie yes have monitoring of the environment and other variables (say locks etc), but why would you want to put control of a critical system like that into the system in the first place??
2) If it?s that important ? those variables should be fixed within the HVAC system and you would not be able to override ? thereby not your problem to worry about when the good stuff turns sour!
the code is not on the system and the customer has to try to figure out if they have it or whether they can get it from the original contractor. It's just a pain in the butt for everyone when the code's not on the master
Likewise - it happens all the time; basic change - person who dealt with it left - code lost - can't trace original supplier - client gets to pay for it to be written again! They often ask me to check their other systems - just so they know for future... Be honest and leave it on the system.
1) Surely you would never have control of parameters outside of your design remit ? ie yes have monitoring of the environment and other variables (say locks etc), but why would you want to put control of a critical system like that into the system in the first place??
Because the client requested it. Not sure why you wouldn't. Isn't that the point of integration? And don't call me Shirley
2) If it?s that important ? those variables should be fixed within the HVAC system and you would not be able to override ? thereby not your problem to worry about when the good stuff turns sour!
Now you are relying on the HVAC contractor to do their job correctly. I haven't found them to be all that careful or competent. Last time I did a wine cellar the HVAC contractor hadn't set it up correctly and it was 77 degrees in the wine cellar when I got onsite to start the integration.
Nothing dishonest about it, just trying to make sure that no one screws around with a system I built without my knowledge. Personally I think that helps the client because there is only one person responsible rather than a few people all blaming each other which is what inevitably happens when there are too many cooks in the kitchen.
Paul
Now you are relying on the HVAC contractor to do their job correctly. I haven't found them to be all that careful or competent. Last time I did a wine cellar the HVAC contractor hadn't set it up correctly and it was 77 degrees in the wine cellar when I got onsite to start the integration.
But in the context of the issue raised, that would be the HVAC contractors issue legally! If I found something incorrectly / badly setup - I'd flag it up with the client and not touch it with the control system until resolved.
But I've also been burned by a customer who took all the code and documentation for a room, including custom equipment modification documentation, and handed them over to a trunk slammer to rubberstamp out 6 more rooms just like it at half the cost. Now that customer was insistent on good documentation for the project, and was always pushing us to do as good a job as possible as he had 6 more rooms to do. But in hindsite he never intended to hire us to do the additional rooms. Loss of customer - too bad, experence learned but not forgotten.
I have had this happen, but when the system is broken this old chestnut comes out, "the code was like that before - I didn't do it!!" comes into play. When I trot along to a very annoyed client, who now sees me as the enemy, I then have to go into defend mode and show them my original code as a form of defence and try to get them back on-side, most of the times free, to try to maintain some form of client relationship. I'd like to know how you handle this now John?
On the flipside, I have had a situation where I was advised that a fee was charged each year to "maintain the system" but when the account was overdue miraculously the system stopped! I have since rewrote the code - without this timebomb which had done the AMX product a lot of damage so far as the clients opinion went, so I can see where holding code from clients is not good.
I leave my code in there but password protected - not sure how secure this is but hey it may stop the "trunk slammer"
but when the system is broken this old chestnut comes out, "the code was like that before - I didn't do it!!"
Unfortunately, if the client is hell bent on using an alternative contractor, then the relationship is pretty bust already - in my experience when this happens the client is usually sheepish and will eventually admit what has happened & why, and if they've called me back in down the road then its due to the relationship I originally built up, and they are happy to pay for resolution! Maybe I'm just lucky and my clients are more honest than some, maybe it's the commercial / resi split, who knows! I've only lost 1 system to an other, and I didn't mind after 2 years of being called up wanting budget pricing for additional work that never happened, It was no great loss.
The other issue I often find is that the client has a "disc with the code" from the original install, but not any of the subsequent changes over time - and that is a real pain in the behind! It's like smiling death!
As for dead-mans k/o - while it's been tempting, after the event, I'd agree that it just gives the h/w a bad name and you a worse one!
That's why I always leave the box ticked on every compile and only use passwords when the system is exposed on the local network.
I think many of these items are different for resi jobs. We have made it a policy to always load code on jobs. Our relationships with our clients normally are very good when we leave the job. If we have done something to fault them then they have every right to change dealers. On Jim's case about 6 carbon copy rooms that is unfortunate and karma will bite them in the ***...at least you hope. I like the idea of complete transparency. We do have a service agreement, but it doesn't effect the code. It lets us come out and regularly clean (twice a year) look at possible firmware upgrades, any client changes, and keep client contact. If they decide to stop the service agreement I merely take their systems off e-mail notifications from RMS and also delete their e-mail profile for our company (many of our clients like being emailed or emailing their Master). They are paying for service calls, cleanings, and access to our web services.
You should look into copyright law a little more closely then. Copyright is personal property. You have to agree to transfer the copyright of all your work, it doesn't just happen as a matter of course because money changed hands.
Paul
It's built into our contract agreements, you sign it waiving all rights of intellectual property. Don't sign it, don't get the job. We consider it work for hire.
The whole issue for us will be a mute point shortly. Our group has gotten so much grief over the lack of programming ability of our vendors, that we have started a search this week for one single entity for all of our rooms. I'm not going to throw out vendor names, but the majority of them were terrible when it came to programming systems. Quite simply, we rarely got what we paid for, which was usually a lot of money.
Just a remark on all the above. Side note: I am supporting the "DO NOT SHARE" group.
1.If you sell the job as
- Equipment - $xxxxx
- Installation - $xxxxx
- Programming - $xxxxx
I believe it's a normal assumption from the client to understad that the item "Programming" is redeemable and can claim it as he/she pays for it.
2.If you sell the same job as
- Controlled Equipment - $xxxx
- Intelligent Equipment, pre-programmed as per specifications - $xxxxx
- Installation - $xxxxx
probably the common understanding will be that the so-named "pre-programmed intelligent equipment" is a black box which does some specific tasks.
I am not trying to reinvent the wheel, and I am sure this had been the object of study for many lawyers.
All I am saying is that, if I buy a car, for instance, it will be well understood that claiming access or codes to the ECU pre-programmed software will be out of the question, although (without being itemized) I paid for every single bit. Try and request a feature upgrade or a bug fixing...
Comments
You should look into copyright law a little more closely then. Copyright is personal property. You have to agree to transfer the copyright of all your work, it doesn't just happen as a matter of course because money changed hands.
Paul
To me the grey area is the code that is not specific to a customer's job namely our module libraries which are not written for a particular customer but merely inlcluded to faciltate operation of specific piece of equipment. If they are only being charged for the modules use then they only have the rights to its use and not the source.
If you work for a company - the code belongs to the company end of story.
If you worked for Thomas Edison at Menlo Park and invented something, Mr. Edison got the credit and owned it... like wax paper, among many other things.
Many of the songwriters from the early days got screwed out of all their royalties for this reason. The laws have changed for songwriters but not programmers. I believe Mr. Gates had something to do with this.
If you work for yourself or own the company you own the code. UNLESS you sign an agreement that gives them the rights.
If the money changing hands was a salary or an hourly wage for a job where your job is writing code, then it's considered work for hire. If a contract was signed stating a payment for services and product(s) then it's a work for hire.
If you sold the software wholesale or retail which would then it's considered the creator's property.
Work for hire is not copyright the code creator. Wholesale or retail sale of a hunk of code is copyright the code writer.
Here's a fairly good explanation of it.
http://www.copylaw.com/new_articles/wfh.html
It is not quite that clear cut. There are many cases where a programmer keeps the copyright. It depends on the job description, employee agreement, where you work, and other factors. Only if the work is 'work for hire' and was created in the 'course of that employment' does the company retain copyright. If you are an AMX programmer working for an integration company and write a program that automates accounting procedures at the company relieving the accountants of hours of tedious work, you most likely own the copyright to that work. The company gets 'shop use' of it, but cannot sell or copy it without your permission in most cases.
Using the assumption that the client owns the copyright of all the code, if you used a module that was sold to a client, and then sold it again to the next client, you are selling something you don't own, since the first client owns the copyright. Talk about financial suicide!
Patents are different than copyrights. It sounds like you are confusing the two.
If your work is 'work for hire' and the code that was created fits under your job description and work environment then it belongs to the company, and you cannot hand the code over to a client without the companies permission.
In none of these scenarios does the client get implicit right to the code (as opposed to an implicit right to use the code), so I am not sure where people get the idea that since the client paid a fee to have software provided to them to use that they have copyright of the code. I cannot find any legal reason that this would be so.
Paul
In that link it says this about a ruling made by the Supreme Court:
Comment: CCNV was a major legal victory for independent contractors. It stands for the proposition that creators who produce work at the instance and expense of a third party do not necessarily give up their copyrights in the process. For hiring parties, it stands for the proposition that just because you paid for it, doesn't mean you own the copyright.
Paul
I've never written any Netlinx code the functionality of which couldn't be duplicated by any reasonably competent Netlinx programmer and I've never seen any Netlinx code the functionality of which I couldn't easily duplicate. I've never seen any trade secrets in Netlinx code and I can't even imagine what a trade secret would look like in Netlinx code.
I suppose there might be an equipment maker somewhere who has invented a unique method of calculating a checksum and wants to keep it secret for some reason, but I can't imagine that the secret would have much value outside of the context of that equipment. Same thing with Netlinx code in general. Surely there is not a thriving black market for bootleg Netlinx code, is there? Is anyone afraid that someone else will steal their method of turning a Sharp projector on and off and make themselves rich in the process?
Yeah, some code is better than other code and a clever programmer can get stuff to work better and more reliably than a programmer who is not quite as clever. But, I think, what makes one Netlinx program superior to another that controls the same equipment is not, in my understanding (and, unlike some, I make no pretense of being a lawyer), covered by copyright. You can't copyright an idea, you can't copyright (as I understand it) a programming notion.
So, what I am getting at is when the supplier of the program (programmer, integrator, whatever) restricts the ability of the people buying the system to make modifications to the program, arguing that the code for the system is not work for hire (even though it looks a lot like work for hire to me) it doesn't appear to me that much intellectual property value is being preserved other than forcing the buyer to come back if changes become necessary.
We work almost exclusively for corporate and government clients and I rarely come upon a situation where there is a system installed by someone else and access to the code is restricted. But, there are a lot of times when the code is not on the system and the customer has to try to figure out if they have it or whether they can get it from the original contractor. It's just a pain in the butt for everyone when the code's not on the master.
Had one this past week where the client was replacing one model of Samsung document camera with another -- also a Barco projector with a Sanyo. Easy change if the code is available. If there's no code, the easiest and cheapest thing would be to throw an NI700 in there and steal button presses via M2M. What a waste.
We always leave the code on the master, if possible. If they want to go hire a guy living under a bridge to make some modificatiions down the line, more power to them.
Do you warranty your work/code? If so, and someone else has modified it without your knowledge, causing damage (accidentally heating a vintage wine cellar for example) how is that sorted out?
Paul
No, you're not wrong, you're right.
As far as providing a warranty with my code, the answer, I suppose, is yes. The dealer that I contract to doesn't get paid until the customer accepts the system and I don't get paid until the dealer gets paid. Then, if it turns out that there's something that I screwed up, sure, I'll fix it on my dime. Sometimes when a problem develops that isn't caused by the code I'll end up helping the dealer fix it. I expect that on a decent job that I can afford to commit some time to customer service after the job -- no big deal.
As far as responsibility for damages caused by something the customer hires to be done -- or the customer does -- that would be like General Motors providing warranty service for an after market stereo or something. The wine cellar? Owner calls his insurance agent.
No, you cannot conclude if someone modified the system and when just from timestamps, assuming that someone has Netlinx administrator rights.
I change date on Netlinx controller back to time just BEFORE you left the job, modify all timestamps on my PC for Netlinx files as well - pretending the code I am uploading is yours... Then change controller's date back to normal, wiping out the log...
And, you know, heating a vintage wine cellar is what YOU exactly did, everyone may conclude that from YOUR code...
Sorry, have to disagree. If damage is caused by buggy Netlinx code written by an AMX programmer... I think it is clear here who is taking responsibility for the damage - he who signed the contract with the customer (that would be either your company or yourself).
Lets say your code includes several modules w/ only .tko's for comms and possibly other modules that for some reason you only inlcude the .tko file in the workspace (you don't inlcude the.axs) and the rest of the code in the work space is your typical .axi & .axs files.
You compile and send to the master w/ the source code. Now I've only tried this once the other day to retrieve the source and I assumed I would get a zip file of my workspace but only received the .axi & .axs files. No .irl. .docs, .tko's, etc.
So is there a way to pull out the .tko files that were part of the overall compiling or not? If not what good is the ability to store the source code on the master in this instance since you can not rebuild the workspace and send it back to the master since this reconstructed workspace doesn't have access to the various .tko files that were in the original build. So the ability to modify the code that you do have access to is meaningless since you can't really send it back to the master and expect things to work as they did before since parts (.tko files) are missing.
Is this actually the case or am i missing something? Can you pull the .tko files off the master or are they just in the compiled code and therefore un-extractable?
Inquiring minds want to know!
I recently retrieved the Netlinx Source Code File using Netlinx Studio. I got the Master AXS, the Master TKO, the Master .SRC, the Netlinx.axi, and an additional .axi.
Vining you are correct, recompiling would not work because there were numerous modules that were not retrieved (didn't matter for this project).
If someone were to pull the flash card and read that directly I don't know exactly what you'd be able to get, but I assume it wouldn't be any more useful that what you get retrieving via Studio.
HOWEVER, if the module source code is part of the workspace, and the "send source to master" is enabled, then the code is retrieved -- you DO get an AXS file for each module. So if you roll your own modules and have the AXS as part of your workspace, the project can be extracted and recompiled.
In 2007 I got a reply on that question from AMX tech support that "Unless source code was loaded to the Netlinx master originally, there is no way to retrieve source code or .tkn file from the Netlinx master.". However there are rumors talking about card readers or even ftp... Cannot confirm that, but you have the official words...
It seems to me that this argument always comes down to the "what if the customer wants to change out a projectr" issue. But as the article that ericmedley listed points out, just because you have a copy of a piece of code doesn't mean you have the rights to use that code. This is true of both the end user, and the original programmer.
I got 3 cd's in the mail this weekend, I physically have a copy of these things, but that doesn't give me the right to copy them and distribute them on the internet.
So if you are leaving your code in the masters, and I usually do unless I know the customer to be a jerk, does that give the end user the right to extract and modify the code? Yeah they have the physical ability, but not necessarily the usage rights to do it. Now that is not going to stop them any more than it has stopped the internet free music services. But if you have the usage rights spelled out in a written contract, signed by both parties, then it might give some people a pause before whoring out your work. And it give you a clear line in the sand to void any warranties included with the system.
To me this has alway been more of a customer relations issue than an intelectual property issue. If your cusomter is not calling you back to change out a projector, then you probaly have done something wrong. There is no way to win back a customer by witholding information.
But I've also been burned by a customer who took all the code and documentation for a room, includeing custom equipment modification documentation, and handed them over to a trunk slammer to rubberstamp out 6 more rooms just like it at half the cost. Now that customer was insistent on good documentation for the project, and was always pushing us to do as good a job as possible as he had 6 more rooms to do. But in hindsite he never intended to hire us to do the additional rooms. Loss of customer - too bad, expierence learned but not forgotten.
The line in the article that I found most interesting, was that a work-for-hire, is not a work-for-hire unless all sides agree to that by signing a contract stating that.
But, if the customer modifies the Netlinx code or if the customer hires somebody else to modify the code, it's not the original AMX programmer who is responsible.
Agree, the same thing applies though. It would be the customer calling insurance or that company/person who made the mistake.
Even if the wine cellar was insured and the insurance company doesn't dispute it and pays for it, it wouldn't make your company look good or be good for its reputation. With some of the wine cellars we have controlled the wine is in the hundreds of thousands of dollars in value, some bottles being irreplaceable. Mistakes just can't happen in those situations.
How would you know if someone changed the code on the master if something bad happens? I don't know if there is a way to tell. If another programmer was hired to change some favs or similar and accidentally created a bug that caused an expensive wine cellar to overheat, it will look like its your fault. I just don't want/need that kind of liability. On a job we did a few years ago, the pre wire team drilled a large hole through a support beam and it needed to be replaced. Insurance didn't pay for it, the company did, and it was well into the 5 figures.
Paul
1) Surely you would never have control of parameters outside of your design remit ? ie yes have monitoring of the environment and other variables (say locks etc), but why would you want to put control of a critical system like that into the system in the first place??
2) If it?s that important ? those variables should be fixed within the HVAC system and you would not be able to override ? thereby not your problem to worry about when the good stuff turns sour!
Likewise - it happens all the time; basic change - person who dealt with it left - code lost - can't trace original supplier - client gets to pay for it to be written again! They often ask me to check their other systems - just so they know for future... Be honest and leave it on the system.
Because the client requested it. Not sure why you wouldn't. Isn't that the point of integration? And don't call me Shirley
Now you are relying on the HVAC contractor to do their job correctly. I haven't found them to be all that careful or competent. Last time I did a wine cellar the HVAC contractor hadn't set it up correctly and it was 77 degrees in the wine cellar when I got onsite to start the integration.
Nothing dishonest about it, just trying to make sure that no one screws around with a system I built without my knowledge. Personally I think that helps the client because there is only one person responsible rather than a few people all blaming each other which is what inevitably happens when there are too many cooks in the kitchen.
Paul
I'm sure glad you said that, casue I was sure thinkin' it...
Sure thing Paul
But in the context of the issue raised, that would be the HVAC contractors issue legally! If I found something incorrectly / badly setup - I'd flag it up with the client and not touch it with the control system until resolved.
Once they've paid the bill - ultimately its their system to screw around with if they wish, not mine!
I too have been following this thread very closely
I have had this happen, but when the system is broken this old chestnut comes out, "the code was like that before - I didn't do it!!" comes into play. When I trot along to a very annoyed client, who now sees me as the enemy, I then have to go into defend mode and show them my original code as a form of defence and try to get them back on-side, most of the times free, to try to maintain some form of client relationship. I'd like to know how you handle this now John?
On the flipside, I have had a situation where I was advised that a fee was charged each year to "maintain the system" but when the account was overdue miraculously the system stopped! I have since rewrote the code - without this timebomb which had done the AMX product a lot of damage so far as the clients opinion went, so I can see where holding code from clients is not good.
I leave my code in there but password protected - not sure how secure this is but hey it may stop the "trunk slammer"
Unfortunately, if the client is hell bent on using an alternative contractor, then the relationship is pretty bust already - in my experience when this happens the client is usually sheepish and will eventually admit what has happened & why, and if they've called me back in down the road then its due to the relationship I originally built up, and they are happy to pay for resolution! Maybe I'm just lucky and my clients are more honest than some, maybe it's the commercial / resi split, who knows! I've only lost 1 system to an other, and I didn't mind after 2 years of being called up wanting budget pricing for additional work that never happened, It was no great loss.
The other issue I often find is that the client has a "disc with the code" from the original install, but not any of the subsequent changes over time - and that is a real pain in the behind! It's like smiling death!
As for dead-mans k/o - while it's been tempting, after the event, I'd agree that it just gives the h/w a bad name and you a worse one!
That's why I always leave the box ticked on every compile and only use passwords when the system is exposed on the local network.
I think many of these items are different for resi jobs. We have made it a policy to always load code on jobs. Our relationships with our clients normally are very good when we leave the job. If we have done something to fault them then they have every right to change dealers. On Jim's case about 6 carbon copy rooms that is unfortunate and karma will bite them in the ***...at least you hope. I like the idea of complete transparency. We do have a service agreement, but it doesn't effect the code. It lets us come out and regularly clean (twice a year) look at possible firmware upgrades, any client changes, and keep client contact. If they decide to stop the service agreement I merely take their systems off e-mail notifications from RMS and also delete their e-mail profile for our company (many of our clients like being emailed or emailing their Master). They are paying for service calls, cleanings, and access to our web services.
It's built into our contract agreements, you sign it waiving all rights of intellectual property. Don't sign it, don't get the job. We consider it work for hire.
The whole issue for us will be a mute point shortly. Our group has gotten so much grief over the lack of programming ability of our vendors, that we have started a search this week for one single entity for all of our rooms. I'm not going to throw out vendor names, but the majority of them were terrible when it came to programming systems. Quite simply, we rarely got what we paid for, which was usually a lot of money.
Just a remark on all the above. Side note: I am supporting the "DO NOT SHARE" group.
1.If you sell the job as
- Equipment - $xxxxx
- Installation - $xxxxx
- Programming - $xxxxx
I believe it's a normal assumption from the client to understad that the item "Programming" is redeemable and can claim it as he/she pays for it.
2.If you sell the same job as
- Controlled Equipment - $xxxx
- Intelligent Equipment, pre-programmed as per specifications - $xxxxx
- Installation - $xxxxx
probably the common understanding will be that the so-named "pre-programmed intelligent equipment" is a black box which does some specific tasks.
I am not trying to reinvent the wheel, and I am sure this had been the object of study for many lawyers.
All I am saying is that, if I buy a car, for instance, it will be well understood that claiming access or codes to the ECU pre-programmed software will be out of the question, although (without being itemized) I paid for every single bit. Try and request a feature upgrade or a bug fixing...