Who owns the data/database? Customer or vendor?
-
We have an application that combines data from multiple business areas. (POS, Inventory, Accounting, Payroll, etc.) Most of the time, these sources are from different vendors and most of the time these vendors utilize SQL Server. For years, we have simply worked with the IT departments of our customers to create sql logins for these other databases (db_datareader role only!) in order to extract data used by our application. This usually involves the customer sending us a backup that we restore, analyze against a report set, and build queries against. The goal is to solve the business need of the customer who needs to have these many puzzle pieces in a single place...we are not competing with the other vendors, only making use of the data from their systems. The reason for this post is that last week, I got a call from an angry software developer for one of these vendors who wanted to know who gave us permission to connect to their sql database and blaming us for missing records. I expained the concept of the db_datareader role and expressed my opinion that the data belongs to the customer...the customer gave us permission for the connection in order to fulfill a business need. He said he will be contacting his legal experts on the matter. So, how would you feel if you found out another company was mining your database?
"Go forth into the source" - Neal Morse
-
We have an application that combines data from multiple business areas. (POS, Inventory, Accounting, Payroll, etc.) Most of the time, these sources are from different vendors and most of the time these vendors utilize SQL Server. For years, we have simply worked with the IT departments of our customers to create sql logins for these other databases (db_datareader role only!) in order to extract data used by our application. This usually involves the customer sending us a backup that we restore, analyze against a report set, and build queries against. The goal is to solve the business need of the customer who needs to have these many puzzle pieces in a single place...we are not competing with the other vendors, only making use of the data from their systems. The reason for this post is that last week, I got a call from an angry software developer for one of these vendors who wanted to know who gave us permission to connect to their sql database and blaming us for missing records. I expained the concept of the db_datareader role and expressed my opinion that the data belongs to the customer...the customer gave us permission for the connection in order to fulfill a business need. He said he will be contacting his legal experts on the matter. So, how would you feel if you found out another company was mining your database?
"Go forth into the source" - Neal Morse
This all depends on the contract between the other vendor and the client. Almost certainly the data belongs to the client, however the structure the data is contained in may well be the IP of the vendor and having another SW house ratting arround the structure could be percieved as infringing on their IP. Most vendors needing to protect their IP in the structure will publish views that can be consumed by the client (and other vendors). I suspect his legal experts are going to tell him to pull his head in!
Never underestimate the power of human stupidity RAH
-
We have an application that combines data from multiple business areas. (POS, Inventory, Accounting, Payroll, etc.) Most of the time, these sources are from different vendors and most of the time these vendors utilize SQL Server. For years, we have simply worked with the IT departments of our customers to create sql logins for these other databases (db_datareader role only!) in order to extract data used by our application. This usually involves the customer sending us a backup that we restore, analyze against a report set, and build queries against. The goal is to solve the business need of the customer who needs to have these many puzzle pieces in a single place...we are not competing with the other vendors, only making use of the data from their systems. The reason for this post is that last week, I got a call from an angry software developer for one of these vendors who wanted to know who gave us permission to connect to their sql database and blaming us for missing records. I expained the concept of the db_datareader role and expressed my opinion that the data belongs to the customer...the customer gave us permission for the connection in order to fulfill a business need. He said he will be contacting his legal experts on the matter. So, how would you feel if you found out another company was mining your database?
"Go forth into the source" - Neal Morse
kmoorevs wrote:
how would you feel if you found out another company was mining your database?
But it isn't, it's the customer's. At any rate, I haven't done that from a third-party company, only from the customer. On my last job, one of my primary tasks was to copy data between different databases (Ingres and SQL server in particular). The vendor that used Ingres didn't seem to mind. If I wrote to the database directly it crashed the system (yes, I did that more than once -- yes, the production database), but I could read the database. Getting data in was more of a problem, but doable. The vendor that used SQL Server wasn't very happy: 0) At some point before I got there someone had created some tables in the application's database (a big no-no) -- and it was some time (years?) before anyone realized that they had broken the backup. :wtf: 1) We had asked the vendor for an API so we could update the database; they said they would, then hemmed-and-hawed, then delivered a unusable tool. :sigh: 1.a) In the meantime, I had asked tech support whether or not I could set certain fields and he said I could. So I did. So by the time their management found out and freaked, it was too late. :-D Oh, and in both cases, the vendors knew what we were trying to do. It sounds like, in the case you describe, the vendor didn't know, and that's the real problem.
-
kmoorevs wrote:
how would you feel if you found out another company was mining your database?
But it isn't, it's the customer's. At any rate, I haven't done that from a third-party company, only from the customer. On my last job, one of my primary tasks was to copy data between different databases (Ingres and SQL server in particular). The vendor that used Ingres didn't seem to mind. If I wrote to the database directly it crashed the system (yes, I did that more than once -- yes, the production database), but I could read the database. Getting data in was more of a problem, but doable. The vendor that used SQL Server wasn't very happy: 0) At some point before I got there someone had created some tables in the application's database (a big no-no) -- and it was some time (years?) before anyone realized that they had broken the backup. :wtf: 1) We had asked the vendor for an API so we could update the database; they said they would, then hemmed-and-hawed, then delivered a unusable tool. :sigh: 1.a) In the meantime, I had asked tech support whether or not I could set certain fields and he said I could. So I did. So by the time their management found out and freaked, it was too late. :-D Oh, and in both cases, the vendors knew what we were trying to do. It sounds like, in the case you describe, the vendor didn't know, and that's the real problem.
"the vendor didn't know, and that's the real problem." True and False...the vendor knew about the first client we connected to, some 8 years ago, they just didn't know that we were connecting to other clients we have in common. Originally, they had provided the field layouts for their summary tables of the data we were requesting at that time. Over time, we have identified other areas of import from this vendor's database...and we built the queries, verified the results, and made life easier for our common clients, with the cooperation of the clients' dba. In my experience, database admins feel like they own the data/databases and the idea of automating an export/import process appeals to them.
"Go forth into the source" - Neal Morse
-
We have an application that combines data from multiple business areas. (POS, Inventory, Accounting, Payroll, etc.) Most of the time, these sources are from different vendors and most of the time these vendors utilize SQL Server. For years, we have simply worked with the IT departments of our customers to create sql logins for these other databases (db_datareader role only!) in order to extract data used by our application. This usually involves the customer sending us a backup that we restore, analyze against a report set, and build queries against. The goal is to solve the business need of the customer who needs to have these many puzzle pieces in a single place...we are not competing with the other vendors, only making use of the data from their systems. The reason for this post is that last week, I got a call from an angry software developer for one of these vendors who wanted to know who gave us permission to connect to their sql database and blaming us for missing records. I expained the concept of the db_datareader role and expressed my opinion that the data belongs to the customer...the customer gave us permission for the connection in order to fulfill a business need. He said he will be contacting his legal experts on the matter. So, how would you feel if you found out another company was mining your database?
"Go forth into the source" - Neal Morse
Basically that is what lawyers and written contracts are for. I am fairly certain that if you have been accessing the their data for some time and delivering value to them from that then they have no case. Unless there is a contract that explicitly forbids it. In terms of destroying their data they would need to prove that.
-
Basically that is what lawyers and written contracts are for. I am fairly certain that if you have been accessing the their data for some time and delivering value to them from that then they have no case. Unless there is a contract that explicitly forbids it. In terms of destroying their data they would need to prove that.
Just got an email. They are asking for full disclosure of common clients and queries...nothing threatening, actually quite positive. This is fair enough, and probably should have been in practice before. As for the missing data, it was explained as an internal issue. Apology accepted. We'll see where it goes from here. Think positive.
"Go forth into the source" - Neal Morse
-
Just got an email. They are asking for full disclosure of common clients and queries...nothing threatening, actually quite positive. This is fair enough, and probably should have been in practice before. As for the missing data, it was explained as an internal issue. Apology accepted. We'll see where it goes from here. Think positive.
"Go forth into the source" - Neal Morse
Sounds like a bad idea to me. They are asking you to reveal your business information to them. Information that should have nothing to do with them. What are you going to do if they take that client list and tell those other people that they must drop you?
kmoorevs wrote:
This is fair enough, and probably should have been in practice before
If your business was based on a smile and a handshake and the other side is no longer satisfied with that then it is time to use a contract.
-
We have an application that combines data from multiple business areas. (POS, Inventory, Accounting, Payroll, etc.) Most of the time, these sources are from different vendors and most of the time these vendors utilize SQL Server. For years, we have simply worked with the IT departments of our customers to create sql logins for these other databases (db_datareader role only!) in order to extract data used by our application. This usually involves the customer sending us a backup that we restore, analyze against a report set, and build queries against. The goal is to solve the business need of the customer who needs to have these many puzzle pieces in a single place...we are not competing with the other vendors, only making use of the data from their systems. The reason for this post is that last week, I got a call from an angry software developer for one of these vendors who wanted to know who gave us permission to connect to their sql database and blaming us for missing records. I expained the concept of the db_datareader role and expressed my opinion that the data belongs to the customer...the customer gave us permission for the connection in order to fulfill a business need. He said he will be contacting his legal experts on the matter. So, how would you feel if you found out another company was mining your database?
"Go forth into the source" - Neal Morse
Unless it is spelled out differently by contract, I'm not sure how the data ever belongs to the vendor. And I wouldn't sign such a contract with a vendor, I'd tell them to pound sand. Most of my customers business IS their information or tied directly to it. If the vendor owns it then the vendor can tell you that if you migrate away from their product that you can't take the data with you. Who would agree to such a thing that was thinking? This would be like Microsoft insisting that they own your documents because you wrote them in Word. I also wouldn't give these guys a list of common customers. They are considering a lawsuit and they want to have 'evidence' that you've been tampering with their clients and they want a way to calculate damages- so they can decide to move forward, or not.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug...
-
Just got an email. They are asking for full disclosure of common clients and queries...nothing threatening, actually quite positive. This is fair enough, and probably should have been in practice before. As for the missing data, it was explained as an internal issue. Apology accepted. We'll see where it goes from here. Think positive.
"Go forth into the source" - Neal Morse
But did they actually use the phrase "Full Disclosure"? Doesn't that sound like their lawyer asked them to get the list? Think carefully about how you answer them. If your company has a lawyer I'd run it by them. The developer threatened legal action and now wants this piece of information. Perhaps you should take the threat seriously.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug...
-
Unless it is spelled out differently by contract, I'm not sure how the data ever belongs to the vendor. And I wouldn't sign such a contract with a vendor, I'd tell them to pound sand. Most of my customers business IS their information or tied directly to it. If the vendor owns it then the vendor can tell you that if you migrate away from their product that you can't take the data with you. Who would agree to such a thing that was thinking? This would be like Microsoft insisting that they own your documents because you wrote them in Word. I also wouldn't give these guys a list of common customers. They are considering a lawsuit and they want to have 'evidence' that you've been tampering with their clients and they want a way to calculate damages- so they can decide to move forward, or not.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug...
Hah! Seems they have done some homework...I got an email this morning with a sql script attached showing all the queries used against their database...must have started a trace. The email informed me that the queries passed QA. A half-hour later, I get another email stating that our request for access their system has been approved pending the acceptance and signature of a formal document. The document simply states that we acknowledge and respect their database and all objects contained therein or created thereby as intellectual property of the vendor. We also agree to identify them as the source of any data retrieved from their system, (already in place) and to destory any backups or databases we may have obtained from the client. (sure thing) As a sidenote, the email stated that 'clients have a favorable opinion of your company and consider the connector to our system as 'integral' to their business objectives'. I have a new contact with their dev team and a promise of cooperation should I need it. We are reviewing the document now. I may have to delete this thread as it is now showing up in google searches on the subject!
"Go forth into the source" - Neal Morse
-
Unless it is spelled out differently by contract, I'm not sure how the data ever belongs to the vendor. And I wouldn't sign such a contract with a vendor, I'd tell them to pound sand. Most of my customers business IS their information or tied directly to it. If the vendor owns it then the vendor can tell you that if you migrate away from their product that you can't take the data with you. Who would agree to such a thing that was thinking? This would be like Microsoft insisting that they own your documents because you wrote them in Word. I also wouldn't give these guys a list of common customers. They are considering a lawsuit and they want to have 'evidence' that you've been tampering with their clients and they want a way to calculate damages- so they can decide to move forward, or not.
_____________________________ Give a man a mug, he drinks for a day. Teach a man to mug...
This seems to answer the question. The vendor owns the database...structure and objects. The client own's the data in the database. Clients also own the SQL Server license and contol access to databases. In most cases, whether or not they know it, clients have accepted a EULA that prohibits them from sharing software components (including databases) with third parties without written consent. I believe that a contract is a good idea to protect all three parties involved.
"Go forth into the source" - Neal Morse