GPLv2 affirmation…

I don’t generally post here as people have probably noticed, but here’s a pdf of a recent court ruling, and this turns out to be the easiest way for me to link to a copy of it, since I don’t really maintain any web presence normally and I don’t want to post pdf’s to the kernel mailing lists or anything like that.

And the reason I want to post about it, is that it basically validates my long-held views that the GPLv2 is about making source code available, not controlling the access to the hardware that it runs on.

The court case itself is a mess of two bad parties: Vizio and the SFC. Both of them look horribly bad in court - for different reasons.

Vizio used Linux in their TVs without originally making the source code available, and that was obviously not ok.

And the Software Freedom Conservancy then tries to make the argument that the license forces you to make your installation keys etc available, even though that is not the case, and the reason why the kernel is very much GPLv2 only. The people involved know that very well, but have argued otherwise in court.

End result: both parties have acted badly. But at least Vizio did fix their behavior, even if it apparently took this lawsuit to do so. I can’t say the same about the SFC.

Please, SFC - stop using the kernel for your bogus legal arguments where you try to expand the GPLv2 to be something it isn’t. You just look like a bunch of incompetent a**holes.

The only party that looks competent here is the judge, which in this ruling says

Plaintiff contends the phrases, “machine-readable” and “scripts used to control compilation and installation” support their assertion in response to special interrogatory no. 4 that Defendant should “deliver files such that a person of ordinary skill can compile the source code into a functional executable and install it onto the same device, such that all features of the original program are retained, without undue difficulty.”

The language of the Agreements is unambiguous. It does not impose the duty which is the subject of this motion.

Read as a whole, the Agreements require Vizio to make the source code available in such a manner that the source code can be readily obtained and modified by Plaintiff or other third parties. While source code is defined to include “the scripts used to control compilation and installation,” this does not mean that Vizio must allow users to reinstall the software, modified or otherwise, back onto its smart TVs in a manner that preserves all features of the original program and/or ensures the smart TVs continue to function properly. Rather, in the context of the Agreements, the disputed language means that Vizio must provide the source code in a manner that allows the source code to be obtained and revised by Plaintiff or others for use in other applications.

In other words, Vizio must ensure the ability of users to copy, change/modify, and distribute the source code, including using the code in other free programs consistent with the Preamble and Terms and Conditions of the Agreements. However, nothing in the language of the Agreements requires Vizio to allow modified source code to be reinstalled on its devices while ensuring the devices remain operable after the source code is modified. If this was the intent of the Agreements, the Agreements could have been readily modified to state that users must be permitted to modify and reinstall modified software on products which use the program while ensuring the products continue to function. The absence of such language is dispositive and there is no basis to find that such a term was implied here. Therefore, the motion is granted.

IOW, this makes it clear that yes, you have to make source code available, but no, the GPLv2 does not in any way force you to then open up your hardware.

My intention - and the GPLv2 - is clear: the kernel copyright licence covers the software, and does not extend to the hardware it runs on. The same way the kernel copyright license does not extend to user space programs that run on it.

Together with my LPC videos [1], the video of my OSSummit Japan for a kernel development mailing tool (hkml) that I develop for myself and the community is also up on Youtube [2].

[1] https://social.kernel.org/notice/B1QVooy6voIN85T33I
[2] https://youtu.be/f09kvPvYMsM?si=EXUiMTrZSpwTXMGy

#ossummit #linux #kernel #hkml

Now the videos of my LPC sessions are also available on Youtube.

Page-level and Fleet-wide Data Access Monitoring for Meta: https://youtu.be/GolUxZZrVsU?si=zGk7WrO-Ap8quhR2

Actionable Data Access Monitoring Output Data and Format: https://youtu.be/xCrVjjbBFME?si=Vg7-tXpWbRGpCMVC

DAMON-based Pages Migration for {C,G,X}PU [un]attached NUMA nodes: https://youtu.be/0jWF8Ogi4Fk?si=gLbRz8d5MM-W7eek

FYI, if you're interested in all past DAMON presentations: https://damonitor.github.io/posts/damon_publications_talks/

#linux #kernel #damon #linux_plumbers #lpc #2025

RE: https://social.kernel.org/objects/f889da08-9524-4789-8949-316baa2d3374

According to LWN kernel source DB, the number of my Linux mainline commits exceeded 1,000 with 6.19-rc1. It feels like a moment to me.

Most commits were made for DAMON, but the 1,000-th commit was for zswap ;)

$ git log --oneline --author "SeongJae" | grep damon | wc -l           
872
$ nr=0; for c in $(git log --pretty=%h --reverse --author "SeongJae"); do nr=$((│[43] [PATCH v3] mm/damon/sysfs-schemes: Remove outdated TODO in target_nid_store() (Swaraj               
nr + 1)); if [ "$nr" -eq 1000 ]; then git log "$c" -1 --pretty="%h %s"; fi; done                                                                 
0fdaa13ee93a Docs/admin-guide/mm/zswap: s/red-black tree/xarray/

#linux #kernel #damon #zswap

At the 2025 #Linux #Kernel Maintainers Summit this week the "rust for Linux" experiment has just been deemed concluded (https://lwn.net/SubscriberLink/1050174/6b6d55c90ce1100f/ ).

Rust for Linux maintainer Miguel Ojeda now submitted a patch to follow up on that and remove the "The Rust experiment" section from the #Linux #kernel's docs, as "Rust is here to stay":

conclude the Rust experiment – https://lore.kernel.org/lkml/20251213000042.23072-1-ojeda@kernel.org/

He writes:

""The Rust support was merged in v6.1 into mainline in order to help determine whether Rust as a language was suitable for the kernel, i.e. worth the tradeoffs, technically, procedurally and socially.

At the 2025 Linux Kernel Maintainers Summit, the experiment has just been deemed concluded.

Thus remove the section -- it was not fully true already anyway, since there are already uses of Rust in production out there, some well-known Linux distributions enable it and it is already in millions of devices via Android.

Obviously, this does not mean that everything works for every #kernel configuration, architecture, toolchain etc., […]

But the experiment is done, i.e. Rust is here to stay.

I hope this signals commitment from the kernel to companies and other entities to invest more into it, e.g. into giving time to their kernel developers to train themselves in Rust.

[…]""

#LinuxKernel #Rustlang

""#Rust in the [#Linux] #kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off […]""

https://lwn.net/Articles/1049831/

#Rustlang #LinuxKernel

The end of the kernel Rust experiment

https://lwn.net/Articles/1049831/ #LWN

[$] An open seat on the TAB

As has been recently announced, nominations are open for the 2025 Linux Foundation Technical Advisory Board (TAB) elections. I am one of the TAB members whose term is coming to an [...]

https://lwn.net/Articles/1049035/ #LWN

A number of DAMON changes for Linux 6.19-rc1 has merged into the mainline as a part of MM subsystem pull request [1]. I again recommend people to read Andrew's great summary of the important changes on MM subsystem.

Among the DAMON changes, below four specially come to me. I hope the first change to help my ex-colleagues, and appreciate to Quanmin and Bijan for their continued DAMON works. Fourth one is only for celebrating my Camino challenge completion;)

1. Per-memcg per-node memory usage based DAMOS auto-tuning [2]. This allows cgroup-level NUMA memory management, such as hot pages promotion, cold pages demotion and reclaim. This was developed as a collaboration with my now-ex-colleagues at Meta.

2. Address alignment fix for DAMON modules [3]. This was developed as a followup fix of ARM32 LAPE support, by Quanmin from Huawei.

3. Pin-point targets removal [4]. This was developed as a collaboration [5] with Bijan, as a followup of his vaddr-based DAMOS-migration to multi-destination nodes.

4. Kunit tests for online parameters commit [6]. I started working on this on the Camino de Santiago[7]. It has delayed much longer than I expected, but I finally made it.

[1] https://lore.kernel.org/20251203212918.82f1c9d3947940aeae263878@linux-foundation.org
[2] https://lore.kernel.org/20251017212706.183502-1-sj@kernel.org
[3] https://lore.kernel.org/20251020130125.2875164-1-yanquanmin1@huawei.com
[4] https://lore.kernel.org/20251023012535.69625-1-sj@kernel.org
[5] https://github.com/damonitor/damo/issues/36
[6] https://lore.kernel.org/20251111184415.141757-1-sj@kernel.org
[7] https://social.kernel.org/notice/AyFZuW4Infc0st1NjM

#linux #kernel #damon #pullrequest #6.19-rc1

I will be in Tokyo next week. I will have four sessions on OSSummit and LPC. I also reserved the full week for potential in-person and/or virtual DAMON beer/coffee/tea chats [1]. Even if you don't have a topic for DAMON, if you don't mind shaking my hand, please feel free to reach out to me and say hello :)

[1] https://lore.kernel.org/20251205195509.76051-1-sj@kernel.org

#linux #kernel #damon #ossummit #lpc #linux_plumbers

The last 5.4.y kernel release has now happened: https://lore.kernel.org/all/2025120319-blip-grime-93e8@gregkh/

Please don't use this branch anymore, it's really old, and pretty obsolete, and has over 1500 unfixed CVEs in it:
https://lore.kernel.org/all/2025120358-skating-outage-7c61@gregkh/

And if you are stuck with that kernel version for some reason, go ask your vendor to fix those 1500+ CVEs, otherwise you are paying for support that doesn't actually do anything for you...

#Linux 6.18.y is now officially a longterm kernel series, as can be seen here:

https://www.kernel.org/category/releases.html

Projected EOL is Dec, 2027 (two years from now) – just like the 6.1.y series. All the other series as of now are scheduled for EOL in about one year from now – and 5.4.y just was EOLed, as planned (see https://social.kernel.org/objects/da258e20-22b9-4805-a9e5-5a506eb2bf91 and https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=0f52d79a5053091c95a269ff6fddbece27ea1d64 ).

Note, the kernel.org front page for the next ~two months (e.g. until 6.19 is out) will keep listing 6.18.y as latest stable series, as it might break peoples scripts to call it longterm there:

https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=b9ea3472ee1d973f4c27d075c7e4445afa7ade89

Heya, Heya!

Before the presents land under the Christmas tree, we’re super happy and honored to reveal the name of our godfather for the 2026 edition: @corbet.

Huge thanks to him for giving us a bit of his time — we know how precious it is.

I was unable to take time on DAMON cpus/write-only monitoring extension project nowadays, while I privately receiving more interests and test results. Hence trying to take more time on it, and shared a rough plan for clarifying expected timelines: https://lore.kernel.org/20251128193947.80866-1-sj@kernel.org

The plan is also available on the blog: https://damonitor.github.io/posts/damon_cpus_write_monitoring_rfc_v3_plan/

#linux #kernel #damon #cpus-only #write-only #development_plan

@vbabka Yes, I remember that. Nevertheless I was unable to "confidently" say it, since someone who has no good way to check the fact might think I'm lying. That's why I'm happy with this great integration work :D. Anyway, appreciate all people who made this availableSUSE, including you!

@vbabka Glad to be able to confidently and proudly say CONFIG_DAMON is enabled on the one of best Linux distros, OpenSUSE https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DAMON

#linux #kernel #damon #opensuse #oracle_kconfigs

RE: https://mastodon.social/@vbabka/115582339822470165

> this gives me a motivation for unifying the capacity and bandwidth expansion solutions. I may share a thought soon on the mailing list.

Just posted a rough and early idea about how to provide a holistic tiered memory management for both capacity (or, latency) and bandwidth: https://lore.kernel.org/all/20251114014255.72884-1-sj@kernel.org/

FYI, I got the idea from a chat with a dynamic interleaving developer at Micron, as I also noted on the mail, and HMSDK talk gave me more motivation to develop it.

#linux #kernel #damon #tpp #bandwidth

RE: https://social.kernel.org/objects/75d16f79-f7b5-40f5-8c41-14ec3274fac1

SK Hynix HMSDK presentation video at OSSummit Korea is now available: https://sched.co/2913n

As a part of the talk, HMSDK's CXL memory capacity expansion, which utilizes DAMON internally, is also introduced. It provides detailed explanation of design, their test setup, results, and even a multi-threads based tuning tip. Especially the evaluation using an LLM workload is impressive to me.

Also, this gives me a motivation for unifying the capacity and bandwidth expansion solutions. I may share a thought soon on the mailing list.

#linux #kernel #damon #hmsdk #ossummit_korea

Japan visa applications need to be in by 17 November at the latest: https://lpc.events/blog/current/index.php/2025/10/29/japan-visas-need-a-longer-processing-time/

Abstracts of my LPC sessions are available now.

- "Page-level and Fleet-wide Data Access Monitoring for Meta", Refereed tack, Friday afternoon: https://lpc.events/event/19/contributions/2075/
- "Actionable Data Access Monitoring Output Data and Format", Linux System Monitoring and Observability MC, Thursday morning: https://lpc.events/event/19/contributions/2059/
- "DAMON-based Pages Migration for {C,G,X}PU [un]attached NUMA nodes", Device and Specific Purpose Memory MC, Thursday morning: https://lpc.events/event/19/contributions/2066/

#linuxplumbers #linux #kernel #damon

RE: https://social.kernel.org/objects/7f6edd64-5fbf-4a5d-b192-d00894198ca0