I hoped the “Leaving the Sinking Zazuko Ship” blog post would be the last post about Zazuko, but then they stole my code.
If a code snippet in one of my packages is useful for you, feel free to copy a few lines. I’m not that picky about it. If you need a whole class, adding my package as a dependency is probably a better choice. If, for whatever reason, you think it’s a good idea to fork my package, I would be happy to hear why and discuss if we can find a solution to work on a single code base collaboratively. Legally, most of my packages are MIT-licensed, and you are free to fork them. But if you take a complete package, remove my name from the source, and make it look like it’s your work, that’s deliberate theft and absolutely not OK.
Zazuko did exactly that. When I first stumbled over it, I tried to look at it from different perspectives because I thought they couldn’t be so brazen. What did they do? Let’s have a closer look:
What Happened?
I got a notification about a pull request named “Rebrand as @zazuko package”. Right after it was created, it was closed again with the message, “Sorry, this was meant as PR in the fork itself.” The PR contained just what the title says: Some adaptation to the CI, but mainly the removal of my name from the package and making it look like a Zazuko package. They copied the complete git history, so my name can still be found somewhere in the commits, which means they didn’t try to hide the fact that they forked it, right?
Searching for a Package
Let’s have a look at this from the perspective of a developer looking for a package. Based on which criteria does one select a package?
- Does it have the required features?
- How long has it already been maintained? (commit count)
- Is it maintained by known people? (contributors)
- Has it been updated recently? (last commit)
- Is it a fork?
What developers typically don’t check:
- The content of the commits in the git history.
Based on that list, would someone stumble over my name, and how attractive is the package based on the listed criteria?
Their “Fork”
1., 2., and 3: The fork benefits from being a 1:1 git clone without having the “drawback” of being noticed that it is not work done by them.
4: Nobody would notice my name. Depending on how they continue their work, the package could stay attractive.
5: That point is more complicated. GitHub provides the function to fork a repository. A reference to the original repository would be shown below the name of the repository. But that feature was not used. A new repository was created, and the git history was copied. Also, the readme doesn’t mention that it’s a fork or refers to my repository, so nobody would see my name. If the original package is still maintained, a developer would very likely choose the original over the fork, which is the case for this package. If a package is no longer maintained, and if it is a well-known package, a fork can benefit from the reputation of the original package. Zazuko maintains a fork of Ontodia and YASGUI. The readmes in booth repositories contain the information that it is a fork and refer to the original repositories. If it is in their favor, they happily add that reference.
6: That would be the only way that someone spots my name, but nobody does it.
The code is MIT-licensed, which means you have a lot of options. You can make an open-source fork, and you can even make a closed-source fork, but you can’t claim it’s your work. Copying the git history looks at first glance like they didn’t deliberately steal it and try to hide it, but at a closer look, they did everything to make it look like they contributed an open-source package to the community and by removing my name, they crossed the line in terms of what is legal.
“Response”
Right after I noticed the PR, before I was able to have a closer look, I added a neutral comment to the PR, “I recommend restoring my credits. If you forked any of my other packages, I suggest you also do it there.” All I got in response was, “Fair enough”. My name was restored in the fork, but I had to search for it myself. I didn’t get a link to the PR or even just the repository of the fork. My question of whether other repositories are affected remained unanswered.
Small Mistake or Company Strategy?
Was it just a mistake from a single employee? I would not call the person who created the PR a team player, but I also didn’t expect he would do something like that. Also, the PR to the Zazuko repository was reviewed by another employee. However, it’s not a surprise based on an earlier event I didn’t include in the previous blog post because it was already that long. The origin of most of my open-source projects goes back to the time before Zazuko was even founded. I maintain them in my spare time and never handed them over to Zazuko. That was confirmed multiple times by the CEO, later even in written form in the contract where I handed over my company shares. In that contract, he confirmed that the packages remain my property. Nevertheless, when it looked like I would leave the company, he tried to get control over my work by coercion. I told him I would no contribute to packages he controls, and that would be the end of RDF-Ext and many RDF/JS packages, but he didn’t care. When the other co-founders and I were still in the company, we insisted on contacting the original author of a package before we considered forking it. With the lack of that control instance, one can see that the fish rots from the head down, and no moral or legal boundaries exist for this company anymore. This company is everything but an asset to the open-source community.
Aftermath
Because of that code theft, I blocked all Zazuko employees from my GitHub organizations. All of their email addresses have been put on the spam list. Zazuko and all employees of that morally bankrupt company are no longer welcome at my projects. I extended the tools I developed to manage my repositories to analyze dependencies and replaced questionable dependencies. Regular SBOM analysis will be performed to ensure that my packages can be used without running into problems. I closed the SHACL-UI group, in which one Zazuko employee participated. The process of kicking out a single person would have been too annoying. I just wanted to get rid of toxic people as fast as possible and instead work on something productive. I still like working on specifications. One can learn a lot by trying to understand the position of other participants, but it requires a certain level of respect for each other that employees of this organization do not have. For future work, I therefore see it as an exclusion criterion if such toxic people participate.
FAQ
Many people contacted me after I published the “Leaving the Sinking Zazuko Ship” blog post. They told me about similar experiences and some about their personal experiences with the Zazuko CEO. Some questions were asked several times and may come up again in the future, so I thought it’s worth answering them here.
Reaction
Do you expect some reaction from the CEO?
No, I guess he knows the Streisand Effect, and I wrote only about events where there is proof. Denying it in public would for sure fall back on him.
RDF-Star
What do you think about RDF-Star (working group)?
I know some of the people doing the actual work, and they are smart folks. The group has two chairs, so I expect that that single chair has little influence in that group.
What do you think about RDF-Star (usage)?
Usually, you will not need it in standard data modeling tasks. Typical use cases where it makes sense are in a different layer - for example, maintaining a history of the statements like in Wikidata. A typical use case for me will be scoring statements in the context of machine learning.
Zazuko Packages
Can I use Zazuko packages?
Obviously, I can only recommend not using them. Besides the risk of using stolen software, one should not expect substantial new features as the creative minds left the company in 2022/2023. If you are using a package with no replacement available, I recommend pinning the version, checking the version history, and closely looking into the commit history when updating the package.