You can use LGPL licensed-software in your proprietary software, as long as you only link to it dynamically - i.e. you provide a clear separation between your software and the LGPL software.
5,648 karma · joined March 31, 2021
If you don't own the Qt copyright, you cannot sell Qt to a company who wants to use it to build a proprietary product - since Qt is GPL licensed, using it in a proprietary product would not be permitted.
But since The Qt Company owns the copyright, they can sell their own software to companies that want to build a proprietary product with it - they just sell it under a proprietary license, specifically tailored for this. The fact that it was previously released under GPL is irrelevant, because the copyright holder can license it under as many licenses as they want.
If you don't own the copyright to it, you can only """sell""" GPL software in a manner in which local DVD shops sold pirated movies back in the early 2000s.
You do, if sell means also allowing another vendor to use your software as a part of their proprietary software.
GPL alone, if you're not the copyright owner, would not allow you to sell software in this way. But if you are the copyright owner, you can bypass GPL and sell a proprietary license to the vendor saying "you can use this software in your proprietary product if you pay me $XYZ".
This completely disregards the fact that the "financial model of the closed fork" explicitly chose to build upon the permissively licensed original.
If the company chooses to build upon free software, they should be obligated to give back to the community from which they leech. Otherwise, they should just build their own thing from scratch with all the money they've hoarded, and keep it closed.
It uses mostly real (or contrived) segments of text, which appear as if they were taken out of newspapers or personal letters. It has both beginner and advanced sets of text, and a whole community of custom texts that you can use. I've personally learned touch typing from scratch by using this program alone.
Injuries generally cause brain to release endorphins, which in turn releases dopamine, causing addiction. For example, cutting is a common type of self-mutilation depressed people do. High-intensity exercise arguably also does the same thing - as your body is "microinjured" by strain, your brain releases endorphins to help with the pain, causing effects like "the runner's high".
> the side effect of addiction isn't going to go away
While I agree with your conclusion itself, I disagree that the premise implies the conclusion. The main difference between suzetrigine and opioids, as explained in the article:
Crucially, opioids don’t just kill pain: they also incite pleasure.
When the mu opioid receptors present in the reward center of the
brain are activated, this reduces the secretion of a neurotransmitter
called GABA, which works to inhibit dopamine-producing neurons. As GABA
release declines, dopamine spikes, lighting up the reward center and
inducing pleasure.
Since suzetrigine doesn't affect mu receptors in the brain, this mechanism doesn't apply.
But I'm almost sure it will have some other unintended side effects. Morphine had them, heroin had them, methadon had them... And each time the inventors were sure they didn't.
To me, it doesn't sound like you did. The parent comment of yours just stated, albeit bluntly, that the "invention" and "discovery" are fundamentally the same. Whether we use one or the other depends on how big the size of the space of the possibilities feels to us. Math has a very rigid and easily enumerable space of possibilities (strings of symbols), so we call it "discovery", while cooking has an enormous space of possibilities (countless pieces of meat and vegetables, each unique in its configuration of atoms, etc.), so we call it "invention".
When you invent a way to make music, did you really invent it? Or did you simply discover a particular configuration of atoms that can produce sound when handled in a particular way, that was already there in some platonic universe of ideals? Either way, the end result is the same. Nothing really changes.
Maybe you'd prefer a purely set-theoretic one:
---
Let R be a set. Let S be a set of all subsets of R.
We want to prove that |S| > |R|, by proving that a bijective function from R to S cannot exist. We will do that by assuming that it can, and then deriving a contradiction.
Assume there is a bijective function f : R -> S. Define D = { r ∈ R | r ∉ f(r) }. Since f is a bijection, there exists some r₀ ∈ R such that f(r₀) = D.
However, by the definition of D, we have:
- If r₀ ∈ D, then r₀ ∉ f(r₀) = D, which is a contradiction.
- If r₀ ∉ D, then r₀ ∈ f(r₀) = D, which is also a contradiction.
Therefore, our assumption that there exists a bijective function f : R -> S must be false.
Therefore, |S| > |R|.
It is IMO not known widely enough that Python itself can be compiled, using Nuitka [0] compiler. It still runs Python code, so the performance increase is not as extreme as one would get from rewriting in a fully statically typed code, but the AOT compiled C code is still faster than the interpreter.
If we go down the skeptics' route, we can't know anything absolutely (except that we exist yada yada). But we still have to function in the real world, so we assume the most consistent observations will never change. From those observations, we extract the axioms, on which we build the tower of conclusions.
Funnily, it's also one of the reasons I stay with Go.
Error handling is the most contraversial Go topic, with half the people saying it's terrible and needs a new syntax, and half saying it's perfect and adding any more syntax will ruin it.
But that would be unfair to the very design choice of omitting metaprogramming while exposing the go/ast library to users to foster code generation.
I often get in arguments about how I tend to avoid brands that put too much into marketing. Of course, theoretically, the amount of money a company puts into marketing doesn't automatically lower the quality of their products, but in my experience, the correlation is there. Whiskas, Coka Cola, McDonalds, etc.
However, that's not what we should have in mind when designing software. The Unix IPC model of file descriptors combined with select syscall (and its successors) was a powerful abstraction by itself, and Go just brought it to the single-program level - instead of pipes, you have channels, and instead of select syscall you have select{} keyword.
The problem is that we're still stuck, mentally, with the C model of threads and shared memory. You can use Go channels as locks and still write C code dressed up as Go. But in my experience, the most powerful design in Go is separating work into goroutines, each of which does one thing (and does it well :), which communicate via channels to achieve a common goal. Preferably, exposing the interface in a simple way, not requiring the user to be aware of them at all. Sort of like Actor model, but with channels instead of explicit addresses.
As long as I've followed this way of thinking, I've rarely had an issue with deadlocks at all.
Go sounds like a good candidate.
Some actions simply make so much sense to do, that any sensible person (unaware of the concept) will start doing them given enough practice, and in process they "reinvent" a common method.
Congratz, you've independently invented integration tests.
If your intention is to not start a flame war, you might want to avoid contraversial topics such as the obviously manufactured canceling of RMS by the-powers-that-be.
Sometimes, what you want is just a simple key=value config parser.
A little re-inventing the wheel is better than a little dependency.
That's not cool, man. How would you feel if someone looked at your wife that way?
For those who want a really self-contained Python script, I'd like to point out the Nuitka compiler [0]. I've been using it in production for my gRPC services with no issues whatsoever - just "nuitka --onefile run.py" and that's it. It Just Werks. And since it's a compiler, the resulting binary is even faster than the original Python program would be if it were bundled via Pyinstaller.
The author's GitHub page [1] contains the following text:
Other than software development, my passion would be no
other. It's my life mission to create the best Python
Compiler I can possibly do or die trying, ... of old
age.
Considering how fast the TypeScript compiler is, the TypeGo -> Go transpilation might as well be similar (up to a constant factor) in speed to Go compilation itself.
I'd give it a try. As a highly enthusiastic Go programmer, a powerful TypeScript-like type system is something I'd welcome in Go with open arms.