missjellyfish

I'd further argue that it would be important if your program does anything useful without the GPL parts; if so, you can probably argue that it is not a derivative work. If you however only build an extension to some GPL'ed software that fundamentally needs the GPL'ed code to properly function and cannot (easily) be used by any other software, then you probably will create a derivative work.

Yes, all of the above is on the condition that some distribution happened (and you can prove that).

However, distribution also happens in places you might not expect. As a business, I'd stray far away from such constructs even if I only use this construct internally.

However, this is purely based on the wording of the GPL. For example, the EUPL explicitly covers the creation of derivative works - and I'd argue that the proposed circumvention would create a derivative work.

The end result will most probably violate the GPL. However, this is only realized by each user; you could probably argue that you never test your software and only look at API documentation.

And then it becomes a problem of proving your users violating the GPL. So you'd have to go after each one of them, which will be incredibly difficult, and proving damages would be even more difficult.

It's an asshole way of exploiting "Wo kein Kläger, da kein Richter" (where's no plaintiff, there's no judge) since actually proving that the developers violated the GPL will be difficult, unless they have a CI system that readily documents this.

I'm not entirely sure if this is even possible the way copyright in the EU works today. Be that as it may, at least from my perspective what really prohibits me from actually enforcing GPL on my software is funding. I rarely go beyond sending a stern letter, because anything more would be financial suicide in most cases; I might win but it is incredibly hard to prove damages. Punitive damages don't really exist in the EU (or, to be more precise, in the roman-german law system), at least not to the exterme seen in common law systems.

At least in my case, I'd fight tooth and nail for my software, if I don't have to bear the financial risk.

I was simplyfying. What I described is unified in the European Union; however, the outlined distinction is common across the roman-germanic law system whereas the US copyright interpretation is rooted in common law. In Europe, the only countries using common law are UK and Ireland. And while Ireland has mostly unified their copyright law with the rest of the european union, you still see some roots in common law. For example, it is possible that an irish company (a legal person) can become an author of a work, which is impossible under e.g. german law.

And yes: in a common law system, copyright governs literally "the right to copy", which is transferable. In other law systems (which is the distinction I made) the law governs the property rights of the author's expression, which is non-transferrable, you can only license the rights you have.

Copyright in Europe fundamentally does not work like Copyright in US. More precisely, the law does not govern the monetary gains possible from copying but rather the author's artistical expression in the work. Which is kind of moot regarding source code, but, it makes for an important decision: author's rights are created automatically and you cannot transfer them under any circumstances whatsoever.

Per default, the law states that the author retains all rights. They can license it, e.g. to their employer, exclusively; The employer can then sublicense that. However what licenses are possible is exhaustively defined in the law; on an abstract basis at least (e.g. using, creating derivative works, ...). It has been not exactly clear if conditions evoked on a license still have their roots in these licensable acts, or if they are based on contract law - where literally anything goes as long as it's not against the law or immoral.

Both can be enforced. However, I'd argue that it is good that it was decided that this is a copyright law matter, because this gives authors _much_ more protection than contract law, where all circumstances need to be evaluated for each single case and rulings might as well contradict each other.

Not a lawyer yet, though.

Trademark law always hinges on the question if a reasonable consumer with reasonable knowledge could be expected to distinguish those trademarks or not.

HDMIY would most probably not fly, HDIY would probably.

not yet a lawyer, though.

edit: I'm also fairly certain that the HDMI forum would fight HDIY tooth and nail, so whoever goes public with that absolutely needs deep pockets.

Someone needs to reverse engineer and publish the spec ASAP. This is ridicolous.

Telephone Line Voltage is anywhere between 48 to 90V DC, depending on where in the world you are and which standards apply.

Give MediaMonkey a shot. If you play local files, it’s the best player I ever had the pleasure to use.

Wow, thank you. Of all things I considered happening when posting my snarky winamp remark this was not something I expected. Will check that out.

I like how they fail to mention that the Apple Music App on Windows is hot garbage riddled with bugs. A few weeks ago they broke reordering of upcoming songs, the "play next" feature and I don't know what else.

I have submitted bug reports with exact steps, reproducible on at least two accounts on five different conmputers. Haven't heared back, doubt I'll ever will.

Anyone can recommend a streaming service that isn't Apple Music, Spotify or YouTube Music? Bonus points if I can just add a plugin to my old trusty winamp to use it.

Exactly the reason why I am rocking a Broadcast Headset (Beyerdynamic DT-797PV, to be specific) for work calls. It has XLR for the microphone and 1/4" for the headphones. All goes into a cheap Behringer UMC22. Never had any problems with Teams, Zoom, ... you name it, my colleagues using bluetooth have constant issues, be it with connectivity, audio quality or both.

Also since I wear glasses all day everyday I will never use any headphones that don't have velours earpads. So much more comfortable than faux leather.

If so, I'd much rather have miniDP. Better connector, better standard, it talks HDMI anyway if you want to, and you will need an adapter anyway.

That would probably be fine by me if and only if:

a) the source code of the secure enclave is 100% open source b) I can compile my own version of it c) I can run my own version of it d) I face no reprecussions (i.e. services not working, DRM not working, ...) if I choose to do so.

This is all fine and dandy for key storage purposes; you actually want all of these to guarantee that your keys are safe. But modern enclaves are primarily used for DRM, and this just doesn't work if I can just patch a way into my enclave to get the key if I really want to.

So, I'd much rather have a system with no enclave which I can attach a HSM to than a secure "trust me bro" enclave.

DRM was the original sin of computing, and nobody can convince me otherwise.