Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signs you're about to be acquired (2020)

yolken.net

Post reply on HN
Print view View original

81–85 of 85 posts

Re: Signs you're about to be acquired (2020)

#81

Post by totetsu »

zvr wrote: post #80
withinboredom wrote: post #39

Earlier quoted context omitted.

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, si…

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

Re: Signs you're about to be acquired (2020)

#82

Post by billy99k »

The company I work for was acquired during the height of Covid. We had an all-hands meeting with the entire company with a 1-hour notice on a Monday. I knew something was up and wasn't that surprised.

The new company made sweeping cuts and I for sure thought I was out of a job. Luckily, the IT team on both sides is small and I got to keep my job (3 years now).

It also helped that upper management of the new company made really terrible IT decisions (the director was fired about a year after the acquisition). We were supposed to convert our proprietary systems (that I maintain) to Net suite. The plan was terrible and crashed and burned.

They tried again last year, and we were successful.

Re: Signs you're about to be acquired (2020)

#83

Post by withinboredom »

totetsu wrote: post #81
zvr wrote: post #80

Earlier quoted context omitted.

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, si…

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)

Re: Signs you're about to be acquired (2020)

#84

Post by withinboredom »

zvr wrote: post #80
withinboredom wrote: post #39

Earlier quoted context omitted.

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, si…

> 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.

Post reply on HN