When are you coming back to the WebRTC space, lots more cool stuff you could b doing :) I really loved [0] it's so cool that a user can access a server behind a firewall/NAT without setting up a VPN or having SSH constantly listening.
I don't think this is trivially fixed since you can still only have one writer that is holding the lease.
Your new service will come up, but it won't be able to get the write lease until the previous server shuts down. Now you have tools to detect this, stop one writer, and start the other, but the service will likely have to experience some kind of requests queueing or downtime.
Really nice to see this, I wrote this comment almost 2 years ago when I was a little miffed about trying to use litestream and litefs: https://news.ycombinator.com/item?id=37614193
I think this solves most of the issues? You can now freely run litestream on your DB and not worry about issues with multiple writers? I wonder how the handoff is handled.
The read replica FUSE layer sounds like a real nice thing to have.
> When another Litestream process starts up and sees an existing lease, it will continually retry the lease acquisition every second until it succeeds. This low retry interval allows for rolling restarts to come online quickly.
Yeah, this still doesn't answer: can I use this with agpl, gpl, lgpl, apache2, others. The summary on top seems to imply that it's not AGPL/GPL compatible since it talks about granting specific types of organisations some monetization privileges. It doesn't simplify what the rules are (what qualifies as use?), without having to read the licence itself.
On the first read it's basically: compatible with BSD-like and PPL... and not much else?
Yeah, the main thing I understand about PPL is that it behaves like the GPL license, but has provisions for worker owned cooperatives or non-profits. 4.c. (Looking at the information again around this license, I suspect I may be incorrect though)
And you are correct, including colorize does break GPL2, I'm surprised I missed that.
Disclaimer: I am not a legal professional (in any jurisdiction), and this is not any form of an official advice.
But I've happened to work as "engineer in licensing and copy activation" for one of the major FOSS vendors, and then being a licensing compliance officer in another large-ish FOSS project; and here are my 2¢:
You are indeed in violation of GPL2 when building on top of GPL2-licensed code and giving it a non-compatible license. And PPL is explicitly non-compatible, since it restricts the "four freedoms of FOSS" for some actors (as despicable as they might be), while GPL is explicitly restricting any form of judgement when providing the four freedoms.
On a more general note — I appreciate the spirit and the intention behind your licensing choice, but unfortunately in practice this would mean severe impediment for hokusai adoption.
Like, it would be technically hard/impossible to include hokusai and derived works into any software packets distribution: they both technically and by policy are usually restricted to "clear, well-known licenses" (which typically means OSI/FSF-recognized ones), and it might not even be possible to express your licensing choice when putting the code up there.
And who would pick a GUI toolkit to build with, when the resulting code can't even be published in the package repos of their Linux distro of choice?
On a more fundamental level (and I start feeling out of my depth here a little bit) — Creative Commons licenses and their derivatives are usually not a great fit for software code. Eg right here in the comments someone already mentioned that it's not clear what constitutes "use" of your codebase — and indeed, the text of your license mostly focuses on Reproduction, Distribution and Adaptation.
If I build and html-based webapp on hokusai, run it on my own server, and you open the page — is this Distribution or Reproduction, for whom of us?
Even worse, if hokusai is being used in a startup which assigned shares (not options) to its founding engineers, but not to everyone — is it a "worker-owned business" or not?
What about an exploitive business which frames itself as a coop/NGO/whatever, but frames it actual workers as contractors (Uber-style)? Legally it might pass the benchmark outlined in PPL, but in practice it might be even more exploitative than just hiring someone at the labor market rates. Same with an org which exploits unpaid interns or volunteers...
Thanks so much for the clarifying and thorough information.
I will admit that my choice to use PPL is reactionary to the ecosystems of software development as they are now, which I'm not sure GPLv2 addresses. I personally don't really understand why all information shouldn't be free without conditions. Cooperative ethos is also voluntary, so it also isn't my intention to enforce that.
That being said, I might have to think on it for a bit. Hokusai was originally made with Crystal lang, but now uses a Ruby interpreter, so a considerable portion of any derivative source will be available regardless of using the GPL or not. Could a more permissive license prevent an end-user from re-publishing these sources?
There is also an issue with resource allocation (eg. time). The reason I don't think the GPL works well is that most individuals cannot sustain the effort to fully develop many projects that could supplant competitive ones (a necessary condition for equity imo) because they have to live, and living requires money (time).
The closest model I am able to think of is software that has very cheap licenses for the lifetime of that project (as opposed to monthly subscriptions or licenses that are absurdly expensive). Maybe sponsorships are a better answer to these questions.
All in all, these are probably concerns with how companies and people exploit each other as opposed to how software should be available. Maybe GPL2 or a more permissive license is the way to go?
In my (limited) understanding, running your source code using a GPL-licensed interpreter to run the code is not considered _linking_, and thus GPL would not infect the code in question. (This is what allows even prorpietary code to run on top of OpenJDK, which is itself GPL-licensed).
In Ruby's YARV interpreter case it's even more straightforward — Ruby License is essentially "either our custom or BSD-2" (https://www.ruby-lang.org/en/about/license.txt), so no "infectious copyleft" happens when running software with YARV.
I'm a little bit uncertain with what you mean with "prevent an end-user from re-publishing", and what's a desired behaviour here: licenses differ in who they consider to be an end-user (that's the main difference between GPL and AGPL, for example) and if they give any end-user a blanket permission to **obtain** the source code (that's the most substantial difference between copyleft and permissive licenses).
WRT business models on top of FOSS — I fully understand the struggle. I cannot possible give any meaningful advise in hokusai's specific case (and arguably I'm even less qualified to do this than commenting on licensing intricacies, please keep this in mind) — but the successful business models in FOSS I've witnessed range from "this is our GPL-licensed code, but you can buy a proprietary non-copyleft rights from us if you're a commercial enterprise" to "this is your GPL-licensed source; if you don't want to deal with its', pretty complicated, compilation — you can buy binaries from us" to "hey, this is my Patreon/Github Sponsorship — if you want new releases to keep coming, put some money where your mouth is".
Feel free to email/message me (link in the profile), maybe I can help you find a setup which would be the best match to your ideas of how it all should work — hopefully without putting the further adoption of hokusai under unnecessary risk... (But, again, I'm just a random guy from the Internet, and all this would be just my pretty unprofessional opinion...)
I'll certainly open source the code! I just want the flexibility to change my rate limiting logic in the short term to counteract abuse. Happy to answer questions though!
Yes please open source. I tried something similar based one your checkboxes game! I never worked with websockets so I’m curious how you designed for scale and stopped spammers. I game was click the button 10M times and of course the script kiddies started immediately which is fun! But not my server keeps getting hammered with requests long after the initial interest. I did not know how to rate limit bots without blocking whole IP ranges.
fwiw I think the biggest single trick there is to group IPV6 addresses at the /48 or /64 level before applying rate limits (you can rate limit IPV4s on a per-ip basis).
It's kind of annoying and expensive to get a bunch of IPv4s to evade limits, but it's really easy to get a TON of IPv6s.
The other Big Trick I know is to persist rate limits after a client disconnects so that they can't disconnect -> reconnect to refresh their limits.
is there a reason you went with telegram and not slack or discord? i was thinking that it could open up a broader channel for communicating with your assistant. i understand you're also just building more of a poc, but curious if you'd thought about that. great work btw :)
reply