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

161–170 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#161

Post by pbhjpbhj »

M2Ys4U wrote: post #104
Doctor_Fegg wrote: post #39

Earlier quoted context omitted.

CC0 is a licence. "Public domain" is a state. Some works have no copyright, typically because they're the product of a US Federal institution, or the copyright has expired. In American English this copyright-free state is also known as "public domain". (In British English it can mean something quite different.) To put something in the "public domain", you need to make a statement of such. In other words, a licence. Y…

>To put something in the "public domain", you need to make a statement of such. In other words, a licence. You could just say "I put this in the public domain" but it may not provide the certainty that bigcorps like. CC0 is a way of saying this in bigcorp-friendly language. It's more than that - it's impossible to place things in to the public domain in many juristictions - like the UK. (This is because copyright is…

You can abandon property to public ownership (land, cars, anything you leave in the street in England & Wales: it gets sold and proceeds go to the Exchequer or Police) so your justification at the end doesn't sway me.

Moreover, Google have been allowed to assume ownership of intellectual property (content of books). The moral rights on those properties have been effectively cancelled.

Re: Always Review Your Dependencies, AGPL Edition

#162

Post by pbhjpbhj »

alphager wrote: post #43
pbhjpbhj wrote: post #33

Earlier quoted context omitted.

Aside, can anyone explain this to me? >Please do not use "public domain", it's not a license and it makes it impossible to use such code in corporate context. // Seems pretty ridiculous, "can't use code unless it's encumbered by licensing restrictions"??

"Public Domain" is encumbered by Moral Rights https://en.wikipedia.org/wiki/Moral_rights . While they play a very minor role in the US, they exist in Canada and most of the EU. Something like the MIT-license neatly gets rid of them.

Cool, thanks.

I'd argue that when I release something to the public domain that means that I give an open license such that the work can be used as if in the public domain until such time as it actually enters the public domain.

But, yes, I can see how that's a risk companies might avoid until caselaw backs that up.

Re: Always Review Your Dependencies, AGPL Edition

#163

Post by SamWhited »

marcan_42 wrote: post #72

> The bulk of my trust is consolidated in the Go project, and thanks to their stellar reputation and solid operating procedures, I don't feel a need to review the source code of the Go compiler and standard libraries. Well... I have reviewed the Go runtime, after I ran into a bug in it... And that's one of the reasons I no longer use Go unless forced to. That thing is ugly under the covers. There is seriously quite a…

The standard library is generally very well designed and has good practices with the caveat that you should stay away from encoding/*, there be dragons.

Re: Always Review Your Dependencies, AGPL Edition

#164

Post by q3k »

iSnow wrote: post #150
codeflo wrote: post #121

Earlier quoted context omitted.

I’m a bit torn on this. I have most of my experience in the .NET ecosystem, where dependencies are a lot more manageable. However, if something breaks, you’re screwed a lot harder, because it’s not so easy to replace a large library, and there are very likely fewer well-maintained alternatives than there would be on NPM. In total, I find it hard to deny how productive the NPM ecosystem can be, despite my philosophica…

You aren't alone in this. The Node/NPM/JS scene is churning out code and innovations like there's no tomorrow, that's something to admire. What I feel they are missing is a community process to consolidate things. You don't need three generations of ten incompatible solutions for a given problem - after some iterations, things should consolidate into one or two more or less standardized libs that don't break existing…

> You aren't alone in this. The Node/NPM/JS scene is churning out code and innovations like there's no tomorrow, that's something to admire.

I don't find churning out code admirable, and I also don't think I've seen any true innovation come out of the NPM scene (bar innovation in the browser/JS space itself, which I think isn't a good measure as it's mostly just working around limitations that shouldn't be there in the first place).

Re: Always Review Your Dependencies, AGPL Edition

#165

Post by dependenttypes »

grammarxcore wrote: post #145
marcan_42 wrote: post #72

> The bulk of my trust is consolidated in the Go project, and thanks to their stellar reputation and solid operating procedures, I don't feel a need to review the source code of the Go compiler and standard libraries. Well... I have reviewed the Go runtime, after I ran into a bug in it... And that's one of the reasons I no longer use Go unless forced to. That thing is ugly under the covers. There is seriously quite a…

I ran into a speed issue last year messing around with Go RSA keys. Turns out it's an open bug. Even though fixes have been made (see links in the thread), it's not a global fix and Go ciphers can be absysmally slow. https://github.com/golang/go/issues/20058 The recommended fix is to use a library like this one. However, that means your containers blow up with complicated dependency trees so it's not really a good so…

I don't know if using gmp for RSA is a good idea. I am pretty sure that gmp would open you to side channel attacks due to its operations not being constant time.

Re: Always Review Your Dependencies, AGPL Edition

#166

Post by kijin »

saagarjha wrote: post #124
rurounijones wrote: post #54

Earlier quoted context omitted.

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.

An even older tradition is a LICENSE file in the root of your project, which GitHub seems to read, but it's not great at matching up the license text to actual licenses.

An alternative tradition uses a COPYING file. I'm not sure which is older, but most GNU projects use COPYING instead of LICENSE. Meanwhile, some projects use COPYRIGHT or other variation, BSD-style licenses are often added directly to source files, and properly applying LGPLv3 to your project involves adding a separate COPYING.LESSER file. It's a mess.

Re: Always Review Your Dependencies, AGPL Edition

#167

Post by correct_horse »

fmajid wrote: post #85
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…

There are over 200 OSI-certified open source licenses, and no automatable way to handle them.

I count 97 (https://opensource.org/licenses/alphabetical), but point taken.

Maybe there should be an organized effort to make some sort of compatibility matrix for all the OSI licenses...

Re: Always Review Your Dependencies, AGPL Edition

#168

Post by steveklabnik »

galangalalgol wrote: post #156
ncmncm wrote: post #78

Earlier quoted context omitted.

It's not just you. Screaming heebie-jeebies is exactly the correct response. People who don't worry about it tell themselves that nothing that matters very much is coded in javascript, obvious exceptions notwithstanding. Maybe the only practical way left to avoid it is to avoid javascript for things that matter, and to avoid products constructed with javascript for uses that matter. This might be an unpopular observa…

Indeed, rust is a likely wasm choice and it is working on an npm nightmare of its own with crates.io. A blessed crates pack is sorely needed to fill out the intentionally thin stdlib in cases you can't afford a dependency tree 20 layers deep for all the reasons mentione on this thread.

Several people have tried the "blessed crates pack" over the years, but they never gained traction, so people stopped working on them.

Re: Always Review Your Dependencies, AGPL Edition

#169

Post by matheusmoreira »

baby wrote: post #151
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

Rust is on this path as well, the small standard library pretty much forces people into using a ton of tiny dependencies. Compiling a rust project is exactly like using npm and seeing a never ending list of deps

The underlying problem is the lack of curation. Micro-dependencies that are widely used and have been reviewed for quality should be promoted to a group of standard packages. They'd still be dependencies like any other but they'd be officially maintained and installed by default.

Another problem with npm: every package gets its own copy of its dependencies. Not sure if Rust does that.

Re: Always Review Your Dependencies, AGPL Edition

#170

Post by vmchale »

cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

> Nobody except me seems to see a problem there, despite me being able to point out specific security incidents.

The npm model is a shitshow (multiple versions of one dependency). People defend it for obviously self-interested or lazy reasons.

Post reply on HN