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

Always Review Your Dependencies, AGPL Edition

agwa.name

Post reply on HN
Print view View original

131–140 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#131

Post by jsjohnst »

robbya wrote: post #119
sansnomme wrote: post #4

Package managers need to automatically derive properties of end builds based on licenses. E.g. Eclipse License 2.0 without the presence of another more liberal license means it cannot be used in copyleft software, any dependency that is copyleft is also infectious etc. Of course it won't account for every single legal property but the basic checks should be done. To prevent work duplication a single binary/library wr…

Agreed. I found this project helpful for automating dependency checks: https://github.com/pivotal/LicenseFinder I actually played around with turning it into a GitHub action for further usability improvement, although it needs more work: https://github.com/ralexander-phi/license_approval

Pivotal Lab’s license finder used to be my go to recommendation (and still is if “free” is an absolute requirement), but if a company takes license management seriously, I’d recommend checking out FOSSA[0] instead. It’s significantly better and fairly reasonably priced.

[0] https://fossa.com/

Re: Always Review Your Dependencies, AGPL Edition

#132

Post by baybal2 »

arnon wrote: post #32
correct_horse wrote: post #29

Why don't npm-like package managers have settings for licenses in applications (as opposed to libraries)? Settings like "no AGPL" or "no copyleft dependencies" would allow easy vendoring with modifications. This (disabled by default) feature might break some proprietary code, but if it does, that indicates you were not following copyright law prior. Obviously this doesn't solve the general quality problem with depend…

Node's popular `pm2` itself is AGPL. I don't think they're too fussed about copyleft.

Node has tons of AGPL packages which seem to be uses by quite a lot things.

I myself saw a pm2 error message in Linkedin's error 500 output

Re: Always Review Your Dependencies, AGPL Edition

#133

Post by jsjohnst »

rurounijones wrote: post #54
kijin wrote: post #15

Earlier quoted context omitted.

GitHub's license detection algorithm is crap. It tends to get GPLv2 right, but most other licenses are hit-and-miss. And I still can't find a setting where I can manually specify the license when GitHub can't autodetect one or gets it wrong.

Ruby gems have the license as an explicit field in the gemspec (manifest file). Is this not the case elsewhere? It makes license scanning a doddle.

If you trust the license listed in gemspecs alone, you are almost guaranteed to be in violation of a license somewhere. ;)

Re: Always Review Your Dependencies, AGPL Edition

#134

Post by progval »

robbya wrote: post #118
generationP wrote: post #107

> Aside: this is why I don't like to accept pull requests that move code around. Even if the new code organization is better, it's usually not worth the time it takes to ensure the pull request isn't doing anything extra. This sounds like a solvable problem no one has bothered to solve. We need an analogue of diff highlighting for move-around changes, ideally one that decomposes a changeset into the coarsest block pa…

For changes that are a pure file rename 'git mv' tracks those pretty cleanly. Anything beyond that... I don't know of any good tooling either.

Mercurial goes a bit further by tracking copies, so if you split a file in two, a diff viewer will show there is no added code (but a lot of deletions). https://stackoverflow.com/a/4156146/539465

Re: Always Review Your Dependencies, AGPL Edition

#135

Post by userbinator »

naikrovek wrote: post #130
lmm wrote: post #98

Earlier quoted context omitted.

Dependencies are cattle, not pets. There's nothing wrong with having zillions of them; what you need is good tools to manage them in bulk. In the JVM ecosystem, projects are only allowed in the Maven Central repository if they have their license documented in a machine readable fashion there; it's then trivial to check what licenses you're depending on (and there are several plugins available for doing so). I'm amaze…

> There's nothing wrong with having zillions of them That is a scary point of view. We have forgotten that there is no such thing as a zero-cost abstraction, apparently, and shovelware developers are now employed by enterprises and write enterprise software... CPUs aren't getting faster. Software is getting slower a LOT faster than hardware is getting faster, these days, and people are still apparently perfectly fine…

The comment you're replying to makes references to the JVM, which is not surprising given what I've seen in the Enterprise Java culture.

Re: Always Review Your Dependencies, AGPL Edition

#136

Post by progval »

povils wrote: post #5

I think you would end up in a rabbit hole. Do you also review your all GNU/Linux libraries and dependencies? Probably not because you trust them. Thus I think we should be pragmatic and review only libraries which are created by unknown/untrusted creators.

Debian packages are maintained (and quickly vetted) by a rather small group of people (who vet each other). npm packages can be published by anyone without review.

On a somewhat related topic: https://drewdevault.com/2019/12/09/Developers-shouldnt-distr...

Re: Always Review Your Dependencies, AGPL Edition

#137

Post by jsjohnst »

TeMPOraL wrote: post #74
atoav wrote: post #42

Earlier quoted context omitted.

> I'd think the comparison goes the other way around :) Only in the Software industry. This is however not normal: * Mechanical Engineering: Hobbyist bridge vs. professional Bridge – which one should you be able to trust more to carry you? * Electrical Engineering: Hobbyist wall wart vs. professional wall wart – which one should you be able to trust more not to burn your house down? * Medical Treatment: Hobbyist vs.…

Agree on mechanical and medical, but: > Hobbyist wall wart vs. professional wall wart – which one should you be able to trust more not to burn your house down? I will trust a well-known brand with lots at stake, like Apple. But on the other end of the spectrum, I would put more trust in a charger built from ground-up by a hobbyist I from my local Hackerspace than I would in a random charger off Amazon or AliExpress (…

I think GP’s choice of examples for electrical engineering wasn’t likely a good one, but their point generally stands for the time being. Sadly, I see electrical engineering degrading in quality as an industry in a similar fashion to the software industry has.

Re: Always Review Your Dependencies, AGPL Edition

#138

Post by 0x0 »

debiandev wrote: post #89
sansnomme wrote: post #4

Package managers need to automatically derive properties of end builds based on licenses. E.g. Eclipse License 2.0 without the presence of another more liberal license means it cannot be used in copyleft software, any dependency that is copyleft is also infectious etc. Of course it won't account for every single legal property but the basic checks should be done. To prevent work duplication a single binary/library wr…

This is a reason for Debian to exists. Licenses cannot be reviewed automatically in a reliable way. Debian developers review the licenses and store them in a machine-parsable file.

Didn't Debian push a stable security update for Ghostscript that changed the license over to AGPL some time ago?

Re: Always Review Your Dependencies, AGPL Edition

#139

Post by giancarlostoro »

sansnomme wrote: post #4

Package managers need to automatically derive properties of end builds based on licenses. E.g. Eclipse License 2.0 without the presence of another more liberal license means it cannot be used in copyleft software, any dependency that is copyleft is also infectious etc. Of course it won't account for every single legal property but the basic checks should be done. To prevent work duplication a single binary/library wr…

I think each respective package manager should just support this out of the box.

Re: Always Review Your Dependencies, AGPL Edition

#140

Post by sime2009 »

atoav wrote: post #42
TeMPOraL wrote: post #27

Earlier quoted context omitted.

I'd think the comparison goes the other way around :). Hobbyists care enough to do things right even if it's not in the short-term interest. Professionals, judging by all the advice I read on-line, are supposed to focus on delivering value - which is usually measured short-term, and not aligned with doing things right. It's that attitude that makes most companies care little to none about security. Bringing in tons o…

> I'd think the comparison goes the other way around :) Only in the Software industry. This is however not normal: * Mechanical Engineering: Hobbyist bridge vs. professional Bridge – which one should you be able to trust more to carry you? * Electrical Engineering: Hobbyist wall wart vs. professional wall wart – which one should you be able to trust more not to burn your house down? * Medical Treatment: Hobbyist vs.…

The risk profiles of the examples you gave are not comparable to that of most software projects. Most software projects are harmless if they crash. No one is hurt.

Software projects which do risk injury and dead, for example embedded medical, get a lot more engineering and QA.

Post reply on HN