Live data from Hacker News

Always Review Your Dependencies, AGPL Edition

agwa.name

31–40 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#31
post #2

That's the hidden cost of npm, cargo, pip, et. Al. The other one is IMO akin to overweight. Try to modernize a mid-sized project after one or two years and cry when you see the dependency graph. Ceterum censeo go inferior est.

If you define the "modernization" as mindlessly switching to a trending framework or library, the cost is inevitable even without package managers.

Re: Always Review Your Dependencies, AGPL Edition

#32

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.

Re: Always Review Your Dependencies, AGPL Edition

#33
post #12

It's always been weird to me how Microsoft invests so much in making JavaScript easy to develop and maintain with TypeScript but does so little to make it safe, the one thing JS needs is a standard library by Microsoft (or similar, e.g, Google) that we can trust, aiming to significantly reduce the number of dubious-origin dependencies of every JS project (on node and the browser)

Here's another opportunity to point out this unfortunate licensing bug in TypeScript's standard library: https://github.com/microsoft/tslib/issues/47 (Disclaimer: I like TS, but I filed the above bug.)

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"??

Re: Always Review Your Dependencies, AGPL Edition

#34
post #19

Not sure about this bit: > This is quite a bit of work, but is necessary to avoid falling victim to attacks like _event-stream_. Reviewing dependencies is important, but I don't think anything the author mentions would have made a difference with event-stream. The whole issue there was that malicious changes were snuck in via a change of maintainers and a later update to a child dependency, so when people initially a…

He talks about reviewing dependencies when they are updated, as well, which certainly would help if someone snuck in malicious code in a minor version change.

Re: Always Review Your Dependencies, AGPL Edition

#35
post #13

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…

There is https://www.fossology.org/ which helps a bit.

There are a lot of tools in this space:

https://wiki.debian.org/CopyrightReviewTools

Re: Always Review Your Dependencies, AGPL Edition

#36
post #20

Earlier quoted context omitted.

Yeah, remember the left-pad incident? It took until ECMAScript 2017 to make such a simple function part of the standard library. Things are slowly getting better, but JS is still rather lacking compared to "batteries included" languages like PHP and Python.

This comes up pretty often, what would you like to see in such a standard library? I consider the libraries included in Node pretty extensive these days.

Node is a tiny part, the big fish is JavaScript in the browser

Re: Always Review Your Dependencies, AGPL Edition

#37
post #12

Earlier quoted context omitted.

Here's another opportunity to point out this unfortunate licensing bug in TypeScript's standard library: https://github.com/microsoft/tslib/issues/47 (Disclaimer: I like TS, but I filed the above bug.)

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"??

Check out the CC0 license and its justifications:

https://creativecommons.org/share-your-work/public-domain/cc... https://creativecommons.org/publicdomain/zero/1.0/

Re: Always Review Your Dependencies, AGPL Edition

#38

It's always been weird to me how Microsoft invests so much in making JavaScript easy to develop and maintain with TypeScript but does so little to make it safe, the one thing JS needs is a standard library by Microsoft (or similar, e.g, Google) that we can trust, aiming to significantly reduce the number of dubious-origin dependencies of every JS project (on node and the browser)

Google has already developed a good featureful JS library. It's called the Closure library. It can be used independently or together with the Closure compiler. It's also more than a decade old, ensuring widespread compatibility, though not necessarily using modern idioms.

Some communities like the ClojureScript uses it extensively and a front end project in ClojureScript require very few dependencies.

Re: Always Review Your Dependencies, AGPL Edition

#39
post #12

Earlier quoted context omitted.

Here's another opportunity to point out this unfortunate licensing bug in TypeScript's standard library: https://github.com/microsoft/tslib/issues/47 (Disclaimer: I like TS, but I filed the above bug.)

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"??

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. 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. (The CC0 page at https://creativecommons.org/share-your-work/public-domain/cc... explains this well.)

Alternatively, you can use WTFPL, which is a really great way of putting your works in the public domain while guaranteeing that bigcorps won't use them (see: statements on HN by Google people, passim).

Re: Always Review Your Dependencies, AGPL Edition

#40

When this webpage loads, it briefly flashes in plaintext before loading CSS - at least in Chrome. This is unusual since it has the CSS stylesheet in the head which I thought would block until it's fully loaded. Does anyone know what's going on with that?

This is what happens when you dynamically insert your CSS tag in the head after the DOM loads.
Post reply on HN