Still seems pretty tone-deaf to me - obviously MS seems to be in the legal clear, but the moral high ground and lots of dev goodwill has been lost.
It also damages the ability for devs to informally meet and chat with PMs at larger companies everywhere - adds a lot of mistrust to the eco-system.
This is not that MS came up with their own package manager. It's the entire song-and-dance routine that was conducted about potentially hiring Keivan, and then ghosting the engineer whose open-source product you were simultaneously cloning.
Of course, people will forget, but many will still remember. This is still a net-negative all-around when it didn't need to be.
Edit, this ZDNet article adds no new information and nothing has changed since the other articles have come out, but I guess it's good that more places are covering it to signal boost this properly.
FWIW this has been discussed here (please HN do not spam it) where both Andrew and Keivan have started talking, and it seems then they took it to a private convo:
This was no regular interview, it’s quite dishonest of you to say that. Second, be honest; do you have any stake in the game yourself? Do you work for microsoft?
> This was no regular interview, it’s quite dishonest of you to say that.
How so? It was an interview for him to bring AppGet in-house to Microsoft. That's normal software business.
Honestly, based on what this Keivan said - I think he scared Microsoft away with his demands that they take the project only in a direction that he approves of.
And when they went away, they took some of the most banal ideas, ideas that have been done a thousand times in other projects and used them in their own - which they built in a completely different programming language with exception to the very, very common YAML configuration.
> Second, be honest; do you have any stake in the game yourself? Do you work for microsoft?
Nope. People who disagree are simply wrong and I'm attempting to correct their ill-formed point of view.
Meanwhile, you're shitting up the comments with this trashy ad hominem insinuation of shilling. It's against the rules and you should stop doing it - https://news.ycombinator.com/newsguidelines.html
I have a different reading of this. I think this is them doing the best they can within the limits set by microsoft's legal department. They cannot legally admit they looked at his code and copied the structure, because that opens them up to a copyright suit. In the blog post it seems they went as far as they could: admitting to being influenced by the ideas, without having actually copied any of the code.
If they really want to fix this, they need to pay AppGet's author some money, and get something in writing so they are legally protected from copyright suits. I assume they're negotiating this right now, and that once this deal is done there will be another blog post that is more genuine.
They really messed this up because it would have been cheap to get something in writing before releasing WinGet. Someone at microsoft legal dropped the ball.
AppGet is open source, under the Apache 2.0 license: https://github.com/appget/appget. That means basing a new project off AppGet - including using its source code - is legally permissible.
edit: This is explicitly not a judgement of ethics.
Forking is permissible, but you still have to adhere to the terms of the Apache License 2.0. You can't remove copyright notices, you must provide attribution, if you release source you must indicate what you changed, etc.
That Microsoft didn't do any of that indicates that they do not believe that WinGet is a derivative work of AppGet under copyright law, so the copyright license granted by the Apache License is not needed.
ETA: That is, Microsoft believes they don't need a copyright license. My personal position is that I would have liked to see a proper fork under the ALv2 with attribution, which would have avoided all this mess.
WinGet is open source under the MIT License, which I believe keeps them in the clear: https://github.com/microsoft/winget-cli. In practice, I've never heard of any legal problems when a derivative project is also open source under a similar license. (Yes, the licenses are different. But I also believe they are considerable compatible.)
No, that's wrong. You can't just slap a new license on top of code you've copied — that's illegal!
You have to adhere to the terms of the copyright license granted in this case by upstream License. If you do not, you lose the copyright license and the ability to redistribute under any terms.
Maybe you're thinking of license subsumption? That's when (say) a project under a more restrictive license (e.g. Apache License 2.0) bundles a dependency which is under a more permissive license (e.g. MIT), yet the package is advertised as being under "Apache License 2.0" even though the licensing is polyglot.
But even under subsumption, you still don't get to do things like removing copyright notices or declaring unilaterally that somebody else's work is now under some new license they didn't grant. The license headers in the bundled dependency's source files don't get modified, it's just that you summarize the terms of the complete package because fulfilling the terms of the ALv2 suffices to fulfill the terms of the MIT license. (Sort of. License subsumption is a complicated issue.)
Yes. Plenty of projects have gotten "in trouble" for copying code and illegally changing the license, either inadvertently or deliberately. The punishment is generally a complaint, and the remedy is that they fix the attribution. Examples:
Such problems do not end up in court for two reasons.
First, it costs very little to bring a project into compliance with a permissive license — all you need to do is give attribution. It's not like GPL enforcement, where you have to choose whether to open source your proprietary code or to purge the GPL'd code from the project in order to achieve compliance.
Second, the culture of permissively licensed open source communities is such that they don't generally want to foster a litigious environment which would frighten business users.
I'm mean I know it would be nice to toss him some money. And it sucks when companies ghost people. But really isn't the point of open source that everyone can do what they want with the code? And if you're not distributing the actual code, why do you owe them anything?
If I gave credit to everyone who influenced the code I write, the file would be huge. Does the world have enough disk drives to hold all the credit where credit is due?
decency, morals, thoughtfulness, that kind of thing
> If I gave credit to everyone who influenced the code I write...
They directly ripped it off.
Big companies will try not to pay even when they have money. To not even give the minimum of non-monetary credit is even less reason for me ever to release code under a "what's mine is yours licence".
They're not even written in the same language. And everything done in AppGet has been done before. Yawn
> Big companies will try not to pay even when they have money.
I will try not to pay, even when I have money. I think this applies to most people. Who wants to pays for something that's already free? I'm not running a fuckin charity over here.
> To not even give the minimum of non-monetary credit...
They've given it.
However, I wonder if during all of this Keivan has credited Microsoft for all of the open source tools, services and frameworks that he's used in his other work???
> Can you point out exactly what was "ripped off" here?
from his blog
"When I showed it to my wife, the first thing she said was, “They Called it WinGet? are you serious!?” I didn’t even have to explain to her how the core mechanics, terminology, the manifest format and structure, even the package repository’s folder structure, are very inspired by AppGet."
> I will try not to pay, even when I have money
Then people like you will kill off exactly the things they leech off, by pissing off those people who made them from their goodwill.
> However, I wonder if during all of this Andrew has credited Microsoft for all of the open source tools, services and frameworks that he's used in his other work???
I don't know, has he? Why raise the question instead of answering it.
> "When I showed it to my wife, the first thing she said was, “They Called it WinGet? are you serious!?” I didn’t even have to explain to her how the core mechanics, terminology, the manifest format and structure, even the package repository’s folder structure, are very inspired by AppGet."
I wonder if he mentioned his name was inspired by the extremely more well known and 22 year old default package manager in linux that happens to be called apt-get.
I mean honestly if he's saying that as justification in his blog post, I'm immediately off his team. That's insane. Obviously a layman would think the name was ripped off if they didn't know about apt-get.
There's NuGet (another package manager) released by MSFT in 2010.
I compared the manifest format, that's different terminology. And WinGet has more insightful supports, e.g. MinOSVersion, License, LicenseUrl.
And the folder structure is different also. That's per version per file on WinGet but single YAML on AppGet. I'm pretty sure his wife can't handle that if she is not a developer.
I agree. And just because it's a company making billions selling software doesn't mean they're obliged to pay you a great deal of money.
If Beigi was smart he would've asked them to purchase the copyrights as he's the only one legally entitled to do so.
If he's developing his software altruistically he should be satisfied with his credit, well knowing that his project will now be overshadowed by Microsoft's and will eventually pass into oblivion and be forgotten.
Side note: It's amusing that @aclinick doesn't have an avatar on GitHub, given these three facts: 1) @aclinick works for Microsoft 2) GitHub is a Microsoft property 3) LinkedIn is also a Microsoft property and has a very strict avatar policy
I want to clarify, my point was not to unleash a mob onto the MS PM, but rather to bring sunlight onto this issue and hopefully allow for a fix and prevention of this occurring again in the future. Health of the system and all that.
Nobody should get fired (Keivan himself said so in the Github issue), but now that there is some public attention on this, let the parties involved find an amicable way to resolve it their own satisfaction.
'He went for an interview at Microsoft's Redmond headquarters in December, which apparently "went well", but Andrew didn't inform him he would not get the job at Microsoft until six months later – on the day before the WinGet preview would be unveiled at Build 2020. '
This is bullshit. Keep him quiet with the hope of a job (embrace) until they release their version (extend, extinguish). Changing CEOs doesn't change everyone who works there.
Can we please stop trying to slide in an EEE reference everytime something comes up about MS?
You have clearly embraced EEE, but now you are extending it way past what it actually means, and if people like you continue you will extinguish it because it will not mean anything anymore.
We can stop talking about EEE when Microsoft stop practicing it. This time is just with regard to a community instead of a particular software product. WinGet is the “Extend” step where they overtake AppGet in usage and probably in package registrations until AppGet withers and eventually Extinguishes itself.
That's not remotely what EEE is about, which is my point.
EEE refers to a specific business practice that is not related to this story at all.
You can use other words in the language to convey that this particular move from MS is a dick move without having to use EEE. And reserve talking about EEE when it is actually relevant.
Using it all the time just completly dilute it until it becomes totally meaningless.
That's not how "embrace, extend, extinguish" works. That practice is in the context of standards, and not products. Microsoft was perfectly in its right to build a package manager. They based it on an open-source version that allowed copying and forking. So no issue there either.
They did string the developer along, but I'm not sure it was anything nefarious. I think the people at MS who were looking to acquihire Keivan ran into roadblocks at MS from higher-ups for whatever reason and it just fell apart. It probably wasn't a nefarious strategy to string Keivan along in order to boost their WinGet announcement - but just general inconsideration and rudeness in not communicating.
For me the worst thing about this entire fiasco is really Microsoft's brazen unapologetic predator behaviour.
They've invited Keivan to their headquarters with a bait, giving him the wrong impression that they wanted to help him with the project when really they wanted to extract valuable information from his experience. He's been working on AppGet for a while, ran into issues, thought about problems which users are having, dealt with certain challenges and iterated until he got to a certain understanding/vision of his product. This is all very very valuable information not published anywhere in an open source thoughts database. It's just the experience and knowledge that only lives in Keivan's head and Microsoft knew that they had to bait him with some false promises and hopes in order to get access to that information which he might otherwise not have shared with a competitor. Also they didn't forget about Keivan. They knew what they were doing. At the beginning of the process someone put in their calendar to contact him the day before BUILD 2020 to send him this email, which is why he got the email the day before the announcement of WinGet. This was no coincidence.
That is fraud in my opinion. Who cares about his source code, they stole much more valuable stuff from him. Anyone who doesn't see that is ignorant or blind.
What legal action, though? That is, what did Microsoft do that violates the law? I don't see anything. The code is open source, so I believe they're in the clear there. And I don't think they had a contract with Keivan, so I don't see any breach of contract disputes. To be clear, I think Microsoft acted unethically. But I don't see any obvious violation of the law.
If something feels incredibly wrong, there's a good chance that it is wrong. If something is wrong, there's a good chance that a good lawyer will find some legal basis on which they could seek for damages.
> Unfortunately, I don't see what legal action to take
Good for you. Someone else might still feel differently and want to check with a legal advisor to explore their options.
But he didn't license them to take code without attribution. If they had forked the codebase, maintained the copyright notices and adhered to the conditions of the Apache License 2.0, that would have constituted "credit".
Yes that was really low scam artist type behaviour. Still, on the bright side, the more profitable MS are, the more money for Bill and Melinda's good causes
This seems more in the realm of poorly managed expectations and less intentional and malicious copying. After reading his original blog post[0] I felt like they were originally interested in acquiring his software, but decided to go in a different direction with it and just weren't transparent about that decision at the time. It's not like they had to talk to him, the code is literally open sourced.
There's definitely things to gain from talking to the author of the project, but seems a bit reaching to suggest they wouldn't have been able to do what they did without talking to him. And it seems like a particularly pessimistic read to assume they were just lying to him outright to pull from his experience. Very little to gain from being a shark in this scenario, tons to (potentially) gain from acquiring an existing package manager. Gotta follow the incentives.
It's also worth mentioning that he mentioned the name similarity in his post in this way:
> When I showed it to my wife, the first thing she said was, “They Called it WinGet? are you serious!?” I didn’t even have to explain to her how the core mechanics, terminology, the manifest format and structure, even the package repository’s folder structure, are very inspired by AppGet.
He did not go on to mention that his own name was (nearly certainly) inspired by apt-get (stylized as AptGet on Ubuntu[1]). Implying he was the originator of the name [X]Get for a package manager seems aggressively dishonest, to the point that it throws his entire side of the argument into question for me.
I haven't looked thoroughly into the code, but this feels like someone who was expecting something to come out of his hard work and is (understandably) bummed it will now likely amount to nothing. I have trouble putting much blame on Microsoft for that.
I am curious: why would I want to use AppGet or WinGet instead of Chocolatey?
And is the assertion that Microsoft took code from AppGet as part of WinGet? The fact that the word "copied" is in quotes makes me wonder what the beef is... and did anyone ask the APT team if they feel ripped off by the existence of Windows package managers?
What secrets? The code is open source. They were probably planning to hire him as well, something just happened in the meantime before he started so it didn't work out.
It's a shitty situation for him, but that's just life. Sometimes it sucks.
"AppGet uses YAML files instead of scripts; we call them manifests. Using data over scripts just seemed like a much better choice."
So it's an opinion, one that the WinGet team decided to go with as well. Okay... not sure that's massively compelling just because the author says so but I'm willing to be convinced. I guess I need to go back and dig deeper on this scripting being referenced in Chocolatey: isn't it just powershell scripting?
In general it's easier to verify the security of the installation (not the code itself) if the package is configured via manifest instead of script. That's because you've preemptively restricted what the installation could possibly do, at the cost of flexibility. There are also some other specifics that are easier to implement via manifest than asking maintainers to implement via script, like supporting private app repository hosting (common enterprise feature). I suspect that's why WinGet went with AppGet's approach instead of Chocolatey.
Yeah and recently a lot of Chocolatey scripts are calls to a number of standard helpers for various types of installers. Not a whole lot of arbitrary commands being used.
Having something like YAML seems cleaner than the Chocolatey approach, but there are almost 8,000 Chocolatey packages and it works pretty well. Implementation > architecture here.
Yeah it's very dubious to me that YAML is the better approach, at least from the perspective of the average enterprise looking for Windows package management tooling.
There are still too many nasty installers out there, I'd be very worried about the ability to do what I need without a full scripting language at hand.
You can have an approach that is YAML with scripting where necessary. There are so many packages that fit into one of the standard Chocolatey package setups (exe, msi, msu, vsix, zip).
> And is the assertion that Microsoft took code from AppGet as part of WinGet? The fact that the word "copied" is in quotes makes me wonder what the beef is...
Agreed; reading the article makes it sound (to me) like they copied his "idea" rather than actual code.
> I am curious: why would I want to use AppGet or WinGet instead of Chocolatey?
Better names?
As someone who does not install a lot of things on my Windows systems, if I got a package manager named Chocolatey to install something I'd have trouble remembering the name the next time I want a package manager six months later. I'd remember that I already installed a package manager, but not what it is called.
AppGet I'd remember. I might look for it as app-get the second time, but would quickly remember it is spelled a little different than the Debian program. WinGet would be a little harder, but I think I would remember it.
Seriously, I'm getting a bit tired of programs whose names have nothing even remotely apparently related to with what the programs do.
While on a bit of a rant about names, what the heck is up with the naming of backup programs? There is Duplicacy, Duplicati, and Duplicity. Part of the reason I went with Arq was I kept getting those three confused with each other when reading reviews and comments.
Sure, you might not immediately think "backup" when you hear the name "Arq", but at least there is not also an "Ark", "Arque", and "Ourk" backup too.
"We will be open sourcing our service code into our our WinGet repository on GitHub so that we can work together with Keivan and others to enable a better WinGet repository listing service."
People who decide to "work together" should carefully read and understand the terms under which they're doing so:
Yes, "work together" means you work for free for Microsoft. Nothing more.
Because you sign your code over to them, they are free to CLOSE SOURCE future versions at ANY TIME.
Sure, you could attempt to fork, but the platform is proprietary and can lock you out (very likely in this case for "user security"). They are the biggest company in the world (by market cap) and those deep pockets mean they can outspend you until you go under or fall too far behind. It wouldn't be the first time.
Not sure if it applies here, but I've read before that is common practice for companies to never admit errors or apologizing because it could be used against them in court as if they were admitting some wrongdoing.
IANAL. I found an interesting article [1], "Legal Consequences of Apologizing", which says:
> Usually, apologies are admissible into evidence. Admissability into evidence does not necessarily mean useful as evidence of guilt. Since an apology usually can be admitted into evidence, and because some plaintiffs choose to understand an apology as an admission of guilt, it seems safest not to apologize. Case law suggests, however, that courts do not see it this way. Judges and juries seem to like apologies and treat them favorably. Often, an apology does nothing to satisfy the plaintiff's burden of proof. In some proceedings, an apology can be a mitigating factor, and the lack of an apology can be an aggravating factor.
and concludes:
> This article illustrates that judges and juries understand that expression of sympathy, regret, remorse and apology are not necessarily admissions of responsibility or liability. This serves the public interest because such expressions have the potential to reduce the number of lawsuits, rather than attract litigation. When someone goes to court armed only with an apology, they may find that it does nothing to satisfy the elements of the case they need to prove. Additional evidence is required, almost as if the apology did not exist.
That may or may not be true, but why excuse a corporation for what would be insulting, pathologically rude behavior in an individual?
Wealthy entities (including even moderately rich humans) can't admit error for legal reasons. That seems like a recipe for continued abuses, frankly. I'd like to see that changed.
It's unfortunate to hear all of this from Beige's perspective. But the optimist in me thinks this is probably just a big company focusing on a release and putting everything else on the back-burner. That doesn't make it right, but I want to think this isn't an example of how Microsoft wants to treat the community moving forward. I think AppGet, an officially supported package manager, should be a core feature. It needed to happen one way or another.
But the lack of UI to browse/search I think is too lacking so I put this up a few days ago: https://wingetit.com -- I imagine Microsoft is going to copy/replace this soon, but I won't mind.
Sounds like an apology. That's ok, I suppose. But I'd personally also love to see Microsoft pay Keivan for his contribution. It needn't be huge sums but something. No, not because it's the moral thing to do, but for the sake of Microsoft's GitHub and their open source community strategy itself. Keivan's project is exactly the type of projects Microsoft wants to encourage from their GitHub & open source endeavours for the eventual benefit of Microsoft. Paying Keivan something for his contribution to WinGet will really incentivise others to want to contribute to the ecosystem.
Although I'm sure you have good intentions, handing money to people after you make a mistake isn't always the best way to make amends (or to incentivize people).
Indeed. It's pretty funny when people pick their sides based on what companies are involved. They basically loosely implemented AppGet's API. AppGet, being permissively-licensed and open source, could've simply been forked or what-have-you anyways. There's nothing Keivan was actually holding back they had to interview him to get.
That being said, I think it's likely a loss for Microsoft: Keivan obviously had thoughts they considered of value, and he probably would've been a solid hire. The PR hit from this probably costs them more than a year's salary for an engineer, so they probably should've considered the risk here. The fact that Microsoft engaged in a "dick move" is obvious, and for what? Something that feels like a tack-on side project by a couple of Microsoft engineers, that'll probably never graduate to mainstream adoption?
Given that the person who wrote the apology has apologized for the apology not being upto the mark, I think we can say that the apology missed the mark.
So far I don't see @aclinick or @kayone addressing the later note. I see 15 thumbs up and 3 thumbs down plus a thumbs down from ZDnet. I happen agree with the 15 thumbs up that the blog post is a step in the right direction. It's not what is typically considered to be a non-apology.
It likely got no views because the title is worded in such a way as to avoid the actual topic at hand. Given how it's written, my gut is that it was titled to avoid being picked up, so I'm glad a news source caught wind and is calling them out with an appropriate title.
There message sounds like a clear apology, unless the poster is hoping to hear the actual words "I'm sorry". They screw uped and came clean, even though like in most cases takes trending on Hacker News to get that resolution.
I thought the message itself was okay and posted the article as it shows at least some action since the previous Hacker News discussion. I didn't want to edit the article's title though, beyond cutting the words "for Windows 10" to make it fit.
Economy of scale means freeloaders are too expensive a burden, preventing keeping up with closed source, for projects of unbounded complexity, like OS ecosystems. Sad but true.
Microsoft is publishing this as part of a UWP package, writing it in C++ means it could publish the libraries as a framework package allowing other applications to consume it as WinRT components regardless of their implementation language (C++, Rust, C#, JS, etc).
Whether this is planned or not I don’t know, but as they are putting this in the App Installer package right now which also has a public API I would not be surprised.
Based on what I read, I'm guessing Andrew initially thought Keivan was someone worth working with because of AppGet. But then something during the interview started rubbing Andrew the wrong way. Maybe it was the way Keivan talked or how he dressed. So he started ghosting Keivan and things got more awkward. Maybe this worked for Andrew in the office, but that's not how things work between a company and its community.
My assumption is a program manager can relatively easily write a letter thanking someone for their insight and work, but that a significant amount of paperwork is entailed in sending someone a big check. It really depends what level this issue has made it up to for Microsoft. Did Satya hear about this? If the answer's no, money probably is hard to just disburse.
License is Apache 2.0 which does not require acknowledgment. I’m always surprised when open source project creators are complaining about a legal move made by a company related to their project: they allowed it in the first place. If they wanted more, like citation or financial advantage, they had the choice to force interested parties to comply by choosing another license. Betting on companies goodwill is risky...
There's a matter of politeness/good practice that goes beyond license terms. And in some contexts (e.g. academia) there's absolutely an expectation that you cite others' work whether or not you're legally required to do so.
That said, I basically agree with you. If you have specific expectations of whoever uses your code, you should absolutely pick a license that requires the behaviors you want. (With the understanding that fewer people may use your code as a result.)
Of course there are implicit expectations and etiquette. What I’m saying is that corporations are less likely than individuals to follow them so if one doesn’t want to be screwed they have the opportunity to do it with the license.
You speak of academic code, and precisely some projects require (or at least ask for) citations in their license file if use in a research context.
> c. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
In the case of WinGet attribution was theoretically not required because the code was not copied directly, so a copyright license was not needed and the Apache License did not come into play. (Of course if AppGet's creator had Microsoft-level lawyering available, he could quite possibly persuade a court that copyright infringement did occur.)
But the Apache License 2.0 absolutely does require acknowledgment!
Is it really being a dick when someone explicitly, through choice of a license, allows it? What is this post from Microsoft except an explicit and public thank you? Which seems like it should certainly appease the "not a dick" criteria to me...
If that's all they did it wouldn't be so bad. However, they also discussed the project, future improvements, etc with the strong implication that they would hire him or pay for his work so far. This could have been well intentioned but you can't tell from the outside and people tend to default to assuming bad things about actions taken by large companies.
I am going to go against other answers and say that legally OR morally you don't need to acknowledge the author if you don't want to. But that wasn't the issue here at all, the issue was Microsoft interviewing the candidate (to pick up his brain?), then ghosting him, THEN copying his solution. It's about how they treated the original author, not about just copying the solution.
Actually I agree that Microsoft move wasn’t fair to the author. The thing is, we read more and more posts here about people disappointed by open-source, with project they started and put lot of effort into and then didn’t get anything back when a company serves itself. But that what they allowed to happen in the first place. If I were to open source the main project I’m working on, I would think for a while to the kind of licensing (possibly dual) that would allow me to reap some benefits in case of success, by the project itself or its use by a company.
Sure, agreed. The problem with dual licensing is that it does limit the project's potential, so unless it's a truly groundbreaking project (vs an iterative improvement) the adoption would be trickier IMHO.
The "Andrew" in question who courted Keivan (AppGet's dev) is Andrew Clinick. He wrote a blog post in response to this a few days ago:
https://devblogs.microsoft.com/commandline/winget-install-le...
Still seems pretty tone-deaf to me - obviously MS seems to be in the legal clear, but the moral high ground and lots of dev goodwill has been lost.
It also damages the ability for devs to informally meet and chat with PMs at larger companies everywhere - adds a lot of mistrust to the eco-system.
This is not that MS came up with their own package manager. It's the entire song-and-dance routine that was conducted about potentially hiring Keivan, and then ghosting the engineer whose open-source product you were simultaneously cloning.
Of course, people will forget, but many will still remember. This is still a net-negative all-around when it didn't need to be.
Edit, this ZDNet article adds no new information and nothing has changed since the other articles have come out, but I guess it's good that more places are covering it to signal boost this properly.
[0]https://news.ycombinator.com/item?id=23375624