The FSF doesn't endorse Gentoo?

The_Document · Apprentice Joined: 03 Feb 2018 Posts: 275

If Im not mistaken the kernel has TONS of code which isn't GPL or free licensed, not to mention closed sourced driver files which virtually EVERY distribution using a DE with X/Wayland is using. Therefore most if not all distros actually do not abide by their rules because of the closed source drivers and other things not GPL licensed.

The Doctor · Moderator Joined: 27 Jul 2010 Posts: 2678

The_Document · Apprentice Joined: 03 Feb 2018 Posts: 275

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Some hardware is built fully capable and artificially crippled in the microcode because it's more profitable to sell a broken high end part as a low end one than throw it out, or just do it to fill orders for low-end parts - see e.g. most Intel and nVidia chips.

The Doctor · Moderator Joined: 27 Jul 2010 Posts: 2678

They are extremists. That means they do not accept any middle ground. This means the FSF does not only discourage blob use but require that it is not supported in any capacity by a "compliant" distro. They are basically the Microsoft or Apple of open source. They want to be the only game in town and you have to play by their rules. They are not about freedom; they are about control.

You really hit the nail on the head about why companies don't disclose code. Nvidia makes money by selling new video cards. Any card installed or reused is worth nothing to them. Being able to EOL a card is worth a lot of money. Then there is Blu-ray which is literally based on proprietary keys. Releasing it would defeat the entire purpose of the DRM and "allow" movies to be stolen.

Then there is security. If you show everyone how the UEFI is implemented then any Dennis Nedry can use that to shut down Jurrasic Park. You also have to deal with the white hats pointing out flaws in your product. If you keep it a secret then no one cares and Rexy doesn't escape.

Furthermore it is a pain in the neck to make your code available and it helps out your competitors. Two reasons not to do it.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

NeddySeagoon · Posted: Thu Feb 22, 2018 5:01 pm Post subject:

The_Document,

Blobs come in two sorts.

Those which run on the host system, like nvida-drivers and those that do something inside a particular device, like firmware/microcode.

The first sort link against the kernel. If they are not GPL-2 they cannot be distributed with the kernel.
If they are GPL-2, then they are not blobs by definition. You are entitled to the sources.

The second sort are often provided to save a few pennies on providing permanent storage on the device itself.
e.g. Wifi firmware. Lots of these blobs are not computer programs. Is a state machine a program?
They do not link against the kernel.
They might not have sources that most people word recognise so they could not be usefully released.
Think about CPU microcode for example. That's distributed as a blob ... but does it have any sources?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

The_Document · Apprentice Joined: 03 Feb 2018 Posts: 275

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

It occurs to me that a blob which is a device driver need not be compiled against the Linux kernel or any other FOSS software. If anything, the kernel is compiled against the driver.

The kernel is, by definition, a layer between the hardware and the software running on the system, it exists in order to provide a consistent API for other packages to get at hardware without necessarily knowing what that hardware is.

The driver (blob) developer is implementing an API such that their hardware works when software uses that API.

Considering that the blob is developed FOR the Linux kernel, there is an implicit and probably explicit permission if you look at the license for the blob for it to be used in the kernel.

Firmware blobs I would think would be similar. They reside between the hardware and the kernel, or maybe rather the kernel interacts with the firmware blob.

steveL · Posted: Thu Mar 01, 2018 9:29 pm Post subject:

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

Dominique_71 · Posted: Sat Mar 03, 2018 12:04 pm Post subject:

Hu · Administrator Joined: 06 Mar 2007 Posts: 22720

Dominique_71 · Posted: Sat Mar 03, 2018 6:51 pm Post subject:

Hu · Administrator Joined: 06 Mar 2007 Posts: 22720

Right, and even a working assembler is one step (or a few steps, depending on its support for macros, expressions, etc.) up from manual maintenance of the firmware blob. A working assembler and linker are the tooling that I referenced above.

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

Yeah, there's pretty much zero chance that hardware 'in the wild' would be released without at least a working assembler and disassembler, more likely a full compiler and linker too. And yes, I mean for blobs on whatever hardware requires blobs. Edit: That doesn't mean that the assembler/disassembler/compiler/linker is open source or even available to use for a price without signing an NDA with the manufacturer.

I know exactly what blobs are, but thanks for the explanation for people who don't. Not exactly a bios, but correct in that they are at least usually gone when the power goes out.

The point of my statement above is that the GPL most likely does not apply to the blob, no matter what the license of the blob. The blob is not compiled against the kernel, it is simply something the kernel can load. If anything, the kernel is compiled against the blob.

Dominique_71 · Posted: Mon Mar 05, 2018 1:57 am Post subject:

The Doctor · Moderator Joined: 27 Jul 2010 Posts: 2678

I think the point relevant to the discussion here is that anything that is proprietary and interacts with the kernel to make the system work is banned by FSF and an "approved" distro must not support their use.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

steveL · Posted: Tue Mar 06, 2018 12:08 am Post subject:

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

steveL · Posted: Thu Mar 08, 2018 9:32 am Post subject:

Yadda yadda. You keep putting words in my mouth, then you take that nonsense you've attributed to me, and "disprove" it.

You're doing it now and you did it in your previous post, that gained agreement on the idea that this argument is a load of shit:

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

What do you expect? I'm telling you that it's possible to do something, giving an example of a real-world scenario, and you're telling me it's bullshit.

If someone tells you about a possible choking hazard for a toy you bought for your kid do you ask for proof of it being a risk, or do you take the toy away? Or, since YOUR kid hasn't choked do you keep the toy and let him play with it?

If someone says it's possible to cause a buffer overflow and execute code as root, do you argue with them or do you install the fix? Or since nobody has attacked YOUR system do you assume it can't happen to you, and keep using the old code?

I'm not waving my hands. I'm just saying it's possible to have a previously externally loaded module, and for someone (not necessarily the original author) to have implemented that interface using FOSS code.

In what way exactly is that bullshit? Where is the hand-waving? This type of module loading happens all the time for all sorts of reasons. With examples such as ODBC and JDBC drivers it happens with various modules of various licenses. How is it so difficult to understand that it could be done on a commercial app using FOSS code linked to from inside of the module?

I'm telling you and the rest of the thread about a hypothetical scenario, and you say it's bullshit.

steveL · Posted: Sun Mar 11, 2018 10:58 am Post subject:

It's the way you keep conflating "real-world" with "hypothetical" that is hard to accept.

So far, what I've got from your argument is that there are practical difficulties to releasing commercial software.

No offence, but this is hardly news.

And I don't see what the GPL, or any other FLOSS license, has to do with it, since they are in fact an awful lot easier to work with than proprietary licenses, each of which must be analysed in detail by Legal (or whoever gets stuck with the job. IME they come down to "you have no rights" apart from usage at one installation/for one development project, which sucks an awful lot more than FLOSS. Especially when you've just shelled out several hundred dollars for a component, and you haven't got paid yet.)

As for "accidental linkage", there's no distribution involved, and if there is then you're being a twat. ("you" meaning whoever's doing the distribution, which you've stipulated is commercial.) Learn how real build-systems work, and make reproducible builds that only link to what you allow. (After all, you're going to distribute it, and your corporate reputation is on the line, as well as its legal standing.)

With respect, I feel like I've been pulled into a misunderstanding; I only asked you to "go on then, show us some real-world examples", because I thought you knew of FLOSS projects that have been affected by this (so we'd have actual "real-world" examples to talk about.)

I don't much care that commercial software-houses need to deal with copyright, as that has always been the case since the beginning of the industry. It's par for the course, part of doing business etc.

Still not seeing why the GPL is a bad thing, or bad in any way: it is clear, not hard to work with, and allows you to make money on both sides: distribution and publishing, via selling exceptions (admittedly not as lucrative as support-contracts, which is why there's all the politicking going on.)

And ofc, it's the reason we can even have this conversation.

Honestly, patents are far more of a problem to the whole of society, not just the software industry.
Here's hoping our new Chinese overlords stick with their current IP arrangements.. as well as their tax laws. ;p

1clue · Advocate Joined: 05 Feb 2006 Posts: 2569

SteveL,

While there's much to agree with on what you're saying, and I keep trying to expand on the points, you still keep missing what I say.

So we're back to not making much progress here.

IMO we chewed all the flavor out of this discussion 3 or 4 pages back. Let's just drop it.