Category Archives: Open Source

What to know about GPLv2 vs GPLv3

An important thing to note about the GPLv3 is that it is not just an incremental improvement or modernization of the GPLv2, contrary to its name.

It’s effectively a different license that’s even one level stricter than the GPLv2 in a substantial way.

In addition to the base requirements of the GPLv2 for releasing source code for distributed binaries, it goes one step further and requires that modified binaries can be installed onto the hardware that distributed the original binaries.

Unlike simple release of source code, this has engineering implications for hardware manufacturers. It prevents “locked down” devices and forces devices to be open and reprogrammable. “Tivo-ization” is a term referring to the practice of “locking down” a device, which is often used in discussions around GPLv3.

This is why Linus Torvalds refused to adopt GPLv3 for Linux, because in his view, this was going too far.

So if you’re in the market for a copyleft OSS license, keep in mind that GPLv3 is not automatically the best fit, and should not necessarily be automatically used over GPLv2 just because it’s the newest version in the “GPL series”.

It represents an additional step of strictness on the restrictiveness scale. If you’d like distributors to release source code, but don’t necessarily need them to make their devices openly programmable, GPLv2 is still the license to use.

Resources:

Find your own bugs

Audio version: https://podcasters.spotify.com/offlinemark/episodes/Find-your-own-bugs-e2i15vc

Contributing to open source is a popular recommendation for junior developers, but what do you actually do?

Fixing bugs is a natural first step, and people might say to look a the bug tracker and find a simple bug to fix. However, my advice would be to find your own bugs.

In 2019, I had some free time and really wanted to contribute to the LLVM project in some way. Working on the actual compiler seemed scary, but LLDB, the debugger, seemed more approachable.

I went to the LLVM Dev Meeting, met some LLDB devs, and got super excited to contribute. I went home, found a random bug on the bug trackers, took a look for all of 30 minutes, then … gave up. Fixing some one else’s random string formatting bug simply wasn’t interesting enough to motivate me to contribute.

3 months later I was doing some C++ dev for fun. I was debugging my code and ran into a really, really strange crash in the debugger. It was so strange that I looked into it further and it turned out to be a bug in LLDB’s handling of the “return” command for returning back to the caller of the current function. The command didn’t correctly handle returning from assembly stubs that don’t follow the standard stack layout/ABI, and caused memory corruption in the debugged process which eventually led to a crash.

This was totally different. I had found a super juicy bug and dedicated a couple weeks to doing a root cause analysis and working with the LLDB devs to create a patch, which was accepted.

So if you want to contribute to open source, I would agree with the common advice to fix some bug, but would recommend finding your own โ€” it will be way more rewarding, fulfilling, and a better story to tell.

https://twitter.com/offlinemark/status/1778483168611610940
https://twitter.com/offlinemark/status/1208491737099882496