I find it slightly disappointing that the author ended up with Apache 2 as the software license for his new project without any further justification. Even though the author clearly outlined problems with Eric Raymond style open source he doesn’t draw upon these reflections when deciding the license for his new decentralised project. He remains in the status quo and makes himself and his project vulnerable to all the issues he made the reader aware of.
The tangent about copyleft is not the most important part. GPL would not have improved the npm situation in any way. The central problem discussed in the article is the VC-backed private control of the npm registry (which runs proprietary software, not permissively licensed software). Entropic is designed for people running their own registries, the registry software is designed for federation/mirroring.
I trust you already know this but BSD-licensed distributed systems always devolve into SaaS businesses that give little back to the creators of the tech they are based on, e.g. most of AWS. With GPL, the Entropic team has a lot more leverage on the ecosystem.
It’s an interesting idea: BSD, VC-backed vs GPL, Community-driven.
SaaS providers don’t need the original software all that much, they can reimplement APIs just fine.
If the whole idea from the beginning is a federated replication protocol (like here),
SaaS can just implement it from scratch anyway; and
community members just have to resist the SaaS temptation individually, fairly, without licensing tricks.
Even legally forcing hosting companies to release their modifications (which I’m not sure even AGPL does, isn’t that only achieved by the Commons Clause type crap?) doesn’t necessarily prevent SaaS expansion. It reduces the risk of embrace-extend-extinguish, but a lot of times people don’t use SaaS because of exclusive modifications and features, just the convenience of someone else taking care of the servers.
It looks to me that the comment pretty much answers your first question already. Although I appreciate the comment never stated that the Apache-2.0 license is bad for the project. Honestly I too was initially struck by the fact that despite “the author clearly outlined problems with Eric Raymond style open source he [sic] doesn’t draw upon these reflections”. On the other hand, the author of the article also comments that she thinks “it’s good for us as humans to give things to each other, and I think I’m at peace with the idea that some corporations will make money from it.” I guess it’s not a matter of justification but rather of acceptance, from what I can draw from this reading.
Regarding the second question, I would say that choosing the GPL would have felt more inclined towards the spirit of the comparison between open source and free software (what the author originally refers to as ESR- and RMS-style open source). On the other hand, given the remark I quoted from the article, choosing a license has also to do with your objectives. If you are “at peace with the idea that some corporations will make money from it” and you may want enterprise customers to be attracted by the product, the GPL can be quite a hurdle, as the General Public License is sometimes treated as poison, as the article itself recognizes.
Within the context of also introducing a possible replacement for NPM, as the article ultimately does, I believe choosing a permissive license is a smart choice, especially as the aim of the project, from what I read from the article, is to offer a way to put the control of the commons into the hands of the community, rather than one private entity.
Yes, I’m not saying Apache-2.0 is bad for the project; I just felt that this new project remains susceptible to a lot of the issues the author raises with NPM. (And I’m sorry for using the wrong pronoun for the author in my original comment.) A license which forces sharing of derivative source code could help if for example the author of the article in the end goes the same route as the author of NPM and gives authority over the registry comes to a VC held firm.
Note that I never mentioned GPL in my original comment and never suggested it to be the solution. Though I do want to point out that the GPL and AGPL does “allow for corporations to make money from it”. But they do scare corporations; perhaps because it makes it a little harder for a private entity to do what the original author opposes in her article.
I don’t know which license she should have chosen. I guess I just wanted the argument to end up in a solution and not in the status quo. The solution could be anything. Perhaps I am missing the point and the implementation of her repository prevents corporate capture.
The other confession I’ll make is that I believe in the potlatch economy despite everything. I think it’s good for us as humans to give things to each other, and I think I’m at peace with the idea that some corporations will make money from it.
I am the one who gave the talk with a kid in attendance. The talk was about Apache Spark and the mother thought it was an Opera set in the Far West. It is to the day a running gag in the Italian Scala Slack channel.
I’m guessing “peerl”, although I’ve never heard anyone using this pronunciation. It also sounds funny to my Italian ears, as “pirla” (pronounced “peer-la”) means “silly person” in Lombard dialect.
Straight, with ‘e’ instead of ‘ae’-sound - as in [I am not a native English speaker] … well, sort of like if you take the sound by clicking on UK here https://dictionary.cambridge.org/pronunciation/english/pair and add an L to the end. Almost rhymes with the fruit pear.
I find it slightly disappointing that the author ended up with Apache 2 as the software license for his new project without any further justification. Even though the author clearly outlined problems with Eric Raymond style open source he doesn’t draw upon these reflections when deciding the license for his new decentralised project. He remains in the status quo and makes himself and his project vulnerable to all the issues he made the reader aware of.
The tangent about copyleft is not the most important part. GPL would not have improved the npm situation in any way. The central problem discussed in the article is the VC-backed private control of the npm registry (which runs proprietary software, not permissively licensed software). Entropic is designed for people running their own registries, the registry software is designed for federation/mirroring.
I trust you already know this but BSD-licensed distributed systems always devolve into SaaS businesses that give little back to the creators of the tech they are based on, e.g. most of AWS. With GPL, the Entropic team has a lot more leverage on the ecosystem.
It’s an interesting idea: BSD, VC-backed vs GPL, Community-driven.
SaaS providers don’t need the original software all that much, they can reimplement APIs just fine.
If the whole idea from the beginning is a federated replication protocol (like here),
Even legally forcing hosting companies to release their modifications (which I’m not sure even AGPL does, isn’t that only achieved by the Commons Clause type crap?) doesn’t necessarily prevent SaaS expansion. It reduces the risk of embrace-extend-extinguish, but a lot of times people don’t use SaaS because of exclusive modifications and features, just the convenience of someone else taking care of the servers.
Why is Apache bad for her project? Which license should she have chosen?
It looks to me that the comment pretty much answers your first question already. Although I appreciate the comment never stated that the Apache-2.0 license is bad for the project. Honestly I too was initially struck by the fact that despite “the author clearly outlined problems with Eric Raymond style open source he [sic] doesn’t draw upon these reflections”. On the other hand, the author of the article also comments that she thinks “it’s good for us as humans to give things to each other, and I think I’m at peace with the idea that some corporations will make money from it.” I guess it’s not a matter of justification but rather of acceptance, from what I can draw from this reading.
Regarding the second question, I would say that choosing the GPL would have felt more inclined towards the spirit of the comparison between open source and free software (what the author originally refers to as ESR- and RMS-style open source). On the other hand, given the remark I quoted from the article, choosing a license has also to do with your objectives. If you are “at peace with the idea that some corporations will make money from it” and you may want enterprise customers to be attracted by the product, the GPL can be quite a hurdle, as the General Public License is sometimes treated as poison, as the article itself recognizes.
Within the context of also introducing a possible replacement for NPM, as the article ultimately does, I believe choosing a permissive license is a smart choice, especially as the aim of the project, from what I read from the article, is to offer a way to put the control of the commons into the hands of the community, rather than one private entity.
Yes, I’m not saying Apache-2.0 is bad for the project; I just felt that this new project remains susceptible to a lot of the issues the author raises with NPM. (And I’m sorry for using the wrong pronoun for the author in my original comment.) A license which forces sharing of derivative source code could help if for example the author of the article in the end goes the same route as the author of NPM and gives authority over the registry comes to a VC held firm.
Note that I never mentioned GPL in my original comment and never suggested it to be the solution. Though I do want to point out that the GPL and AGPL does “allow for corporations to make money from it”. But they do scare corporations; perhaps because it makes it a little harder for a private entity to do what the original author opposes in her article.
I don’t know which license she should have chosen. I guess I just wanted the argument to end up in a solution and not in the status quo. The solution could be anything. Perhaps I am missing the point and the implementation of her repository prevents corporate capture.
I think this paragraph is the reasoning?
The Node.js bindings for the DAML smart contracts platform. Still quite immature, would love feedback.
Repository is at https://github.com/digital-asset/daml
I am the one who gave the talk with a kid in attendance. The talk was about Apache Spark and the mother thought it was an Opera set in the Far West. It is to the day a running gag in the Italian Scala Slack channel.
I like the name “Perl”, because it can be pronounced in (at least) two ways, and a Perl slogan was “There is more than one way to do it”.
It also has an irreverent backronym expansion, if you want.
I also like “Miranda”, because it sounds friendly.
In which way can Perl be pronounced other than “pearl”?
“Peril” /s
I’m guessing “peerl”, although I’ve never heard anyone using this pronunciation. It also sounds funny to my Italian ears, as “pirla” (pronounced “peer-la”) means “silly person” in Lombard dialect.
Straight, with ‘e’ instead of ‘ae’-sound - as in [I am not a native English speaker] … well, sort of like if you take the sound by clicking on UK here https://dictionary.cambridge.org/pronunciation/english/pair and add an L to the end. Almost rhymes with the fruit pear.
Lua means “moon” in Portuguese. Lua was originally developed in Brazil.
Also, IIRC Lua was developed after SOL which was another language built at PUC but I believe SOL was some form of acronym while Lua is not.
Ps: I LOOOVE Lua
And it inspired Terra, cause the earth is more low-level than the moon.