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

211–220 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#211

Post by mr_toad »

jsjohnst wrote: post #125
syshum wrote: post #86

Earlier quoted context omitted.

Because even in 2020, even in " secure/financial apps" most programmers have security and lic legality as a secondary (or even forth level) concerns, they just want to "make something cool" They play lip service to it being secure, and/or license compliant

I would argue the reason developers don’t have concerns around licensing is partly due to lack of knowledge around the differences between licenses at a fundamental level and partly due to a “why should I care?” mentality at least at a subconscious level, if not higher. A got a taste of it yet again this past weekend when I commented here on HN about GPL and AGPL being licenses that corporations often have concerns w…

I find it’s the opposite - people with limited understanding of licensing (and IP law in general) often have the most concerns, and misapprehensions.

Re: Always Review Your Dependencies, AGPL Edition

#212

Post by fenwick67 »

sime2009 wrote: post #146
iforgotpassword wrote: post #76

Earlier quoted context omitted.

I'm not a web dev, not a JavaScript fan, but out of pure curiosity I've been playing with the idea of doing my next side project in node, just to get an idea of what modern Js feels like. But the whole dependency hell, left-pad and the likes are a real turnoff. So what I'd probably end up with is coding in pure Js without a package manager or "build system". Basically like you did PHP in the 90s. The question is whet…

It is certainly possible to do JS development in a more controlled way. My advice is to avoid most of the JS build tools (i.e. grunt, gulp) by using npm scripts (basically shell commands defines in `package.json`) to trigger build actions, or to start smaller, more specialised tools. At least then you will understand how your build works and won't have an extra layer of buggy plugins screwing things up. Also being co…

I have a project with a build system that is basically cat src/js/* > dist/bundle.js , it's refreshing when you have to deal with setting up webpack at work.

Re: Always Review Your Dependencies, AGPL Edition

#213

Post by antoncohen »

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…

Yarn has `yarn licenses list`[1], which is very useful. And there is an accepted RFC for `yarn licenses check`[2] they would check against a list of allowed licenses.

[1] https://yarnpkg.com/lang/en/docs/cli/licenses/

[2] https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-li...

Re: Always Review Your Dependencies, AGPL Edition

#214

Post by School-Cotton »

nieksand wrote: post #187
vmchale wrote: post #172

Earlier quoted context omitted.

It's unfortunate that Rust is so tied to cargo, and unfortunate that cargo insists on allowing multiple versions of a dependency. If you point out that cargo is poorly designed everyone just yells and you and says you don't understand.

Can you elaborate on the design flaws that you perceive in Cargo?

The biggest flaw is that it makes taking new dependencies easy. I would prefer that it be hard, like in C++, so people think before doing it.

The second biggest flaw is that it couples package management to a programming language, despite those being almost completely unrelated concerns.

Re: Always Review Your Dependencies, AGPL Edition

#215

Post by vmchale »

School-Cotton wrote: post #214
nieksand wrote: post #187

Earlier quoted context omitted.

Can you elaborate on the design flaws that you perceive in Cargo?

The biggest flaw is that it makes taking new dependencies easy. I would prefer that it be hard, like in C++, so people think before doing it. The second biggest flaw is that it couples package management to a programming language, despite those being almost completely unrelated concerns.

> The second biggest flaw is that it couples package management to a programming language, despite those being almost completely unrelated concerns.

Yes it's frustrating. I wish it was more decoupled, maybe with package standards like Haskell tried to do with Cabal.

It makes it hard to use Rust as a drop-in replacement for C. I can add a few C files to a Haskell project without much problem, but most rust code goes via cargo.

Re: Always Review Your Dependencies, AGPL Edition

#216

Post by vmchale »

damnyou wrote: post #205
vmchale wrote: post #203

Earlier quoted context omitted.

It's not as bad as cabal back in the day. Nonetheless I have run into the diamond dependency problem in practice. Their solution is unprincipled and there's no way to turn off the default behavior.

Do you mean passing a struct from e.g. clap 2 into clap 3? Yeah that won't work directly, nor should it in my opinion. If it is frequently required, projects can and should provide a compatibility layer which does any necessary conversions.

> Do you mean passing a struct from e.g. clap 2 into clap 3? Yeah that won't work directly, nor should it in my opinion.

I agree! But it shouldn't fail at compile time with a vexing error message. It should fail to resolve dependencies when calculating a build plan.

Re: Always Review Your Dependencies, AGPL Edition

#217

Post by oaiey »

correct_horse wrote: post #69
arnon wrote: post #32

Earlier quoted context omitted.

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

> I don't think they're too fussed about copyleft. Yeah, and I'm not either. I have never decided to vendor dependencies, and my only modifications to GPL code were to upstream (so I didn't have a legal obligation to distribute the modified code - the distributors of the code I modified do). I just think automated license compatibility checking could be a good move for the ecosystem. Also to be clear, I was talking a…

I hope on your comment you do not mix up LGPL and GPL.

Re: Always Review Your Dependencies, AGPL Edition

#218

Post by oaiey »

baybal2 wrote: post #132
arnon wrote: post #32

Earlier quoted context omitted.

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

A GPL or AGPL software should not exist on NPM for libraries. For tools yes, but GPL for libraries is for 99% of the users a non-starter. It just does not belong into a library ecosystem.

To be clear: everyone has the free right to license their stuff how they like. I just think NPM as a ecosystem should be opinionated (and it is... Towards MIT. Just not completely).

Re: Always Review Your Dependencies, AGPL Edition

#219

Post by lmm »

darkarmani wrote: post #207
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…

> what you need is good tools to manage them in bulk How do you manage reputation and relationships in bulk? There are transactional costs here. Dependencies created by maintainers with impeccable reputations are a much smaller risk than arbitrary dependencies created by arbitrary maintainers.

You require releases to be signed by maintainers (again, something maven central enforces and other repositories ought to), and then you have a notion of maintainer identity and can decide which you trust (again something that plugins let you do). If there are still too many maintainers then you can use the GPG web of trust approach, as e.g. Debian does, and see which maintainers are part of trusted organisations.

Re: Always Review Your Dependencies, AGPL Edition

#220

Post by jbboehr »

vemv wrote: post #182

> It started off poorly when I noticed some Brown M&M's: despite being a library, it was logging messages to stdout In many language ecosystems, logging to stdout tends to be the right thing to do in a lib as it does not impose any specific choice of logging implementation. One always can recapture stdout and route it through one's logging solution of choice; doing something analog with an extraneous logging library…

As a library, if you just have to avoid logging frameworks, at least log to `stderr` so you don't break tools that parse output.
Post reply on HN