The "as much of an art project, as an applied cryptography exercise" take resonates a lot!
Just earlier this week I've released https://github.com/kirushik/paternoster (and even won Berlin Hack and Tell with it) — and it totally came from the idea "in that state-enforced Max messenger there so much surveillance you can only praise the authorities and pray in there. What if there was a way to hide messages into the text of Church Slavonic prayers?"
I've even added TTS (where supported) to it, just for the giggles of getting the "TRUMP" dictionary thorough it.
It's still a pretty solid X25519+AES-GCM encrypted messaging design under the hood, and I'm happy with it — but it still a bit of an afterthough tbh...
Well, Minich's return to MS tech oddly coincides with MS Germany moving their HQ there (and the ruling party change in the city); it's of course hard to explicitly call backroom deals on this (even though ex-mayor seems to be doing exactly that: https://www.linux-magazin.de/ausgaben/2019/10/interview-2/), but it might be that the decision wasn't fully technical.
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...)
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...
For me in Europe, Google Maps coverage quality can be best described by this personal anecdote.
I used to live in Nürnberg, which is in top 10 German cities by population, and where are some major and well-recognized international companies are headquartered.
Nürnberg has a subway system (U-Bahn) since 1980s, and it's significant enough: a few dozen stations over three lines (one is fully driverless, btw).
Google didn't have any representation of U-Banh in Nürnberg till at least 2017.
I don't mean "wasn't supporting it in navigation and routing", I mean " stations weren't even marked and labelled on the general overview maps.
And it's not like they didn't have the into: there was a widely-used user layer which added at least station labels.
They just simply didn't care enough, and had other priorities.
In the meanwhile, the level of detail on OSM covered details as minor as every mailbox not only in Nürnberg, but in every small town around Frankonia (I used to participate in postcrossing and used this a lot from random places).
Yeah, and I failed to even find an option to open a local HTML file on mobile Firefox (for Android) just now.
That's a shame — things were definitely different in 2019 when I built the initial version; and mobile browsers were definitely a target I had in mind for the tool (especially when it comes to the recovery).
Instead of wrapping the existing tool into a mobile app, I'm thinking about standardizing the QR code format from the tool a bit more — so multiple, more task-specific recovering mobile apps would be possible. (Like, the one in your password manager detecting certain internal text formatting and importing the entries automatically and such).
We probably shouldn't even bother recommending browser-specific offline modes; I've created an issue in the project's repo to reword that piece by the next release.
Would it be too much to ask for you to open an issue in Github for this?
Things I'd be interested in the most would be details about your environment: browser/version/platform and if this is reproducible in a "fresh" browser profile without any extensions added (or just a list of your extensions, if that's not too privacy-invasive for you).
OK, since we're pitching our SSS implementations here in comments, I welcome everyone to check out BananaSplit, https://bs.parity.io
Not sure about year 2023, but at the time I wrote it for my previous employer there was nothing remotely usable for regular user.
Thus, BananaSplit.
It doesn't allow you to specify many parameters (just the number of shards, and then requires 50%+1 to recover); aimed at printed backups (generates printable full-page QR codes, while asking to copy a decryption phrase to the pages by hand to avoid an "evil printer" attack); and takes the concept of _portable web app_ to its extreme, being a self-contained single html file which requires you to save it locally and open via file:// protocol for it to work.
Disclaimer: while being in use for years, the code had never seen a proper independent code review; there might be bugs, despite me trying to minimize their impact by design, and using only reputable (and pretty minimalistic) JS primitives.
If you want to check out the sources yourself before using, of course those are available under GPL at https://github.com/paritytech/banana_split/
The idea is that our taxonomy selects a group named "trees", but there's little internal coherence in that group, which probably results in more online hilly wars in the plant-loving communities than we the laypeople can think of.
Does this imply that GPS satellites are a legitimate military target for Russia right now? (I'm pretty sure GPS is used for guidance of drones and missiles pretty heavily there.)
Or for a satellite top be a legit target the communication needs to be two-way? In such case I suspect Türksat satellite should be considered within scope, since Bayraktar TB2S (which reportedly has been used by Ukraine in this war) uses it for SATCOM.
What about other military uses of Starlink, outside of guidance systems? Those are plentiful, and it's hard to see why there would be a drastic difference between guiding a drone and providing communication backbone for military operation coordination in the eyes of the Russians. After all, they are bombing civilian infrastructure just fine, and didn't even care to formally declare this "special military operation" a war...
My point being, I don't think "legitimate target" has to do anything with Russia not shooting down any satellites; it's either lack of capacity or fear of retaliation, both being rather orthogonal to the targets "legitimacy" IMO.
Grimmsc version is a bit weird then, because there is a plausibly-sounding "freundian" interpretation of the most common folklore version, in which a frog turning into a prince after being kissed is a thinly veiled metaphor for fellatio.
That said, in the most common Russian folk version it's *Princess* Frog (Царевна Лягушка), and the metaphor is not working that well once again.
It still has limitations (the biggest one is the requirement for the os&architecture to match between the builder and the deployment target) — but the result is a standalone binary which not only embeds the VM and preloads the app's bytecode, but even "trims" the stdlib to only ship the required functions.
Fun fact: Russian translation of Dancing men is legitimately solvable, with messages being _in Russian_!
The translators had to butcher the characters' names and twist the deduction logic here and there — but it's still a marvel of localization work (especially given the languages, grammar and even alphabets being very different).
I've wrote https://bs.parity.io/#/ exactly for this; it also tries to avoid the most obvious opsec mistakes, like trusting your printer too much =)
BananaSplit is of very experimental quality, it hasn't been battle-tested and independently reviewed yet.
But at least it's there, it's FOSS, and I encourage you inspecting the code, contributing to it, or re-hosting the HTML.
Judging from the discussion in [1], the "going down this road" already started to happen about half a year ago.
Please notice how everyone in conversation seems to implicitly understand that their customers won't like the new forced telemetry, but still pushing on this, "for customers' own good" (with the only possible exception being made for public sector customers).
Parity Technologies builds blockchain software in Rust. We're probably the only team in the world successfully reimplementing both Bitcoin, Ethereum and ZCash nodes from scratch. We only do opensource development, and are practicing Programmer Anarchy (https://www.parity.io/engineering-at-parity-what-its-like/) as our main development methodology.
We're currently focusing on Parity Substrate, our framework/toolkit for building blockchains in Rust, and are growing steadily.
I think it would be safe to assume that the author knows pretty well how to use git and github: https://github.com/tonsky/
Probably, while his own commit messages seem to be consistent and informative, he spent too much time looking at repos of other people, where it is not so.
Since I frequently have the same feeling when exploring potential dependencies for my projects, so yes, changing the Github UI to accept the status quo seems more logical for me, than trying to reeducate all the developers in the world to follow the universal guidelines for commit messages sensibility.
Another possible take on this would be Parity Signer (https://www.parity.io/signer/), which is an opensource app turning your (full-disk encrypted and put into an airplane mode) old phone into an improvised hardware wallet.
Very narrow attack surface (no USB or Bluetooth, only QR codes are used for communication), and more safety against the supply chain attacks make it a viable alternative for some particular threat models.
Just earlier this week I've released https://github.com/kirushik/paternoster (and even won Berlin Hack and Tell with it) — and it totally came from the idea "in that state-enforced Max messenger there so much surveillance you can only praise the authorities and pray in there. What if there was a way to hide messages into the text of Church Slavonic prayers?"
I've even added TTS (where supported) to it, just for the giggles of getting the "TRUMP" dictionary thorough it.
It's still a pretty solid X25519+AES-GCM encrypted messaging design under the hood, and I'm happy with it — but it still a bit of an afterthough tbh...