Two people declined to re-license their contributions to Racket. We therefore removed their contributions and, where appropriate, replaced them with new code and/or documentation.
The GPL relies on copyright as far as I understand.
The two declining authors don't have copyright on the new replacement code, because they didn't write it. So their choice of license can't possibly have any bearing on the license of the rest of the project.
A similar thing happened when the busybox maintainer forked the project to toybox.
busybox is a GPLv2 project (not LPGL), and so all his contributions were licensed as such. But he forked his own code to a Apache 2 License. He is able to do that because he owns the copyright. But of course he can't relicense code to which he doesn't own the copyright.
toybox isn't a derivative work of busybox in that sense. It's just a bunch of code that someone wrote (and automatically gets copyright for), and chose to license in a certain way.
Basically you get the copyright first, then you decide to license it. If it's clearer to think about, the authors could have started a new project called "Zacket" that's not a derivative work of Racket, as long as they own all the copyrights. But the name doesn't matter here, and they can keep using "Racket".
> The two declining authors don't have copyright on the new replacement code, because they didn't write it. So their choice of license can't possibly have any bearing on the license of the rest of the project.
But they influenced the shape of the code.
Imagine if Google loses their upcoming case with Oracle. Any rock thrown into the river will forever taint a codebase unless you can rewind before it was committed or the code is 100% leafy and isolable.
Does Racket use a DVCS? A git checkout involves making a copy of every historical version in addition to the current one, so their code is still being distributed. If a lawyer wanted to make trouble, they could argue that the repository as a whole is a single work and thus must remain on the GPL.
Each version presented by the VCS contains a copy of the GPL.
The GPL for Version 1 (example) would be presented if you checked it out and if you check out Version 2 it's now an Apache 2 license. The license in each case applies to the files in the VCS, a the GPL contains no special case for access to previous or future versions of the same file under it's license under the GPL license, neither does the Apache license and I doubt such a clause would hold water.
Yes, Racket uses Git. Which things are and aren't a derived work of other things is a complicated question which is, for example, the subject of a big lawsuit between Oracle and Google, and I won't pretend to give a final answer here. But we did follow the advice of our attorneys as part of the Software Freedom Conservancy (one of the big benefits of joining SFC is having such attorneys who know about free software copyright law).
IANAL, but pretty much no. GPL covers software that is linked against GPL software or containing any GPL software. Just having a GPLed file present, especially if it is in the past, does not affect anything not depending on the GPLed file. Products routinely ship together with GPLed software without falling under the GPL, as long as the non-GPL program does not depend on the GPL software, doesn't link against it or doesn't use any source under GPL.
IANAL, but I think of the relicensing effort as conceptually equivalent to starting from scratch and asking everyone to re-contribute their code towards the new codebase, because these contributors never relinquished their copyright in the first place. For people who said no, you just leave out their contributions.
replace the code? I'm not sure how it would not be legal to write substitute code under a new license. If there is no remaining GPL code in a project, the project doesn't have to abide by the GPL. The "Ship of Theseus" example makes no sense in the context of copyrights.
If the new code is a clean reimplementation of the function of the old code, that is, not based in its source or principle of working on the old code (e.g. copy large parts of the logic from the original code), it should be quite fine. Porting an existing code to a new language isn't a clean reimplementation.
but you can take the 98%, and also relicense it under anything the copyright holders (=authors) agree to, and include an extra 2% so that it is a new work.
I've seen a ton of people make that mistake, though. I think it's because what you write is accurate - "refs are meant for values that don't need to trigger a rerender" - but most people think of refs (or at least refs of DOM elements, which for many people are the only refs they ever use) as just a way to access a DOM element. They expect it to just be a DOM element in a normal variable.
I'm not sure if there is a less confusing way of doing it, but it's damn confusing.
But it's a pretty straightforward rule once you know it right?
This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs.
Once you know refs updates won't re-render, you won't make this mistake.
I don't understand why "a thing you need to learn then you're good" is somehow inherently more complicated than ... other apis that you need to also learn.
> but most people think of refs as...
This sounds like Dan Abramov's comment that some of the struggles with hooks is from people who have experience with react without hooks, vs people coming new to the whole thing. So maybe it's about relaxing pre-conceived notions until experience takes over.
Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune.
Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated.
Now that I'm thinking about it... what is the reason that DOM refs and other refs need to be handled by the same concept? Every time I make a DOM ref, I'm doing something with it in a hook like useEffect. Why make me jump through hoops to re-run the hook if the DOM ref changes?
(I recognize there are probably good answers to those questions, the React folks are great, I just don't know the answers! Is it just to avoid introducing one more "type of thing", and instead making refs and DOM refs the same "thing"?)
There's always need for escape hatches and maybe I'm missing your use case, but in the context of a discussion about how hooks are more complicated than classes, what were you doing before with refs to solve your "re-render" on change scenario?
Your example was likely contrived, but modifying innerHTML should be replaced by putting whatever in state and simply rendering it. And use state for dependencies where you want to re-run on change. Refs are just another way to keep state but not have it affect render cycle.
If you're not aware of that, it is very tempting to use `useRef`, which is what I have often seen. Before hooks, we did not have the temptingly-named footgun `useRef` for this scenario (although we did have other footguns for other scenarios, and overall I love hooks).
I don't think that can explain it, because IIRC that rule has only been around since Obamacare, but the US/world price disparity for prescription drugs has existed much longer than that.
Sometimes there are browser bugs that are impossible to do feature detection for, in which case have no better option than looking at the user agent.
For instance, several versions of Firefox had a serious bug in shared workers, which appeared intermittently when users opened your site in multiple tabs https://stackoverflow.com/questions/51092596/feature-detecti... - I had to use the user agent to work around this.
Sure, this is a fair use case. But then can't the browser tell the end user that someone wants to read this browser data so the user has a chance to say "no"?
Interesting title. If you just started building skills in software development, what would you focus on early, in terms of knowledge/experience, to make development "suck" less in a career?
20x more is not a sure thing, but for a disease like Alzheimer's that is already pretty common (e.g. we're not talking about risk increasing from 0.01% to 0.2%) it's more meaningful than just for entertainment purposes.
I agree with your wife that for most people their 23andme results will be nothing more than entertainment, but there are a handful of truly meaningful things it can find.
What does "rationalized" mean? Highly respected open access publishers like PLoS charge similar fees https://www.plos.org/publication-fees - maybe that's just what it costs to run a journal? If not, PLoS must be some ridiculously profitable scam.
PLoS is a non-profit with publishing fees up to $3000, so I think their point is that high costs are not simply profit but that there is a large cost involved.
This is a misunderstanding: “non-profit” does not mean that an organisation can’t earn money. It means the company cannot be sold, and all profits have to be reinvested (rather than e.g. paid out to shareholders). And PLOS, like for-profit publishers, has in the past had very large profit margins (and has been criticised for this, e.g. [1]).
> It means the company cannot be sold, and all profits have to be reinvested
Right, so the incoming money is spent on the company itself - so should represent the long term running costs, surely.
> And PLOS, like for-profit publishers, has in the past had very large profit margins (and has been criticised for this, e.g. [1]).
I'm not sure I'd say those are extreme, $5M on $50M in revenue. Even if you removed that you would still have APCs of ~$1450-2700 which I don't think would change the original point.
> PLoS is a non-profit with publishing fees up to $3000, so I think their point is that high costs are not simply profit
“Non-profit” does not mean an organization does not earn profits. It means that it is not a vehicle for returning profits to particular stakeholders (owners, shareholders, LLC members, etc.)
And I'd add that it's also not particular proof of efficiency. Non-profits can be amazingly effective at using money to further their missions. They can also be enormous boondoggles.
Is that actually allowed by the GPL? I thought it was more like the "Ship of Theseus" - that even if you eventually replace all the original GPL code, the entire work remains GPLed. https://softwareengineering.stackexchange.com/questions/2603...