Winamp deletes entire GitHub source code repo after a rocky few weeks

I can't see the original issue, but it's interesting that the title chooses to highlight the fact that the GPL code was modified. 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.

The original issue was complaining about libdiscid which is under the LGPL license not GPL. With that license, linking to an unmodified library in proprietary software is fine. What's not fine is to link to a modified library without releasing the source code for that modification. (Of course here the modification is extremely simple so some concludes this is a nothing burger.) The original poster likely knew the LGPL difference and that's why everyone became fixated on finding the modifications to the library rather than the fact of linking itself.

> 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.

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.

Yes, it's true. There's a reason GPL is called copyleft.

> Lest everyone using any flavour of Linux is liable to the same problem?

The kernel is GPL. applications running on it in usermode are not constrained by the license.

https://www.gnu.org/licenses/gpl-faq.en.html#PortProgramToGP...

The devil is in the Details. Usually a licence is applied to a single library or compilation unit.

> That's just not true, surely?

It is true.

> Lest everyone using any flavour of Linux is liable to the same problem?

The Linux kernel has an explicit "system calls are not linking" exception to avoid any possible confusion on this matter.

https://github.com/torvalds/linux/blob/master/LICENSES/excep...

Merely using the kernel's facilities from user space does not make your program a derivative work of the kernel.

> Android, for example

Yes, OEMs are expected to release their kernels' sources. Also yeah, they're mostly very bad at it.

> Of course here the modification is extremely simple so some concludes this is a nothing burger

But still a modification.

Winamp came onto the scene about the time I was learning to really code and there were a few projects I didn’t start because the wisdom at the time was of a poison pill/ship of Theseus variety: if you use code you didn’t write as scaffolding to write a new system, even once you’ve replaced all of the sections of the code you borrowed with completely new code, you are still stuck with the old license.

One of the reasons libraries are useful. You can replace the library in one go and if you do it right (ie, don’t replace it by the same modification process described above) the license is moot.

I worked for a company that did sales in Europe and we ran afoul of a public domain library. At the time the EU didn’t recognize PD release as a legal act. One library was easy enough to replace with a similar one, the other had no suitable peer. Luckily the library we used was small and we didn’t use much of it, but that use was important.

I wrote a bunch more unit and functional tests in our code to serve as pinning tests, then asked a lead dev on another team to write a library to replace it without referring back to the existing code. I’d stepped through it enough I could practically rewrite it from memory. I knew that wouldn’t stand up legally, but he had no reason to obsess about that part of the code. Nearly took me longer to explain the gambit to him than it did for him to complete the task once he understood it.

> With that license, linking to an unmodified library in proprietary software is fine.

Was it linked dynamically? Static linking to an LGPL library from a proprietary application is also possible, but way trickier.

> 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 think the point here is that so that people reading the article don't complain about "they didn't contain GPL code directly" somehow justifies thinking that that was bikeshedding and not a legitimate violation of the license. Of course, it does not matter if the code was modified or not, but that point might not be clear to the readers who don't have enough experience with GPL.

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.

> Was it linked dynamically? Static linking to an LGPL library from a proprietary application is also possible, but way trickier.

For a "shared source" app (i.e. source available but under restrictive non-open source terms), static linking is generally a non-issue, provided you give people permission to recompile the app from source with a modified library version, and you actually built the binaries you ship from the source you provide them (as opposed to some separate internal repo containing changes missing in the source you provide to your customers or the public). So, WinAmp currently would not be infringing even if it were statically linking modified LGPL libraries (assuming their source repo includes the source to the modifications) – although this may be evidence of past non-compliance.

Static linking is really only a big problem for proprietary apps where you don't give people the source code. Even there, so long as you ship them object files so they can relink it with an updated LGPL library version, you are fine. Once upon a time, linking at the customer site was not an uncommon strategy for enterprise software, in fact last time I worked with Oracle RDBMS (7+ years ago) it was still using that strategy for a standard install.

For LGPL 2.1, you don't even need to ship the object files or offer them for download – you just need to make an offer, valid for at least 3 years, [0] to supply them on request. LGPL 3.0 removed that provision, with LGPL 3.0 you have to either ship them or offer them as a separate download.

[0] I believe the "3 years" is from the date you ship each individual copy of the software. So if you released version 1.0 in 2001, and it contained a "valid for 3 years offer", if you are still offering version 1.0 for download from your website in 2024, that offer is valid until 2027 for someone who downloads it today. But if you removed version 1.0 from your website in 2005, and since then have not given anyone a copy, then the offer would have expired in 2008.

the point here is to solve the problem of linking to an LGPL licensed library, to comply you can:

a) release the code of the original LPGL licensed library

b) release it with a patch of any modifications, ie the small change here

c) nothing else. zero. No license changes. No other code of the app affected. No app code needs to be released.

And you are compliant with the LGPL license and can get on with life. So this is not a big deal the way GPL code in the app would be which would require the app code to be re-licensed and released to comply, which is a huge deal and difficult to accomplish.

> 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. :(

> 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.

[0] e.g. https://github.com/torvalds/linux/blob/master/arch/x86/entry...

[1] https://github.com/torvalds/linux/blob/master/LICENSES/excep...