|
|
Log in / Subscribe / Register

ambiguity

ambiguity

Posted Dec 25, 2025 22:06 UTC (Thu) by josh (subscriber, #17465)
In reply to: ambiguity by DeletedUser128680
Parent article: A partial ruling in the Vizio GPL suit

> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.


to post comments

ambiguity

Posted Dec 26, 2025 0:56 UTC (Fri) by DeletedUser128680 ((unknown), #128680) [Link] (14 responses)

That says "installation of the executable", but not "installation of the executable on the same device", hence the judge's ruling.

ambiguity

Posted Dec 26, 2025 2:10 UTC (Fri) by marcH (subscriber, #57642) [Link] (13 responses)

The image created by the original scripts is very likely specific to a certain TV model. Which means there is no "other device" that can run an unsigned image. So what does "installation of the executable" mean when there is no device that can run it? Debatable.

What is not debatable: the GPLv3 was very clearly designed to stop "Tivoization", because the GPLv2 clearly did not take it into account. So, projects not upgrading and taking a v2 versus v3 stance are OK with Tivoization. Spirit of the license versus letter of the license?

ambiguity

Posted Dec 26, 2025 3:15 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

There is a difference between "the scripts used to control compilation and installation of the executable" (as the GPLv2 says) and "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work" (as the GPLv3 says, in the context of a "User Product," which has a whole bunch of other verbiage that I'm not quoting here).

The judge's opinion does not say exactly where to draw the line, but here are some hypothetical things that *might* be "installation scripts" under GPLv2:

- A script that places binaries in /usr/bin etc., assuming that is the name of the directory where the real product keeps its binaries.
- A script that creates an unsigned image suitable for use with e.g. Docker.
- A script that constructs a .deb or .rpm package.

This is further complicated by the fact that, in this case, the software we care about is the kernel. So /usr/bin is probably irrelevant, but then I don't know precisely what it means to "install" a kernel (as distinguished from installing an entire OS including the kernel). Maybe configuring GRUB etc. to boot into it? Maybe constructing initrd/initramfs or whatnot? It seems underspecified.

I think the most plausible position for Vizio to take is that they are only required to provide things that are either directly based on something in Linus's tree, or direct replacements for something in Linus's tree. So if Linus has an "installation" script in the upstream kernel, and Vizio has a script that performs an analogous operation, then maybe Vizio has to provide that script (even if it is not based on Linus's script). But if Vizio does something that Linus has never provided (like code signing), then they will argue that it's out of scope.

I have no idea if the judge will sign off on that interpretation, but it does at least look to be compatible with what the judge wrote.

ambiguity

Posted Dec 26, 2025 16:31 UTC (Fri) by Wol (subscriber, #4433) [Link] (11 responses)

> So, projects not upgrading and taking a v2 versus v3 stance are OK with Tivoization.

Cart. Horse. Which is which? (a serious question).

The GPLv3 is NOT a PURE software licence. So Tivoisation aside, it is NOT a drop-in replacement for v2.

You can have plenty of reasons for rejecting v3, in which Tivoisation just does not feature at all ... my biggest beef is that v3 is a patent licence, amongst other things ...

Cheers,
Wol

ambiguity

Posted Dec 26, 2025 16:39 UTC (Fri) by Wol (subscriber, #4433) [Link] (10 responses)

Whoops - should have said not a pure COPYRIGHT licence.

Cheers,
Wol

ambiguity

Posted Dec 27, 2025 15:29 UTC (Sat) by cyphar (subscriber, #110703) [Link] (9 responses)

GPLv2 also contains text about patents but is intended to provide something akin to an implicit patent grant (my understanding is that the view of Stallman and the FSF was that they did not want to endorse the concept of software patents back in 1991). Unfortunately, defensive patent licenses really are quite necessary to avoid patent trolls, and most modern licenses include them for that reason.

ambiguity

Posted Dec 28, 2025 16:13 UTC (Sun) by Wol (subscriber, #4433) [Link] (8 responses)

Dunno how this fits in with my philosophy, but I would simply have, as my "patent licence", a statement that "the software authors' opinion is that software is mathematics and cannot be patented. By copying this software you agree with the authors that this software cannot be patented, and agree not to launch any patent suits for technology in this software. This agreement places absolutely no restrictions whatsoever upon the use of patents for self-defense or a counter-offensive".

Cheers,
Wol

ambiguity

Posted Jan 1, 2026 0:56 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (7 responses)

> This agreement places absolutely no restrictions whatsoever upon the use of patents for self-defense or a counter-offensive

This carries exactly the same problem as the JSLint license's infamous line "the software shall be used for good, not evil." Nobody knows exactly which patent actions count as "self-defense or a counter-offensive."

Suppose party A sues party B for infringing a patent on industrial process Q, which happens to involve software as one component in a larger manufacturing process (see e.g. Diamond v. Diehr). Does that give party B the right to sue party A "for self-defense"? For that matter, does such a lawsuit fall under the proposed patent-exclusion term in the first place? Where do you draw the line between software and hardware?

ambiguity

Posted Jan 1, 2026 2:24 UTC (Thu) by Wol (subscriber, #4433) [Link] (6 responses)

> Where do you draw the line between software and hardware?

Can you print it on a piece of paper? Is it something that gets fed through an Arithmetic Logic Unit? (Hence the claim that software is mathematics. As soon as something physical happens, that's hardware. If it's maths, the physical representation is an implementation detail. if it IS the implementation detail then it's hardware.)

> Nobody knows exactly which patent actions count as "self-defense or a counter-offensive."

If you're sued "for using the software", then any action you take in response is self-defense. If you're sued for using someone else's industrial process, that's hardware, and no a counter-suit is not self-defense for "using the software".

Cheers,
Wol

ambiguity

Posted Jan 1, 2026 16:25 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

So the engine design in my car is software, because it can be printed on paper, and was fed through lots of ALUs during the design process, and thus any patent that's infringed as a consequence of design decisions is a software patent?

And if I'm sued for using the software as part of an industrial process, where the software is the part of the system that implements the invention, then I'm allowed to counter-sue, but if instead of using a microcontroller, a sensor, and software to implement the feedback loop, I used the simpler mechanical equivalent, I'm not?

These sorts of edge cases are why it takes a lawyer to think it through - and why simpler is better (e.g. "you are using a patent if you sue someone first; you are defending yourself with a patent if it's a counter-suit").

ambiguity

Posted Jan 1, 2026 20:38 UTC (Thu) by Wol (subscriber, #4433) [Link] (4 responses)

This is where you want to shoot all lawyers :-)

> So the engine design in my car is software, because it can be printed on paper, and was fed through lots of ALUs during the design process,

Well, it could be ... I think I missed the distinction "fed into the instruction register" as opposed to "fed into the data registers", but see the next point ...

> and thus any patent that's infringed as a consequence of design decisions is a software patent?

No, definitely not. It's all meta, or is that meta-meta, or even meta-meta-meta?

> These sorts of edge cases are why it takes a lawyer to think it through - and why simpler is better (e.g. "you are using a patent if you sue someone first; you are defending yourself with a patent if it's a counter-suit").

Well, the first question is "what exactly have you patented"? Let's take your engine blueprint (on paper), and my software (on paper). I think any judge, presented with a claim that you've patented the paper, will laugh you out of court.

So. Have you patented what's on the paper? As far as the software goes, that IS the software, that is a software patent. The blueprint? If you've patented the blueprint itself, what rights exactly does that give you? The right to stop someone feeding it through a photocopier and colouring it in?

Or the right to feeding the instructions on the paper into a CNC milling machine, and making the object described by the paper? That right exists, it's called a Design Patent, but there are rarely any instructions on the paper itself, you have to put a load of work in yourself to create the physical object. You can't do that with my program - this step can't exist - the patented object is the object ON the paper, not described by the paper.

Or is it the right to actually USE the object that you created from the blueprint that is covered by the patent - what we normally think of as a patent - a meta-meta-meta claim.

So any patent infringed by USING the software is a software patent - any patent infringed by using the RESULTS FROM the software is outwith the purview of the licence.

> And if I'm sued for using the software as part of an industrial process, where the software is the part of the system that implements the invention, then I'm allowed to counter-sue,

Eggsackerly. You have been sued for using the software. If the software drives mechanical linkages, and you're sued over them, then that's not a software patent (but then you've not been sued for using the software!).

> but if instead of using a microcontroller, a sensor, and software to implement the feedback loop, I used the simpler mechanical equivalent, I'm not?

No. You're not being sued for using software. You're being sued for using a mechanical controller, which is exactly what patents are meant to protect!

Cheers,
Wol

ambiguity

Posted Jan 2, 2026 11:19 UTC (Fri) by farnz (subscriber, #17727) [Link] (3 responses)

But the patent can't cover the machine without software (motors, sensors etc are old tech, and not eligible for patent protection as a result), and I can run the software in isolation.

Unless, of course, you're saying that if the software is controlled by touch and movement sensors, and causes hardware to emit sound, movement or light, then it's patentable - but in that case, all software is effectively patentable, since I just add in details of the hardware that you use to run the software to make it patentable.

ambiguity

Posted Jan 2, 2026 13:53 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

> But the patent can't cover the machine without software (motors, sensors etc are old tech, and not eligible for patent protection as a result), and I can run the software in isolation.

That's exactly the point. If it can't cover the machine without software, then it's clearly a software patent, and as such it is explicitly not patentable in Europe.

Likewise, if you run the software with no hardware attached, it's clearly a software patent and again not patentable. (Plus, without hardware attached, it can't do anything so what exactly are you patenting?)

If you can't patent the hardware, you can't patent anything, because "do it with a computer" is not patentable.

As I said, what exactly are you patenting? Patenting software is the same as patenting a blueprint. And if you're patenting the blueprint itself, what exactly is it you've got? Something pretty worthless.

Cheers,
Wol

ambiguity

Posted Jan 2, 2026 14:12 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

So I build an unpatentable machine with 1990s tech, add a modern microcontroller, and the process that was previously patentable (since the patent talks about how to do it with hardware) is no longer patent protected, because I'm simulating the patented hardware in software instead?

The patent is on a machine that does something useful - the trick you're opening up is to reimplement the patented machine using 1990s hardware and a (possibly quite powerful) microcontroller, such that the patented process is done by the microcontroller instead of being done by hardware, and the machine does not do the patented process without the software loaded into it.

This is, BTW, how we've ended up with software patents in Europe - the software in and of itself is not patentable, but the combination of software with hardware is patentable where the same combination could be achieved without the software. It's almost the exact opposite of your claim about what makes a patent a software patent - a patent is a software patent in Europe if, and only if, the implementation of the patent requires software, but the mere fact of moving a process from hardware to software does not protect you from patent infringement if the combined machine infringes the patent.

And yes, this means that "do it with a computer" is potentially patentable - as long as the patent can be implemented without the computer, "do it with a computer" is covered, too.

ambiguity

Posted Jan 2, 2026 15:14 UTC (Fri) by Wol (subscriber, #4433) [Link]

> This is, BTW, how we've ended up with software patents in Europe - the software in and of itself is not patentable, but the combination of software with hardware is patentable where the same combination could be achieved without the software. It's almost the exact opposite of your claim about what makes a patent a software patent - a patent is a software patent in Europe if, and only if, the implementation of the patent requires software, but the mere fact of moving a process from hardware to software does not protect you from patent infringement if the combined machine infringes the patent.

At which point, when push comes to shove (if it ever does), some smartypants lawyer will successfully use that to prove "true = false". And leave the Judges with a big headache. Pity Groklaw has gone, but I suspect as soon as any of these patents are actually challenged in court (yes, I'm aware the EPO has been issuing them with gay abandon) and the patenter is asked "what, exactly, have you patented?", then the whole house of cards will come collapsing down.

Can't point you to the details, sorry, but there was a case went to USPTO some years back, where a PRO-software-patents judge said, in a concurring opinion, that he agreed with the decision that in this particular case the software could not be patented and he could not personally conceive of any situation where software could pass the patentability bar.

In court you would simply argue that you are using a load of patent-expired technology, running a list of instructions on a computer (not patentable because it's just using a computer AS A COMPUTER), to control some ancient machinery (obvious). Where in that is the patentable step? Just because the EPO has been gaily issuing "do it with a computer" patents, doesn't mean they will survive scrutiny in court.

How many patents actually survive a challenge for inventin' the bleedin' obvious? Pretty much none. My employer was sued by a (-: Norwegian Blue :-) supplier for breaching their patents - we *had* to fight. And I don't know whether they got sanctioned - I think they might have done - but they certainly got slammed for bringing a baseless lawsuit. The problem is fighting a patent lawsuit is expensive, but in our case it was much cheaper to fight than to cave. And it probably cost them their patent portfolio :-)

Cheers,
Wol

ambiguity

Posted Dec 26, 2025 2:54 UTC (Fri) by iabervon (subscriber, #722) [Link] (1 responses)

Way back when, the FSF had computers you could get accounts on, which had Emacs installed. You could get the compiled Emacs executable, and you could get the source and compile it yourself, but you were unable to install a modified version on the FSF's computer (in /usr/bin) because you didn't have the root password. Presumably, they weren't violating the GPL. The difference in the Vizio case is that it's (supposedly) your hardware that you don't have the ability to write to, rather than the hardware belonging to someone else, but the GPL doesn't have any way to distinguish someone who owns the device from anyone else the firmware was distributed to.

ambiguity

Posted Jan 9, 2026 23:14 UTC (Fri) by anton (subscriber, #25547) [Link]

The difference in the Vizio case is that it's (supposedly) your hardware that you don't have the ability to write to
According to the article, the judge ruled: "this does not mean that Vizio must allow users to reinstall the software, modified or otherwise, back onto its smart TVs", so he is apparently not talking about your or my hardware, but only about Vizio's hardware (i.e., before they sell it).


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds