General question on liability issue regarding third-party IP modification

[layowblue]

We are using a third-party IP which we paid money for. And now we found an issue during integration, and the partner is telling us to modify their RTL to fix it.

I don't have access to the contract regarding this IP, but I'm curious about this case.
Generally, if an IP is purchased or licensed, issues found inside the IP should be fixed by the vendor, correct? Otherwise, if the user touched and modified the IP, and if the product has bug related to this IP, how to clarify liability from each side?

Anybody having the experience or insight?

Thanks

 

[dick_freebird]

I think you should assume the finger will point to you, and
only in some remote legal chain of events would your IP
vendor's responsibility come into play.

It is not stated, whether the IP block is actually defective,
or whether the problem is in how you insist to use it. If
you are pushing or violating the boundaries of their interface
specification, or trying to take advantage of some incomplete
specification, maybe it's not them that's to blame.

Legal advice, I'll leave to the lawyers.

 

[layowblue]

Thanks for your reply.
Actually, I'm trying not to touch the IP, and trying to push back for the vendor to fix the issue they created in their own RTL. It's weird that they even asked us to modify their code. I'm concerned if there is a hidden trap.

 

[ads-ee]

Odd that the vendor would suggest you change the code.

I once ran across bug(s) in a vendors IP core that we paid for and the vendor wanted my testcase to prove the issue. Once they ran it and discovered the problem, they produce a patch and sent it to me. Unfortunately for them they sent me and un-encrypted RTL patch...and I found another problem in their code, that I was able to force to occur by modifying my testcase. Needless to say it became a rather visible issue on the project and our upper level managers and the vendors managers setup a meeting where I ended up telling them (IP coders) how to fix their IP. Sure hope nobody is using that IP in some medical equipment now and I missed some other bug in the IP I "fixed". ;-)

 

[layowblue]

Interesting...
We have the un-encrypted RTL from the vendor. We paid for it. But it turns out that some of the RTL does not have associated doc spec. That's why I started reverse engineering the RTL, and identified several issues. For the first one or two issues, they agreed to fix it. But recently, as more issues are found by me(reading RTL without verification), they tend to let me fix it saying "since you know the root cause and the work-around". I have my own red-line beyond which I would never go.

Based on above discussion, I've made up my mind never modifying the vendor RTL.

Odd that the vendor would suggest you change the code.

I once ran across bug(s) in a vendors IP core that we paid for and the vendor wanted my testcase to prove the issue. Once they ran it and discovered the problem, they produce a patch and sent it to me. Unfortunately for them they sent me and un-encrypted RTL patch...and I found another problem in their code, that I was able to force to occur by modifying my testcase. Needless to say it became a rather visible issue on the project and our upper level managers and the vendors managers setup a meeting where I ended up telling them (IP coders) how to fix their IP. Sure hope nobody is using that IP in some medical equipment now and I missed some other bug in the IP I "fixed". ;-)

 

[jbeniston]

I don't have access to the contract regarding this IP, but I'm curious about this case. Generally, if an IP is purchased or licensed, issues found inside the IP should be fixed by the vendor, correct? Otherwise, if the user touched and modified the IP, and if the product has bug related to this IP, how to clarify liability from each side?

Generally, they should be fixed by the vendor, but there isn't necessarily any liability anyway. You'd have to see the contract to find out.

 

[ads-ee]

Interesting...
We have the un-encrypted RTL from the vendor. We paid for it. But it turns out that some of the RTL does not have associated doc spec. That's why I started reverse engineering the RTL, and identified several issues. For the first one or two issues, they agreed to fix it. But recently, as more issues are found by me(reading RTL without verification), they tend to let me fix it saying "since you know the root cause and the work-around". I have my own red-line beyond which I would never go.

In one respect having bought the RTL you can probably do what you want with it in regards to modifying it for your needs. I also suspect that having purchased a license for the RTL also means any modifications (or fixes) you make to the code don't have to be given to the vendor. Seems to me that you could then fix all the bugs. Make note of what they are and how to make them happen. Any competitors that use the same core might not have been so diligent about testing and fixing problems...Seems like a good way to show customers how much better your product behaves when you can make the competitors product "break", but yours is still running merrily along.

Regards