Microsoft copies AppGet, open source law has a long way to go

The “plagiarism dispute” between The Open Source Project AppGet author Keivan Beigi and Microsoft’s WinGet project has recently been updated. Microsoft responded by admitting that it had “failed Keivan and AppGet” and acknowledging Keivan and AppGet’s contribution to Microsoft’s new projects.

In May, Microsoft unveiled winGet, a new package management tool, at the Build 2020 conference and opensource it. Shortly after WinGet was released, Keivan Beigi, author of the Open Source Package Management Tool AppGet Project, announced the “death” of the AppGet project, pointing to Microsoft’s WinGet copying AppGet.

Microsoft copies AppGet, open source law has a long way to go

AppGet is an open source Windows package management tool that automatically installs software on a Windows PC. Author Keivan Beigi is a software engineer living in Vancouver, Canada. Last July, Andrew Clinick, product manager for Microsoft’s App Division, began reaching out to Keivan to express Microsoft’s interest in AppGet and saying he could offer Keivan a position at Microsoft to develop a software package management project for Windows systems. During this time, Andrew conducted several interviews with Keivan on the grounds of exchanging views and obtained ideas for the development of AppGet. In December, Keivan gave a full-day interview at Microsoft’s seattle headquarters, and things were heading for good.

For the next six months, however, Microsoft did not contact Keivan again. It wasn’t until May of this year that Keivan suddenly received an email from Microsoft: “I’d like to take a moment to tell you that we appreciate your input and insight.” We’ve been building windows package managers, the first preview will be available tomorrow in Build, our package manager will be open source, and we welcome any contributions from you. “Then Microsoft released WinGet on Build.

Keivan said he was shocked when he saw the announcement and WinGet’s code. Keivan believes that WinGet’s core mechanisms, terminology, manifest formats, and structure, and even the folder structure of the package repository, are shadowed by AppGet. Microsoft’s description of AppGet in its announcement has only one sentence , ” … There are many other AppGet, Npackd, and PowerShell-based OneGet package managers. “

Keivan was disappointed by Microsoft’s approach, saying it had no problem copying his open source software, but wanted the right honors for his work. To that end, he published the “Death of AppGet” article, announcing that he was abandoning an update to the AppGet project because there was no point in competing with developers of this magnitude with Microsoft.

Microsoft copies AppGet, open source law has a long way to go

As for Microsoft interviewer Andrew,” Keivan tweeted: “I don’t want to stand on the opposite side of WinGet, I don’t want anyone to be fired for this, I just want to share some of the injustices I’ve had in this story.” “At the same time, he doesn’t want to ruin a good product because of some personal grievances, and he wants Microsoft to give a proper answer.”

“Last summer, we talked to Keivan about potential opportunities to jointly provide Windows Package Manager,” Microsoft Product Manager Andrew said in an official Microsoft message on May 30. AppGet has many qualities that can really help us find a better product direction for WinGet. Recognize son and AppGet’s contribution to the Microsoft WinGet project. “The purpose of Windows Package Manger is to provide products that enable communities and users to contribute and gain recognition, which is why we’re building it on GitHub; over the past few days, we’ve listened to the community and learned from it, and it’s clear that we’re on the losing end.” Rather, we failed Keivan and AppGet. This is the last thing we want to see. “

Andrew also explicitly lists several AppGet contributions to Help WinGet get Better:

There is no script during the installation – we fully agree, but MSIX is not allowed

Rich inventory definitions in GitHub – Open capabilities combined with rich declarative metadata for applications are critical to achieving your goals

Support for all types of Windows application installers (including Win32/Win64)

Seamless updates to applications in the repository 

Andrew expressed the hope that he would take the opportunity to express his gratitude for the development of The AppGet provided by Keivan and for his collaboration with Microsoft. And hopefully in the future to work with Keivan and other developers to make WinGet better.

Although Microsoft acknowledged AppGet’s contribution and expressed its gratitude, it still did not apologize for the whole thing, and some netizens expressed their dissatisfaction.

Microsoft copies AppGet, open source law has a long way to go

Even some netizens said, “This everything is clear, Microsoft began to open source, in order to more convenient to steal other people’s labor results?” “

In fact, the taunts of netizens are not a trend, as early as June 2018, Microsoft has been exposed to similar plagiarism incidents. At the time, the open source multi-pack repository management tool, Lerna author Jamiebuilds, accused Microsoft of copying its code.

Jamiebuilds says that when you work for Babel 6, you find everything split into nice widget packages, but you also need to manage dozens of packages. As a result, Lerna.js, a multi-pack repository management tool, came into being. To make the project work better, he rewrote the project five times to try to perfect the architecture. Then, jamiebuilds discovered that Microsoft had introduced a new design system of many small packages, which it thought was Microsoft had used Lerna in a project, only to find that they were using something called “Rush”.

Perhaps Rush is a branch developed by Microsoft based on Lerna? With this in mind, Jamiebuilds took a closer look at Rush’s Git log and found that the project was created a few days after Lerna was created, and that other similar tools, including Lerna, were described in the document, calling it “not good enough products”, which looked like “Rush is an original tool better than these products.” To understand the difference, Jamiebuilds compared the two projects and found that Rush’s file and directory naming, core functionality code is exactly the same as Lerna’s, and even the commit record is consistent, which means Rush is constantly copying Lerna’s changes and then claiming that it was an original work developed by Microsoft.

Microsoft copies AppGet, open source law has a long way to go

Jamiebuilds said he was shocked and apologized after he contacted a Microsoft employee he knew about the incident, but there was no reasonable explanation from the authorities. The Rush project did not change the license or add additional instructions, but confused the commit record, movethe the code location, and rewrite or rename some functions.

Jamiebuilds mentioned that if someone else had done it, he might have been a little upset but ignored. But he was angry that Microsoft, a trillion-dollar software giant, did such a thing.

The matter will not end up. It’s worth noting that this time Lerna’s developers didn’t choose to give in to Microsoft. Now with 23k Star on GitHub, Lerna is such a star project that Microsoft later changed its multi-pack storage management tool to Lerna in its own project, Just.

While the plagiarism may have been caused only by the inappropriate practices of individual Microsoft employees, Microsoft’s series of plagiarisms has raised concerns in the open source community. In fact, someone’s code in the open source community or copy is not a bad thing. But Microsoft’s behavior of crediting the fruits of other people’s work is a clear violation of the ethics of the open source community and, of course, the open source protocol.

At present, many software engineers generally do not understand open source protocols. Some people even think that open source software is free software, so I can use it without restrictions. This is clearly a misunderstanding.

According to industry lawyers, open source software and proprietary software and other closed-source software, are protected by law. The copyright of open source software is neither abandoned nor expired, and the author still enjoys the copyright. In addition to copyright, open source software may also be regulated by contract law, patent law, trademark law and other laws. In the context of copyright law, software code is protected like a writing work. After you have obtained a piece of source code, it cannot be adapted or redistributed by default. Open source software, on the other hand, is characterized by the fact that for some loose open source protocols (e.g. MIT, Apache 2.0), the author waives and transfers some rights, such as allowing the user to adapt or redistribute the code, if the user promises to meet certain conditions (usually including signing the author and attaching a license).

The lawyer said that the terms promised by the user and some of the rights waived by the author formed a contractual relationship, more specifically the licensing contract, which in the case of open source software, which is what we often call an open source license (License). A license is a non-negotiated, standardized public contract that reduces the cost of a contract.

In theory, a project using a loose open source license such as MIT, Apache 2.0, the source code can be modified, distributed, or even commercialized by anyone, but the copyright of the original author of the project, that is, the copyright notice of the project author is retained in part of the source code reference. In the case of the MIT License Agreement, which provides that the authorized person is obliged to perform its obligation to “include a copyright and license notice in all copies of the Software and Software.” In other words, Microsoft’s use of open source source to develop new projects itself has no problem, but its refusal to fulfill the “protection of the copyright of the original author of the software” under the open source agreement is in fact a violation of the open source agreement.

Although open source code for open source projects is protected by open source protocols, open source projects maintained by individual developers often have difficulty defending their legal rights in the face of large enterprises of Microsoft-level levels. Larger open source projects are often handled by a specially established foundation that sits on a neutral open source foundation that has the right to handle project authorization, change open source agreements, and to be ready to deal with legal disputes arising from project authorization issues. However, the copyright of individual-developed projects belongs to the developers themselves, in the face of similar infringements, it is clear that there is not enough human and financial resources to deal with these legal disputes, in most cases can only be lost. Therefore, when individual developers decide whether to open their projects, it is important to measure the pros and cons of open source, fully understand the terms of various types of open source licenses, predict the possible consequences of the project open source, and think twice. Similarly, when we use the code for open source projects, we must respect the work of the original author and consciously fulfill the obligations required by the open source agreement.

Finally, end with a sentence in Who’s Blocking Our Innovation:

“We’re always used to asking for it and forgetting to give back. “

Microsoft copies AppGet, open source law has a long way to go