4 ms·
My 2c as someone who works on the enterprise side of these requests: There are a couple of reasons reasons we might ask to look at your code: 1. While not a r
by hvindin 9y ago
My 2c as someone who works on the enterprise side of these requests:
There are a couple of reasons reasons we might ask to look at your code:
1. While not a reason to look at your code, instead, if we don't have a valid reason to look or don't have access to technical resources either internal or via external consultants who we are fairly confident could build whatever the software is we are buying given time and resources then we DO NOT WANT TO SEE YOUR IP. This goes as far as shell scripts vendors use for stuff that we don't particularly care about. If they leave them on our boxes we make sure we destroy the data. If the company is worth 50bn then there is it a very small chance their about to make a huge pivot to your particular niche and therefore need your code to solve a problem. The reason companies buy software is because they don't want to pay people to maintain it and in addition they DEFINITELY don't want to get sued for looking at your code. So for no other reason than legal repurcussions you can probably trust them not to do anything sketchy. (Disclaimer: small business units do sometimes go rouge. Make sure youre talking to someone who understands the company wide impacts of fucking this up)
2. If the code is going to be used in sensitive environment (ie. Air gapped networks) we may want to scan for both destructive malware dependencies or just bad code that intentionally or unintentionally might damage systems. Also you would be amazed how many vendors build hooks to call out to the internet in standalone software packages that they "certify" for offline use.
3. If we need to build a bunch of integrations ourselves (ie you would be useless to us in so far as needing to understand legacy core banking systems and the like and therefore are not helpful with your knowledge of the code base, we need someone with knowledge of both code bases at a fairly low level) then depending on the size of the code base we might ask for all of it or just all the external interface implementations. Not the definitions. The actual code.
4. If you are a small company it is not unlikely that we will negotiate a clause which says that if you disappear or all your developers die or whatever, then we are allowed to internally use your code base to build our own stuff since we will end up with dependencies on it and will want to make sure we can still function without you (this is obviously not ideal, we would rather throw money at you to make problems go away, but if you aren't a business any more then we just have to hire people to do it) I actually heard a colleague working at a competing bank in Australia tell me that their agreement with hashicorp gives them ownership of consul enterprise code base for use internally if hashicorp disappears. You just need to make sure your lawyers and on this properly to make sure you clearly define the circumstances in which the large companies expectations of you maintaining the code are no longer met and therefore they can do it if they need to.
5. If we just don't trust you to not be hiding some black magic bullshit behind the scenes. This is usually the result of particularly uninformed sales people making claims that cannot technically be true, and thus out due diligence require that we handle it ourselves. It's also much more likely that we will recommend a bunch of software auditing companies we have used and we trust to audit the code base for us, just so we don't have the liability of your IP in our heads.
6. If we have government financial institution regulations which apply to the thing we want to use your software for and we are required to check of sign off the risk. As an example, an Australian bank running things on cloud platforms that hook back into traditional on prem systems it is mandatory without exception that all data at rest or in flight be encrypted. We trusted a large software company on this and only when we had auditors sniffing traffic over the network did we discover that major data intensive operations relating to backup integrity decrypted everything and then pumped it over the wire between instances using HTTP at which point we where $6m deep in licensing fees so we had a few very difficult conversations about "fix it or fuck off and pay us substantial reparations" because we suddenly needed a lot of technical lawyers (who ate as rare as hens teeth) to explain what had happened to avoid fines that could have cost literally billions.
Summary: there are a bunch of reasons a company might want to see your code. If the person you are talking to is speaking on behalf of the whole organisation (ie. They understand broader business implications of doing anything shady) then you're almost definitely safe. If your a bit on the fence about the whole thing, get a third party auditor in, but the request itself is pretty reasonable.
- hvindin 9y agoI just remembered a specific use case which we had where we where told no re: looking at code and it completely screwed us. One of the banks owned by our parent company was using a system built by HP to determine loan rates. Now, being a bank that's kind of their core competency so letting someone else build it just seems silly. But two years later I was on a project trying to hook a bunch of stuff up to this system and we noticed that we couldn't get a proper test run because it kept giving us different figures for the same inputs. After asking again for the code, or even pseudo code that would explain the behaviour we again told no. A bunch of lawyers got in a room and they explicitly threatened to sue us if we tried to decompile their code or monitor the system to learn the logic. My response to this was immediate alarm bells because that meant we where not allowed to actually test the system which paid for most of the development of and hosted internally. A discussion with just our lawyer revealed that, because it was related to home loan rates, our liability was actually significantly reduced if it where technically possible to decompile the code and verify what it was doing because the cost of not being able to explain it to auditors would be so high and the amount we would be sued for might maybe max out in the 10's of millions. After a bit of very low level analysis we found that their algorithm for determining a load rate included a random number generator to determine an arbitrary discount in the case that very similar data was input repeatedly. We later discovered that a developer was trying to be clever and get more home lones sold and had entirely missed the point of risk profiling properly. Ie. We don't want to sell you a home loan at a low interest rate if the risk of you defaulting makes it less profitable. Eventually the resolution we came to was that HP would fix this shit up and they would provide us with all of the original source they had access to. But for the next 20 years or so we will be carrying the liability of potentiallt hundreds of loans (this system wasn't used by most business units at the time but we where thinking of expanding out its use, hence the project) that have an interest rate that is lower than it needs to be (like 1-1.5% lower!) to cover the risk profile of the person who got the loan. And all we needed was the code and that wouldn't have happened.