> Actually, under the GPL, this fact is immaterial. If the Winamp player contained any GPL code at all, modified or not, then it is a derivative work of that GPL code and anyone receiving a copy of Winamp is entitled to demand the full corresponding source be provided under a GPL license.
That's just not true, surely? Lest everyone using any flavour of Linux is liable to the same problem?
How many apps out there are using GPL code? Android, for example.
Making a derivative in the sense of adding functionality to it, I get, but using it as-is as a component or library surely doesn't - and cannot - fall foul of the license else the entire technosphere is liable.
It is if you link it into your address space. If your code wants to be non-GPL then it needs to have some kind of barrier between it and the GPL code that it uses. For Linux, that would be the kernel syscall abi. But normally it's the process boundary. For example, if your program spawns the GNU gperf command, then its GPL license doesn't apply to your program. Furthermore, the generated code that the gperf command prints to stdout, is not encumbered by the GPL. In other words, the output of a GPL licensed program belongs to you. But if you were to copy gperf's .c files into your codebase and use their perfect hash table algorithm, then your software would become GPL encumbered, but only if you distribute. They will sue you and spare no quarter if you don't give your users the same freedoms that they gave you. Even if the gperf dev team doesn't do it, then some other org representing someone who contributed a bug fix once will. You can't hide and there is no time to survive, because GitHub can be easily monitored using tools like BigQuery.
> spare no quarter if you don't give your users the same freedoms that they gave you.
What? The actual history of GPL enforcement is restrained when it comes to remediation. Are you aware of some routinely punitive GPL enforcer that I am not? Or is this FUD or a joke?
I hope I've not missed some news about your own projects and that you've not been subject to anxiety or meanness on account of the GPL, either. :(
You can have copyleft without virality; the Mozilla Public License 2.0 requires any modifications to a covered work to be released under the same license (copyleft), but does not extend this requirement to other code included in a combined work (virality). As I read the license, you could embed the Gecko browser engine in your proprietary e-reader software, and only your changes to the engine itself would have to be released as free software.
If you are linking against GPL code then yes it's true. If you are linking against LGPL code then it's fine. Note that running software on Linux doesn't mean you are linking to Linux. However, if you distribute Linux, then yes, you must supply the Linux source code on request.
The "technosphere" is generally fairly compliant on these things. There is no disaster. But this is also why most commercial companies avoid GPL libraries.
> Note that running software on Linux doesn't mean you are linking to Linux.
Technically, you do link to linux-vdso.so (or variants depending on architecture), which is part of the kernel image. There doesn't seem to be an explicit GPL exception for the sources of this library [0] but the general syscall exception [1] may or may not apply.
> Lest everyone using any flavour of Linux is liable to the same problem?
If by that you mean, if you are using Linux in production servers: You may use GPL software in a commercial setting. The source code part only applies if you are distributing software that contains GPL code.
I lost a lot of respect for the RabbitMQ maintainers when they refused to honor the semantic versioning scheme in package managers like nuget/maven/etc. "Safely upgrading" was impossible. 3.5 => 3.6 saw the removal of an argument.
They didn't lose my respect for the removal of the argument, however, they lost my respect for whatabouting the conversation calling SemVer a "no true scotsman" fallacy, then trying to claim that removing a redundant argument is not a breaking change, and other reality-warping nonsense, before blocking myself and other complainants from their issues - and even deleting some of their own comments to mop up some of their own terrible reasoning.
I'm sure there is no love lost on their side, either. Personal rant over.
> I lost a lot of respect for the RabbitMQ maintainers when they refused to honor the semantic versioning scheme in package managers like nuget/maven/etc. "Safely upgrading" was impossible. 3.5 => 3.6 saw the removal of an argument.
Well, at least AMQP 1.0 is now supported so I expect that for most things you are able to use any client now.
Continuous testing tools would make good use of audio. It's been a minute since I have been in need of such a tool, but I could appreciate differentiating sounds for passed/failed.
I'm gravely naive to modern security methods (both defense and offence) but I work closely with some infosec guys in a big-fish company and they often share tales/experiences that I find fascinating because of their ingenuity and temerity.
Some examples:
We have had multiple attempts to use AI as imposters to convince well-wishing colleagues into doing things they shouldn't - a complicated technique that has seen success for the hackers on some occassions[0] - which requires infilitrating numerous accounts etc. This one is the "hollywood romanticized" idea of hacking because it is in realtime with actual people operating the stolen accounts, but using AI to mask their appearance and voice.
Sleeper infiltration - someone will find and breach an exploit, only to patch it, but leave a new backdoor. They then let it sleep for many months, eventually coming back to use it only to (attempt to) completely remove any trace of their presence. inb4 anyone says "ah but they probably copied/did something else you don't know about!" We've had those, too, but some really do just exploit, patch, then leave. Probably to deny someone else or something.
A really fascinating moment for me was watching a seceng spinup a honeypot and it took less than a minute for some attacks to start hitting it.
Techies aren't immune either, before we all follow the "blame management" bandwagon for the 2^101-tieth time.
CEOs aren't the reason supply chain attacks are absolutely rife with problems right now. That's entirely on the technical experts who created all of those pinnacle achievements in tech ranging from tech-led orgs and open source community built package ecosystems. Arbitrary code execution in homebrew, scoop, chocolatey, npm, expo, cocoapods, pip... you name it, it's got infected.
The LastPass data breach happened because _the_ alpha-geek in that building got sloppy and kept the keys to prod on their laptop _and_ got phised.
An employee (dev/sysadmin) had their home device compromised via a supply chain attack, which installed a keylogger and the attacker(s) were able to exfiltrate the credentials to lastpass cloud envs.
Yeah supply chain stuff is scary and still very open. This ranges from the easy stuff like typo-squatting pip packages or hacktavists changing their npm packages to wreck all computers in Russia up to the advanced backdoors like the xz hack.
Another big still mostly open category is speculative execution data leaks or other "abstraction breaks" like Rowhammer.
At least in theory things like Passkeys and ubiquitous password manager use should eventually start to cut down on simple phishing attacks.
It's definitely worth a try if you're not satisfied with DDG's results. They seem to more closely match Google & have a few more privacy features, such as visiting a page through their anonymized proxy.
I've been quite impressed with Brave's search, tbh. They do have optional AI answers & I've been happy with the results.
I note a total absence of sources for your claims.