This often happens, the previous article didn't get any visibility so people post it again, not realizing. I think the old one is the dupe :-) We need a name for a "dupe that was ahead of its time."
Well, I'm steadily losing weight, down to about 65kg now from 76kg when I was diagnosed. I'm finding it harder and harder to eat, and I've steadily increased my painkillers from 10mg to 50mg or more per 12h.
So, clearly, things are not getting better. I'm dying and it is just a matter of what bed I die in, and whether it'll be a vital organ like the liver that gives up first, or euthanasia if the breathing gets too hard, and the pain too much.
What the extended horizon does is let me write a little more in that article (there are still stories to tell) and wonder if maybe it'll be enough for a book.
Weirdly the main emotion I feel is a kind of embarrassment at raising a false alarm that gets so many people worried. Also, happiness of course to still be alive and see my family & friends and chat a little more with people on the Internet :-)
This is a really good article. There's one part in particular that struck me:
"Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on the terms of the project’s existing license—what Richard Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t recognize any such rule. Strong copyright protection, not permissive licensing, is the default."
In other words the fork + pull request + merge flow does not work on a project unless you have an explicit step like a CLA, or an alternative solution.
We faced this problem early on in ZeroMQ, that asking contributors to take this extra step increased the work for maintainers (to check, is this the first time person X contributes, and have they made a CLA?) It also scared off contributors from businesses, where this often took approval (which took time and was often denied).
Our first solution in ZeroMQ was to ask contributors to explicitly state, "I hereby license this patch under MIT," which let us safely merge it into our LGPL codebase. Yet, again, another extra step and again, needs corporate approval.
Our current solution is I think more elegant and is one of the arguments I've used in favor of a share-alike license (xGPL originally and MPLv2 more these days) in our projects.
That works as follows:
* When you fork a project ABC that uses, say, MPLv2, the fork is also licensed under MPLv2.
* When you modify the fork, with your patch, your derived work is now also always licensed under MPLv2. This is due to the share-alike aspect. If you use MIT, at this stage the derived work is (or rather, can be) standard copyright. Admittedly if you leave the license header in the source file, it remains MIT. Yet how many maintainers check the header of the inbound source file? Not many IMO.
* When you then send a patch from that inbound project, the patch is also licensed under MPLv2.
* Ergo there is no need for an explicit grant or transfer of copyright.
I wonder if other people have come to the same conclusion, or if there are flaws in my reasoning.
A more dangerous side-effect of branding Tor as a "human rights" tool is that whereas if it's a "privacy" tool, people in oppressive regimes can legitimately use it (e.g. people working for such regimes), whereas as a "human rights" tool, its simple presence on a computer is evidence of guilt.
I disagree. I'm happy to install Linux from a USB stick. I'm not happy reflashing a BIOS. Have installed many, many laptops with Linux (ironically, my all time favorites are older Lenovos like the X220). I've not once flashed a BIOS.
Not being able to change the OS on a laptop severely reduces its aftermarket value too. My laptop originally ran Windows. I bought it second hand to run Linux on.