Hacker News Reader

Comment by jkarni | Hacker News Reader

It isn't open-source yet (and might never be). But it also might, as I said in a sibling comment, I've been thinking about a license that would require only running it (and derived software) on green energy; that way, if competition were to arise, cheaper/dirtier energy wouldn't be what we would be competing on. But figuring out whether that's plausible, and what the consequences of the decision would be, is hard.

(In general the idea of a license that's viral like GPL, but oriented towards green and renewable energy, seems like an interesting thought to me.)

View on HN

I doubt you would care very much (not many do), but this is a problem for those among us fortunate enough to be born in so-called "developing" countries.

I am from one where we still burn coal for heat (along with plastic bottles, tires, and rubber). You can imagine the impact of the electricity produced here. Yet there are IT jobs here and we're using many of the same products you do.

I've been using Drone and GitLab CI for years and likely won't be using anything like what you're describing because green energy is simply not available, and probably won't be for the next 50 years at the very least.

Hosting CI on the other side of the planet is a no-go for various reasons (we self-host everything since it makes a lot of sense for us).

I do care. I also was born in a developing country. (Though the correlation between development of country and proportion of green/renewable energy usage is I think quite low (and might not even be positive?) [0].)

I think access to software and services shouldn't be be based on the country you happen to live in, and I wouldn't want to contribute to that. But I would have thought either using a hosted service, or else self-hosting in a different country, are almost always options. Why is hosting CI on the other side of the planet for you a no-go?

(Also, I think right now a license that simply says "must be run with renewable energy" is infeasible almost everywhere still.)

[0] https://en.wikipedia.org/wiki/List_of_countries_by_renewable...

what about "you may run this locally on your, or your organization's servers, but you cannot offer it as a free or paid service?"

That makes sense!

Except that it isn’t then free software. Nix and its ecosystem is all free software, and it seems incongruous for people to build nonfree tools on top of and around it.

That's a pretty huge violation of layer isolation. Software should focus on being hardware efficient, hardware on being energy efficient, and energy on being CO2 efficient. If you want clean energy : great I'm 100% with you but a software license is not in any way the right approach for this. You software license is 10 degrees of separation removed from anyone having the slightest impact on the decision to build X or Y power plant. Please use political means to solve political problems.

You can modify GPL with an additional clause. Kinda like JSON did to the MIT license with their do-not-use-for-evil morality clause. Of course the project then will be considered non-free by both FSF and OSI. Ironically installation via Nix if it's put on nixpkgs will then require enabling allowUnfree.

That is true, and to add: If you are not careful with your additional clause you easily violate Debian's Free Software Guidelines (DFSG). The guidelines are used to determine whether your software can be included in Debian. If that is important to you a clause that adds additional restrictions (like green energy use) is out.

It's if anything better that way. The commitment would have to be one you consciously take on, after all.

I think you might be mixing JSON up with jslint? The famous story is that Crockford gave a license to “IBM and its minions” to use the software for nefarious purposes as a joke when their lawyers asked for an exclusion.

Nope, JSON. See: https://www.json.org/license.html. It was first used for the reference Java implementation (initially found in http://www.json.org/java/index.html; then https://github.com/douglascrockford/JSON-java). JSLint also used this license until few years ago.

You can modify the GPL with an addition term that requires the use of green energy, but the resulting license is incompatible with the GPL with the result that code under the new license cannot be mixed with or linked with GPLed code. See section 7 ("additional terms") of the GPL:

https://www.gnu.org/licenses/gpl-3.0.en.html

(the GPL version 2 also has this property.)

Also, its unusual license is probably why jslint is not used much.

Used jslint extensively back in the days.

The reason why it fell mostly in disuse nowadays is because jshint appeared, which allowed a lot more customization of the available rules being applied.

Later eslint popped up with it's plugin engine allowing anyone to have their own custom set of rules.

As far as I know, no one cared about jshint's license because there was no code being shipped, and eventually code would be minified anyway leaving no traces of jshint.

Now... We can talk about the morality of ignoring a license, but ultimately jshint's license was simply ignored by almost everyone

You don't necessarily have to enable `allowUnfree` entirely. There's also `nixpkgs.config.allowUnfreePredicate` which lets you define a predicate that takes a package and decides if it's okay to install.

I see. Interesting idea with the green energy. But basically a non-opensource CI would be very difficult to justify due to the vendor lock-in. Yet I'm using github-workflows out of convenience...

I've never worked anywhere that used a FOSS solution for CI. We currently use buildkite, my last two jobs used TeamCity and another job used Electric Commander (!).

We don't care about vendor lock in, we can rewrite the build scripts. We care about support.

There's not really space for lock-in with garnix - you really only need a flake.nix file, nothing garnix specific (or more precisely: at most a very simple 5 line YAML file). The idea is that "normal nix" is enough.

The only lockin here is convenience, garnix builds the existing outputs from your flake.nix, and there are already self hosted options which work the same way.

Not nearly as bad as writing a bunch of custom github actions or travis CI yaml files and needing to move.

You can replicate garnix's checks with much worse UX and less parallelism on any other service with a few lines of shell calling `nix flake check` and `nix build`. Making the UX good is left as an exercise for the reader.

Ah interesting. Thanks for the explanation.

So essentially no then

Decidedly no.. just like they said very clearly.

Reply on news.ycombinator.com