As a leader of a FOSS project that is on github, and migrated off of sourceforge because SVN and email patches were not scaling - I'm a bit confused by this article.
Co-pilot has issues, ergo github is going the way of sourceforge, and so now we must abandon github? Do I have that reasoning correct?
We need to:
- migrate the bug queue
- have all links in commit history break
- application integration with githib for bug reporting be removed
- update documentation
- find a new website host (and no longer github.io)
- find a new CI/CD (we were already burned by travis, github workflows are nice)
- teach our user contributors to actually use git! There has been a lot of heartache from them that they have to use the pencil icon on a web ui to edit config files, now we have to take them back to using a git GUI client! We were on github before that blessed pencil icon feature came out, there was no end to the wailing about how unapproachable the process was (super frustrating when users see they have to do something.. frustrating for us because our users wanted to just email is stuff so we could then do the uploading to git work)
- lose all PR history
- migrate project tracking
- find a new place to host release artifacts
- update our website to use a new distribution URL (the website scrapes github api to get latest version for download link; it's nice never updating website as we do releases on every merge)
- figure out and migrate repository permissions. (We have a hundred repositories of user generated plugin content, everything about migrating that would be a lot of work and missing important features)
- lose our search ranking and rebuild our SEO
What else to add to this pile.. and all because co-pilot smells?? Meanwhile all of that work is busy work, and not at all feature-pare. That kind of migration would take a long time, seems like that pivot without good reason is the worst kind of churn. Convince me this article is not a temper tantrum about copilot...
That list is a perfect example why GitHub is so problematic.
Forget Copilot. Even without that you’ve put all of those services in one centralized basket, fully controlled by a for-profit company (with proven track record of unethical behavior).
And not only that, but this is true for the vast majority of FOSS projects!
I see your point. The disagreement I have is I would not at all consider copilot as putting MSFT into the evil empire category yet. While it was very unnerving for the ownership to change, MSFT has really had a pretty hands-off approach on Github.
I touched on it, but I still see this for-profit model as being compatible with FOSS. Specifically, make it free to FOSS so that those professional software developers then move to adopt the same platform at their private companies. There are lots of examples of for-profit companies that provide free-to-foss platforms.
For example, just considering code scanners, Codacy, CodeClimate, Snyk, LGTM, all used by this project and all have the same for-profit model (but free to FOSS). We also use 'install4j', which has the same free-for-foss model and is a for-profit company.
I think the heart of it is the argument that MSFT is going to expand that for-profit model and leverage data in a way that violates FOSS licenses? Is copilot an example of that? Should this all be taken to the extreme and declare that MSFT is the evil empire for this and by extension so is Github?
> MSFT has really had a pretty hands-off approach on Github
(a) since it is proprietary, you can't see where their hands are
(b) the fact that they haven't done anything also means you have no signal of their intent once they do. Not doing anything would be the logical play for a period of time whether you had evil intent or not.
> I would not at all consider copilot as putting MSFT into the evil empire category yet
The question is not whether Microsoft should be put into the evil empire category, but if they really left it or are just pretending like they did every time before.
> As a leader of a FOSS project that is on github...Do I have that reasoning correct?
The way I read the article was that by being on GitHub, you are implicitly agreeing to no longer be a FOSS project as regards licensing. GitHub customers can use Copilot to generate proprietary code that's identical to your project's code (several articles I have read call this overall idea "laundering through Copilot", which sounds incendiary but accurate to me) without needing to respect your license.
The other stuff you said is...kind of irrelevant. Sure, you get a lot of convenience from GitHub. If you don't care about software freedoms in the libre/copyleft sense and regard a "do whatever you want" license as the best, then it's probably fine to keep using GitHub.
Is copilot really a violation of GPLv3 (our license)? How is co-pilot different from someone lifting sections of code? Lifting a few sections of the code is a world different compared to re-distributing the entirety of the source code, or forking the project and replacing 2 or 3 letters from our brand name & then redistributing that.
I think the article needed to go into more detail about how that really is a violation of a license. This seems like a similar argument that was made in court whether the Java APIs themselves could be copyrighted. Can an algorithm be copyrighted or licensed? If someone uses the same algorithm as found on FOSS, have they violated the license of that FOSS?
Then the reaction, instead of pursing litigation, and/or communicating and working with github, the reaction is we should 'cancel' github and move to.. gitlab? Is that even an answer? If we think algorithms are copyright-able, wouldn't have any kind of code search be a violation? Would allowing for any kind of transcription of code be a violation? If so, then seemingly having the source be open would invite this.
I think this gets to the heart of FOSS in some ways. It's closed for privatization, open to the community, and what matters is the software provided. If someone cribs the project to configure a Feign client, or set up a unit tests with DbRider - it's okay! It's the same thing as viewing HTML source code, learning a cool javascript trick by looking at how some website did that trick - is part of the openness.
I wonder then, is the point of FOSS openness only to allow others strictly to view and edit the code for the purpose of contributing back to that exact software product? Or is the openness more than that, and that others are going to use the software in creative and novel ways, and use it for learning and who-knows how else (all pursuant to GPLv3).
> Is copilot really a violation of GPLv3 (our license)? How is co-pilot different from someone lifting sections of code?
If it's reproducing vebratim your code, yes it's a violation. And this is no different from others copying sections of your code.
The license that you chose says that people are allowed to do many things (e.g. copy and modify the code), provided they also fulfil some obligations. If they don't do that, they are violating the license.
Please note that this is not specific to GPLv3 (your chosen license). Other licenses, BSD-3-Clause, for example, also give rights (e.g. to copy and modify) and have their own set of obligations to be fulfilled (e.g. "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer"). If someone redistributes source code (not the "complete" source code, even a "section of code" to use your words), they have to fulfill the obligations, or they violate the license.
It sounds like Github needs to index the license of where it obtained code, and check the license of a project using co-pilot so that it only suggests GPLv3 code for compatible projects. I'm not sure that it is really enough, enforcement is tough, it could be like one of those "are you 18" checkboxes.
I get the impression that this article and it's reaction is largely a lot of people wanting to cry big brother and mostly just shit on Github & Git. IMO it would be more appropriate to look for solutions and post a public letter to github and/or just pursue actual litigation before advocating FOSS projects spend inordinate amount of effort across the board to vacate Github.
I think the article starts from the position "everyone should respect the software license" and obviously promoting the SFC views.
You are correct that the problem is hard, because adding licensing info to training data and subsequently use it is something not yet accomplished by anyone (who at least has spoken publicly about it). It might be the only way out would be to have different training sets according to license, but then you lose the advantage of scale.
On the other hand, I believe it's a little much to ask SFC to do the cutting-edge research and propose solutions to Microsoft. Let's not forget that, when faced with the problem, their chosen path was "completely disregard licenses (for now), ask legal later". Many legal opinions are that there would not be any issue if copies of the input code were not reproduced verbatim; unfortunately this is not the case.
Microsoft could afford to train several models for every significant class of licenses. So if you don't want the model which included e.g. GPL code in its training set, you would opt for the model that was trained on the dataset which didn't include any. It's a bit of a hassle for MS, but that would partially resolve this issue.
> Is copilot really a violation of GPLv3 (our license)? How is co-pilot different from someone lifting sections of code? Lifting a few sections of the code is a world different compared to re-distributing the entirety of the source code, or forking the project and replacing 2 or 3 letters from our brand name & then redistributing that.
Yes. Many projects will see your license and never copy your code if their licenses is incompatible with yours. Copilot disregards your license and offers your code or derivations of it to anyone who asks the correct questions, breaching your license both in ethical and legal level.
You can't lift a function from a GPL licensed codebase and plant it to a MIT licensed codebase. It's that simple.
I appreciate the response. The ethical level, in my opinion, is reproducing the functioning software and the "business" specific logic. At a specific function level, and particularly for boilerplate code, I don't view that as specific to this (GPLv3 licensed FOSS) project. There are also dozens more examples of the same code being used, I don't think FOSS necessary gets a monopoly on technology.
Which I think creates an interesting debate, where is the line of general technology vs the intent of not allowing private companies to re-package FOSS for their own benefit?
> You can't lift a function from a GPL licensed codebase and plant it to a MIT licensed codebase. It's that simple.
If that function is a 'pad-left' type of function, is there an ethical violation? Or is this similar to learning Javascript by viewing the source code of webpages? At some point, functions are hardly unique in what they do, and there are only so many different ways to write a 'pad-left' function. I mention this question not to refute what you've said (I think I agree there is a likely license violation), but to explore where the line is for the ethics. I mean, an inferred implication could be that software developers stop looking at HTML source in order to learn. If you learn how to write a standard algorithm or function, and then you reproduce that later in private software, that is "lifting code". It's not much different committing that to memory then doing an outright copy-paste of a 2 or 3 liner. This makes me also think to the variety of shell scripts and standard bash'isms, if a single FOSS project uses a 'sort | uniq -c | sort -n', does that mean a MIT codebase has to re-invent a new way to do that?
You're welcome. First of all thanks for your kind and welcoming response.
It's an interesting debate for sure. When a program is divided into many functions, and when there are many utility functions, the debate indeed gets blurry. Moreover, many of the open projects in today's world are web applications and "simple" in nature.
In this context, simple means that the application can be composed via many simple, relatively general functions with a unique asset set and unique way of connecting them, so the magic (or sauce if you pardon the term) gets more abstract.
On the other hand, we have another group of programs, which can be similarly called "complex" programs. The biggest difference is these programs use complex, one of a kind functions.
Consider Blender, KiCAD, many open source and GPL licensed scientific software, libraries like Eigen, video/audio encoders, CD/DVD tools. Even a three liner in these programs and libraries can be a game changer.
I have a research oriented code, and a ~25 line function in this is worthy of its paper. I published a paper, and didn't obfuscate the language and algorithm, so you can implement it if you want.
However, if I open the code of this algorithm with AGPL3, can you say it's too small to be licensed? I don't think so. A more general algorithm can be ruled out as "too simple", but "fast_inverse_square_root" or my function or any other math heavy secret sauce can't be excluded because it's 2-3 lines.
As a result, while this issue needs serious discussion, we need to understand that even a small piece of code can carry a lot of research, knowledge and advantage in itself, regardless of its size.
So, while lifting a left pad from a GPL code can be understandable up to a certain point, getting the secret sauce, improving it and keeping it closed or merging into a similar, but incompatibly licensed software is inexcusable.
At the end of the day, this means we need to defend our GPL codebases, because we can't protect our secret sauce functions without defending the simpler ones.
If source its not subjet to corpyright then independently of it being illegaly leaked, i could unbrand XP's source code (that as I recall was leaked no long back) use it and redistribute it even for profit... I would like to see M$ answer to that.
I think the issue with Java's API was actually terribly explained even by Oracle's lawyers, Google stole that API, first because it already had a large amount of developers familiar with it so they could benefit of cheap code monkeys developing for their platform, added modifications (memory management) which under Java's open source licence (Oracle owns java yet it is still open source) they should have made public for everyone's benefit (in a true Open Source spirit), modified the packaging mechanism (slightly, you know .apk), so instead of you know having a package (jar) that can run on a desktop or rather on any JVM it could only run on the devices with their* OS (or rather dalvik implementation) and guess what, now that there are some options to run those on other environments the "casually" decided to change it again instead of letting people benefit from the rich APK ecosystem somewhere else than Android
> I think the issue with Java's API was actually terribly explained even by Oracle's lawyers…
Of which none of your examples are in any way applicable to the case of google violating the Java copyright.
The Java Specification gives terms and conditions for usage which is what the lawsuit was about and not some laundry list of things which annoys a random internet person. In fact, not annoying your users isn’t even mentioned once in the conditions to call an implementation “Java” strangely enough.
Or I’m completely wrong and oracle doesn’t spend enough on their legal team.
> The way I read the article was that by being on GitHub, you are implicitly agreeing to no longer be a FOSS project as regards licensing.
In this case, they have violated our license. The license states how it cannot be changed, and implicit changes by the hosting company is not one of them. Isn't there a legal case here? If no, then the license is not violated. This makes me wonder why not take Github to court vs a tamper tantrum (we're taking our marbles and going home!)
> the other stuff you said is...kind of irrelevant.
It goes to show that Github is providing really, an excellent service to FOSS. We could migrate to GitLab, though, why?
I know that sounds like 'fan-boy', but the list is large, useful, and all highly available and free to FOSS. By those measure, it's a good service.
> Sure, you get a lot of convenience from GitHub.
The items are more than convenience, they are core to our application and project. Uprooting them is not a small task.
The automatic integration with issues is excellent for example, before we did that - we had no idea how many users were seeing errors. We run a thick client that is downloaded and added an integration to upload error reports to github issues. That has been pretty invaluable. So, we have to move all that, to another host: who is to say that other host will always be a better FOSS steward? who is to say that other host has anyone near the level of features? An integrated CI/CD and hosting of release artifacts is huge.
So, on the premise that our license has been violated, instead of sue'ing, we should take our FOSS somewhere else? Again, the list is large, we need to migrate all of that. It took a long time to get out of sourceforge, it's not even more work to get out of github because we automated so much (to allow our team to scale better). It's not just a matter of 'convenience' to go somewhere that is feature-sub-par and spend the better part of a year to do that and nothing else.
> This makes me wonder why not take Github to court vs a tamper tantrum (we're taking our marbles and going home!)
Mainly because it might be more in line with traditional FOSS ideals to take our marbles and go home? It's hardly a temper tantrum. After the Linux kernel got into one too many arguments with Bitkeeper, there was an inflection point where Torvalds got fed up and just wrote git instead. I think this is an inflection point like that. And "taking Github to court" is much easier said than done for a FOSS project, although I assume that someone will be doing that at some point.
> So, we have to move all that, to another host: who is to say that other host will always be a better FOSS steward? who is to say that other host has anyone near the level of features? An integrated CI/CD and hosting of release artifacts is huge.
In addition to GitLab, I think Sourcehut offers similar features and is also FOSS (AGPLv3).
> So, on the premise that our license has been violated, instead of sue'ing, we should take our FOSS somewhere else? Again, the list is large, we need to migrate all of that.
I don't think anyone is telling you what to do, just offering suggestions. My suggestion is that switching to a forge that respects FOSS is a reasonable alternative to legal action against GitHub or just ignoring the potential license violations via Copilot. You can of course choose any of the alternatives, or the status quo; which is what you seem to have largely convinced yourself is fine. Good luck, and thanks for working on FOSS anyway!
> generate proprietary code that's identical to your project's code (several articles I have read call this overall idea "laundering through Copilot", which sounds incendiary but accurate to me)
Can you point me to those articles? I have seen the Quake thing, but "your project's code" is not like that one function in Quake (namely, it's not duplicated hundreds to thousands of times through countless license violations already).
Anyone can already generate proprietary code that is identical to your GitHub project's code just using copy and paste.
For people that care to respect copyright, there's a copilot setting to block exact copies of code in the training set (which only happens a tiny percentage of the time, unless you're actually trying to make it happen).
For people that don't care to respect copyright, git clone is a way more efficient way to violate your license.
Forget Copilot for a second. Do you think it is healthy for the industry to be so dependent on one single service provider, and a closed one on top of that?
There is gitlab, a decent alternative. Bitbucket is a (poor) option too. I think I would quibble with that dependency statement. Github is providing a lot of services, high availability, project tracking, a web api, etc...
The money model, as is for many free to FOSS tools is that by getting devs tooo use those tools, they'll carry forward to their professional lives and recommend the adoption by their companies. That does happen in practice, so it seems like the money model will not necessarily flip like it did for sourceforge (which kinda was garbage and the only game in town)
I would disagree about the industry dependency compared to FOSS. Many companies are not on github
So, that is to say the dependency aspect is a concern. So far Microsoft has overall been a steward for FOSS and copilot is not at all nearly enough to lose that trust. It is always a bit nerve wracking to place your balls in someone else's hands... and it was concerning when MSFT bought github.. but they have not been evil, not even close yet (in the grand picture)
You say BitBucket and Gitlab are alternatives, but at the same time you can not fathom the idea of migrating away from GitHub. So it's safe to say that GitHub has a de facto control of the market, much like Windows controlled the desktop market until early 2000's.
I can fathom a migration. It's just not pretty & is expensive. The experience coming out of source forge was not pleasant, and that was before the project even had a CI/CD. The early days of Github were game changers for FOSS, no more consolidating email patches together, etc.. So, this goes to whether Github still has a reputation and a brand for being a good home to FOSS. The argument that copilot, which automates what is otherwise an available and a manual process, and lifts just lines of code and small sections - is not at all "reproducing software". It's like someone used the "pad left" functionality from someones Javascript on their web page. Being able to do that is part of the point, it is a feature of openness, it's not a corporate back-door, market monopoly enabling flaw.
I'm curious if anyone can find references, though when I researched market share of code hosting companies a few years ago (for a private company that was moving off of BitBucket), it turned out that there were more private companies on Gitlab than Github. Github though had a big advantage for hosting FOSS. We wound up moving to Microsoft Azure because the scrum boards and Microsoft integration were appealing and familiar to the company. I don't see it being analagous as Windows desktop control in the early 2000's.
As an alternative to github... one of these is not like the others.
In any case... why github? What is so unique about it that you can't even consider other possibilities? I guess soon people will be non-ironically saying "no one ever got fired for hosting their code at Github" and turn a blind eye to perfectly usable, open alternatives who does not lock us in.
For what? Fear of taking responsibility for maintaining the basic tools for their job? If that is the case, you can always pay for other smaller, independent companies who can host at competitive rates.
Anyway, you do you. I'm tired of playing Cassandra, and I'm tired of seeing people giving in to convenience and general conformity.
I think it's like any social network. It grows in value with how many people use it. Yes, you can host your own public git repo or even your own gitlab, but then there's a barrier of entry to contribute to your code, and it's a lot harder for others to discover it.
The network grows in value with the size of the protocol, not just with a platform. Social networks can and should operate like email, not like siloed platforms. All the value ends up being captured and controlled by one single entity.
(I will not get in a tangent about web3, but that is the one thing that web3 skeptics always fail to acknowledge is how the current web is broken in that regard. We were promised open protocols, and we end up with a handful of companies building their own walled gardens)
The only way that Github would get any modicum of credibility would be if they joined the effort from codeberg/forgefed and integrated with activitypub. As it is now, github will be nothing but a mirror for my repositories that I will be hosting on gitlab and/or my own gitea.
Familiarity with the UX and conventions on that platform. Almost everyone knows how to make a PR against a GitHub repo. But some random other code hosting site? It would be a lot less familiar, and people would have to spend time making an account and figuring out how to contribute.
Even low barriers of entry can cause a big drop in user engagement.
If GitHub didn't provide value, then it wouldn't be where it's at. Considering that collaborating on FOSS before GitHub was a mess if you weren't technical, I'd say GH has earned their spot.
Also, there's no way to avoid centralization. At some point somewhere, you're relying a mega-corp for critical services, and if not you, someone else.
There's no getting away from it. Unless you're RMS, you're dependent on Microsoft or Apple. Just like your phones are dependent on Google or Apple. Is it a good thing? Nope, but it's real convenient and so most people will compromise.
> Unless you're RMS, you're dependent on Microsoft or Apple
No. Stopping believing this shit. It has never been easier to not depend on any of them.
There are good, perfectly usable phones with de-googled Android. You can buy laptops and desktops that run Linux without issues out of the box for years. You can even game on Linux today better than you can on an Apple box. You have legions of people working on different open source projects that make hosting your own server a matter of point-and-clicking.
It's not an Sisyphean job to keep yourself away from bad tech products. It takes some discipline, but so does anything worth doing.
And if you really just want to pay to get rid of any "headache", why not then pay for an open source alternative so you can be safe knowing you won't get locked in?
> Co-pilot has issues, ergo github is going the way of sourceforge, and so now we must abandon github? Do I have that reasoning correct?
No, you don't. If you had actually read the whole article[1], you would have noticed that they also listed several other issues which far predate Copilot.
___
[1]: You need to correct this part of the guidelines, dang. Some times -- like here -- the injunction against saying this is just fucking wrong.
TL;DR: The rest of the article is vacuous, the list of other reasons is a link of bothersome but not compelling other reasons. In sum, it's not a compelling argument to give up github. I disagree that the correct course of action based on the arguments presented would be to boycott Github rather than take any of course of action that would lobby them to change.
If this is just fucking wrong, I wonder about the implication. Would you say, I am just fucking right? I would be careful whenever having any such conviction. If I were already a hater of github, this article would have resonated with me a lot more. Perhaps there is some kool-aid drinking happening here? Maybe not and everything is totally reason to abandon Github as a hosting platform.
> you would have noticed that they also listed several other issues which far predate Copilot.
I don't quite see that list. I do see this article as quite focused on co-pilot. Though, I do see this:
> There are so many good reasons to give up on GitHub, and we list the major ones on our Give Up On GitHub site. We were already considering this action ourselves for some time, but last week's event showed that this action is overdue.
Which links to this https://sfconservancy.org/GiveUpGitHub/ (I'll point out here, linking to a list is different from listing the other points, so.. 'fucking right?')
Re-capping that list from sfconservancy:
(1) co-pilot
(2) contracts with ice
(3) githubs hosting code itself is not FOSS
(4) no self-hosting with github code options (again, github hosting is itself not FOSS)
(5) work to discredit copyleft
(6) wholly owned by MSFT
In this article, it essentially says that co-pilot was the last straw, and a decisively large one at that. So my response is still, this is the last straw where we need to abandon github?
If you are fully vested in the other reasons, then I think that this article would be preaching to the choir.
For me, points 1-6 are bothersome, but still just 2s and 4s on the 1-10 scale of fire alarms. My personal take on this list:
(1) co-pilot: seems problematic, perhaps github can fix it. Maybe a better solution is to lobby github first before doing a cancel campaign
(2) ice contracts: this is bothersome; but I can see how it could be a bit complicated given ownership by MSFT and the complexity of government contracts. It is bothersome though.
(3) closed source: I don't put a lot of weight to this criticism. Just because I can't run Githubs code for myself.. I mostly shrug. Yes, I'd prefer for it to be open source too, but I respect there are various for-profit models out there (and holy-hell I wish I was payed market-rate for FOSS work).
(4) no self-hosting option: Seems like the same point as (3)
(5) CEO leadership discrediting copyleft: bothersome, but without concrete examples, for me it is not fully substantive and just bothersome (but not major, like, wow, they are shutting down FOSS projects, or aiding in getting them taken down by ginning up BS charges, etc..). So, yes, the CEOs of Github were at times discouraging to copyleft. Are they evil incarnate here where those bad actors needs to spurn everything Github? Did the CEOs of Github personally oversee any FOSS projects being sued, or made into non-FOSS? Did they personally increase the cost on FOSS?
(6) owned by MSFT: big companies are big companies and they are really hard to avoid completely... MSFT has had a big culture shift in the last 5, 10 and 15 years. It's not the same company it once was. That is not to say this is not a concern. Though, until I have specifics around how/why I thnk MSFT has become actively evil, this remains just a notable concern.
> If you had actually read the whole article[1]
Apologies for seeming like I only commented on the first paragraph. A lot of the article seems vacuous to me and generally trying to gin up a mountain out of what might just be a gnarly hill.
Git is confusing for just about everyone. It is really easy to shoot yourself in the foot once you step away from git add/git commit/git push. Hell, you can foot-gun yourself even with the usual workflow.
GUIs help with bridging the gap, but because the GUIs make everything that's actually happening opaque, troubleshooting gets really complicated when something goes wrong (GitHub also sells professional services).
Github and Gitlab have done a lot to make Git easier.
>What else to add to this pile.. and all because co-pilot smells??
You are absolutely right that this all is a huge pain in the ass. GitHub, and later Microsoft, played their cards well. The product both works well, and also creates such a moat of vendor lock-in that it won't make sense to leave.
Co-pilot has issues, ergo github is going the way of sourceforge, and so now we must abandon github? Do I have that reasoning correct?
We need to:
- migrate the bug queue
- have all links in commit history break
- application integration with githib for bug reporting be removed
- update documentation
- find a new website host (and no longer github.io)
- find a new CI/CD (we were already burned by travis, github workflows are nice)
- teach our user contributors to actually use git! There has been a lot of heartache from them that they have to use the pencil icon on a web ui to edit config files, now we have to take them back to using a git GUI client! We were on github before that blessed pencil icon feature came out, there was no end to the wailing about how unapproachable the process was (super frustrating when users see they have to do something.. frustrating for us because our users wanted to just email is stuff so we could then do the uploading to git work)
- lose all PR history
- migrate project tracking
- find a new place to host release artifacts
- update our website to use a new distribution URL (the website scrapes github api to get latest version for download link; it's nice never updating website as we do releases on every merge)
- figure out and migrate repository permissions. (We have a hundred repositories of user generated plugin content, everything about migrating that would be a lot of work and missing important features)
- lose our search ranking and rebuild our SEO
What else to add to this pile.. and all because co-pilot smells?? Meanwhile all of that work is busy work, and not at all feature-pare. That kind of migration would take a long time, seems like that pivot without good reason is the worst kind of churn. Convince me this article is not a temper tantrum about copilot...