Hacker News Reader

Comment by itsdrewmiller | Hacker News Reader

These all seem accurate and I'd add even moreso than security (which can be prioritized for other reasons) a focus on buttoning up open source licensing / IP ownership is a dead giveaway that a sale is close. Also the hiring and retention thing is probably less about distraction and more about not taking on additional expenses in the middle of due diligence - generally the acquirer will want to have more of a say in staffing strategy.

View on HN

100% - OSS IP licensing is exclusively the provenance of public companies, companies about to go public, and companies about to be purchased.

I don't actually know what "buttoning up open source licensing / IP ownership" means. Is that making sure you have a license for all software you're using?

You make sure that employees don't own what they write, but sign it over to the company (usually language to that effect in the employment contract, if there is none).

Also running tools like Black Duck over your source code tree to check open source license types or use of unlicensed code snippets from the Web.

NDAs can be given to people who know how something is done, knowledge that they could use to re-create the product or service elsewhere, which the acquired does not want. In some cases (that I have not personally seen) making people sign non-compete agreements, meaning if they quit they cannot work on the same thing for some time (not legal everywhere).

If "BigCorp" buys "CoolIdea" for their nifty piece of software "SecretSauce" they do not want to find out later that "BigCorp"/"CoolIdea" is required to publish source code for "SecretSauce" because it's based on "GNUOpenSauce" or that "CoolIdea" was selling something based on "FSFSauce."

Big companies are very allergic to GPL-like copyleft licenses. You generally have to go over the entire dependency tree with a fine tooth comb and make sure that nothing is going to get you sued to released the source code (inside a big company there are processes to ensure this on an ongoing basis)

FWIW, I've had to track down licensing and proof of IP assignment for fundraising rounds too.

On a tangent , can anyone point me to resources on solving the problem of distributing docker images with oss licensed software inside them?

What’s the problem that’s specific to container images? It’s no different than distributing software binaries that include FOSS.

Sometimes the lower layers of the image fs can have binaries in there that are not used or even accessible to the running container.

They're still accessible by inspect and hash (maybe start with "docker history".) You may find it easier to use that to get enough info to build your own images from scratch, so you have control of what's going in (since you already have responsibility.) "mmdebstrap | docker import" gets you surprisingly far.

It’s not a problem per-se. You just have to document them and their license. Whether you actually have to do that is another question since most believe that that would fall on the base image publisher, not the final image. Further, a proper base image will already include licenses in the base image because most OSS licenses require distributing the software with the license available.

The only thing you would have to document are the things you specifically added.

At least, that’s been my experience.

If the license says I must make the source code available, don’t I also have to have some mechanism to provide that code if asked?

Debian based distros (and all the others) have a command to run and get the sources for ALL open source packages installed on the system. So, there is nothing to do there. apt get source package.

If someone asks for source code for a library, simple point them to the GitHub repository. This isn’t rocket science and it isn’t worth automating because practically nobody asks for it.

For packages being installed from distributions like Debian, you are correct that doing "apt-get source $pkg=$version" will download the source, so you can do it for every package in the image that you are distributing. On the other hand, if you are using Alpine as a base, things are not so easy..

For GPL-licensed code, you should provide the sources yourself. "Point them to a GitHub repository" is not acceptable, since the repo might disappear or change contents without you noticing.

And it is definitely worth automating, if you are releasing at scale (either many products or many versions). Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"

Thank you that’s very helpful. I’m also wondering about pip and npm

That is specific to the language, but neither Python nor JavaScript is a compiled language, so for the most part, those sources are already distributed. Some of those packages also contain binaries, so it can get dicey. Some may even have an incompatible license, so you have to be careful.

At a big company, we (as in the team) had to review any and every library and its dependencies before we could use it, then the security team had to review it. The amount of shit code out there is outstanding; many times we would just reimplement it ourselves, unless the library did something substantial that we didn’t want to maintain. (This is also why zero-dependency libraries are a thing)

> Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"

Generally, this can be solved by simply vendoring your dependencies (aka, commit them to the repository instead of fetching them for every build).

> For GPL-licensed code, you should provide the sources yourself.

Version 3 of the GPL simply states that "clear directions" on how to find the source code may be given. There's no requirement for you to distribute those sources yourself unless you make modifications and make the software available for sale or download. Internal use/private modifications do not need to be given away.

> it is definitely worth automating

I worked at a company that dealt in nothing but commercially licensed open source code. That meant we were much more likely to get requests for our source code because it was obvious we were running heavily modified open source software. That being said, despite having millions of users, we only got a few requests a month and we still didn't bother automating it.

So, I'm not convinced it is worth automating unless you are in the hundreds of millions of users range.

this is how I guessed we were being acquired - a request to compile a list of the licenses of the dependencies of our mobile app, out of the blue and without further explanation

Reply on news.ycombinator.com