Open Source Licenses in 2020: Trends and Predictions | Hacker News Reader

Open Source Licenses in 2020: Trends and Predictions

whitessource.com

11 pointsWoodenKatana9 comments

What is the basis for these stats? new projects? new repos? new files? new commits? the lack of details makes me wonder.

The older post [0] has some info:

> Our research team analyzed our database of over 3M open source components and 70M source files, covering 22 programming languages.

[0]: https://resources.whitesourcesoftware.com/blog-whitesource/t...

And to what degree are the numbers skewed by the proliferation of "left-pad" tier libraries on npm?

Aside from the stats, which are not really surprising, I still find it very hard to get my head around licensing and I bet that this is the main reason why MIT is used. MIT is indeed the only license that is really understandable.

The mentioned choosealicense.com is not really helpful with choosing a license because it not really explains all the legal terms used, in my opinion. There are many blog articles out there but to this day I couldn't find a single overview that describes each of the major licenses in a regular-human way. And this overview is what I would need. Simple language, tailored to the most important questions: copyright, attribution, what can both non-commercial and commercial users do and what not, and what are my rights as the owner. If you have any resources on this please share it!

The only way to understand the fundamentals of licensing is to hire a lawyer. Because if you are unwilling to hire a lawyer, it doesn't matter how you license the software or whether you license it or not. The only person who can enforce the license for your software is you. And that requires paying lawyers. If you really care about what people do with your code, closed source is the way to go.

On the other hand, the big difference between licenses is how easy it is to incorporate contributions. That is why Linux thrived under GPL. It's why the formality of Apache's process is well suited for corporate contributions where participation will be vetted by the legal department...and why Apache is less suited for an ecosystem like Javascript.

> Changes to licensing in leading open source projects like Mongo DB and Redis are reminders that...

That the author should do their homeworks and get the facts right. Redis is BSD licensed for 10 years now. Redis modules by Redis Labs, never a part of the Redis core, changed license.

Article flagged because I can excuse a casual commenter here but if you write an article about OSS licensing and are not able to show facts in the correct way, for me there is no place on the HN top positions.

If you choose to profit off a common brand you also have to live with the fallout of that choice. You can't use the Redis name only when it's convenient and say "but that's not real Redis" else.

Those "Redis" named products were open source and now are not.

To be honest in the community it is crystal clear what "Redis" refers to, there could be confusion about the project organization itself versus the company (Redis / Redis Labs), but people now that Redis is what they normally use, download from Github and so forth. So there are no excuses.

I don't have a dog in the fight. I'm just reading the article casually. I understand the point you are making and have some sense of why Redis has the license structure it has. I don't have any criticism of it. I'm glad for its success.

The description of Redis would be out of place in an article about Redis. For an article about licensing, the statements about Redis are not a terrible way of pointing out that there are a myriad of flavors in the world of open source. The description has cosign similarity not relational calculus's exactitude. But I still see why it might elicit your response.

Anyway, thanks for all the fish.

Reply on news.ycombinator.com