The Demo That Wasn't

In 2005, I was deep in the DTrace ecosystem. Sun Microsystems had released the dynamic tracing tool, and I was making a name for myself by publishing my own open-source scripts — the DTraceToolkit and related utilities. But there was something curious happening at Sun. They were cranking out far fewer DTrace tools than I was, which made me wonder if a bigger internal project was absorbing their energy.

At the time, I was based in Sydney, doing training and consulting for Sun. One day, I was told a very important person from the US would be visiting — a DTrace developer on a world tour, showing off a new product built on the technology. This had to be the big internal project. A developer on a world tour meant this was something extraordinary.

A Meeting in Sydney

The VIP arrived weary from travel — he had come from South Africa and New Zealand, and was headed to more destinations. He didn't recognize my name or my DTraceToolkit. To him, I was just some random local guy. After a brief, low-key introduction from the Australian Sun staff ("Brendan teaches some classes for us, and has been doing some DTrace stuff"), I tried to correct the record by mentioning my open-source work. No reaction.

He offered a demo anyway. The product was a GUI add-on for a familiar Sun interface. You could double-click an icon to run one of several DTrace tools, viewing either raw output or line graphs. Honestly, it was underwhelming — the GUI already did all that. The only new piece was the handful of tools themselves. He gave his sales pitch, clearly not expecting me to grasp their real value. But I did understand them — I'd built equivalent functionality myself.

"I've done these before – I've written tools that do these things myself!"

The look he gave me suggested he didn't quite believe that.

A Familiar Script

Browsing the GUI, I spied a tool for tracing socket I/O. That one caught my attention. In 2004, I'd written an incomplete attempt at socketsnoop.d using black-box analysis — no kernel source access — and published it as open source with warnings about its gaps. Sun's engineers, having full source access, could finish the job properly.

"Can I see the socket I/O script?"

He was initially alarmed, then recovered: "Well, sure, you could even add more tools to the GUI!" — then, as an aside, "if you have them." I had them, all right. He gave me a path to his tool directory. The names were all familiar. One was even called socketsnoop.d.

A realization crept in. I printed the file. It was my script — same weird formatting, same early coding style, same workarounds from before the days of defaultargs. It was the same incomplete attempt I'd hacked together a year earlier. I printed the other tools, and they were all mine, too.

"This is MY script."

My jaw was on the floor. He still didn't believe me.

Stripped Credit

To prove it beyond doubt, I grepped his tools for my name — it was in the header comment of every script I'd published. Nothing. My name had been stripped. Some of my files even carried this line:

# Author: Brendan Gregg  [Sydney, Australia]

Now he was in Sydney, trying to sell Brendan Gregg's tools to Brendan Gregg.

An Australian Sun staffer pointed out: "Those say copyright Sun Microsystems." The original copyrights and licenses — GPLv2 or CDDL — were gone, replaced with Sun's standard header.

"You deleted my name! And the copyrights and licenses!"

The other Aussie piped up, addressing the VIP directly: "You can't do that." Silence. Everyone realized the scope of what had happened. While some people at Sun were cultivating open-source contributors, others were ripping them off — taking work, stripping licenses, and packaging it as proprietary product.

The VIP was confused and mostly defensive, explaining he hadn't known and might have received the tools from someone else in that state. The meeting wound down quickly. I suggested he grab updated copies directly from the DTraceToolkit, since those old versions had bugs I'd already fixed, and reminded him to keep my name, copyright, and license attached.

Perhaps the outcome would have differed had my introduction been more substantial. Australian culture, with its "tall poppy syndrome," favors understated introductions — a contrast to American professional self-promotion. In that context, maybe my low-key intro cost me credibility in that room. But it hardly excuses what had happened.

A Pattern of Rebranding

The demo wasn't an isolated incident. A few years later, Apple bundled dozens of my tools into macOS, preserving my name, copyright, and the CDDL open source license. Oracle did the same for Solaris 11, as did the BSD community for FreeBSD. Those were proper integrations, and I'm grateful for them.

But the underlying attitude at Sun wasn't unique to one careless employee. My consulting colleagues and I had encountered it before: a conviction that only Sun could build anything worthwhile with its own technologies, and that anything created outside the company was worthless. When Sun engineers did find something good, they tended to assume it must have originated internally — and therefore it was safe to reuse, rebrand, and relicense as they pleased, since they believed they already held the copyright.

That said, some people at Sun did make genuine efforts to respect my work. On at least four other occasions, my DTraceToolkit was incorporated into observability products without stripping the licenses. In one case, they wanted to relicense to GPL and consulted both me and Sun's legal team about it — but that's a separate story.

Not the Last Time

This wasn't the final occasion someone tried to sell me my own creations; it was just the first. Over time, I've stopped telling salespeople that I'm the author of what they're demonstrating. They give me strange looks, as if I'm delusional. Instead, I simply say, "I have a lot of experience with that technology," and move on.

I'm thinking back to this incident because my BPF tools are now making their way into observability products, at a scale that will likely dwarf the DTrace era. My immediate advice to developers is this: build on my BPF tools and the bcc libraries (whether the Python or libbpf-tool variants) rather than rewriting them from scratch, and pull in updates regularly. These are works in progress; forking them divides engineering resources and leaves your customers running outdated versions. I've laid out the details in my post on how to add eBPF observability to a product.

Flame graphs are the exception. That software is a simple, finished algorithm requiring little maintenance, so rewriting it isn't a serious problem — though acknowledgement is always appreciated.

The Unbelievable Part

So what made the demo unbelievable? It wasn't the impressive DTrace product tour I had envisioned. It was my own tools being shown back to me. It's probably not rare for an open source developer to eventually find their code rebranded somewhere. But the details here are unusual: an American developer toured the world showcasing software he didn't write, and in Australia he delivered the pitch and demo to the actual author — without ever saying thank you.