A controversy involving K-skill and Blue Ribbon Survey has been growing in South Korea’s developer community.
K-skill is an open-source project that connects AI agents to a range of services commonly used in South Korea. It has attracted considerable attention, earning more than 6,000 stars on GitHub. The trouble began when critics pointed out that a Blue Ribbon restaurant search feature included in the project was redistributing paid data and had attempted to bypass the service’s restrictions on automated access.
The developer later stopped operating the feature and removed it from the repository. They also said they would work with legal counsel to explain their position in the ongoing legal proceedings.
No court ruling or official statement from Blue Ribbon has been made public yet. At this stage, it would therefore be wrong to conclude that copyright infringement or an act of unfair competition has been established. Even so, the development history preserved in the public repository is enough to understand why the case shocked so many people.
The MIT License Is Not Permission to Use Another Company’s Data
The main K-skill repository is licensed under the MIT License, while parts of its proxy server are covered by the AGPL. The first thing to understand is what those licenses do and do not cover.
They define the terms for copying, modifying, and distributing the code written for K-skill. They do not grant rights to use Blue Ribbon’s data, paid membership accounts, server APIs, or brand.
Applying the MIT License to a project does not make every external dataset that the project accesses open source. Nor does the fact that something is visible in a web browser mean it may be freely collected and redistributed.
We often confuse four different things:
- Information that is publicly accessible
- Information distributed as open data
- Code covered by an open-source license
- Information whose automated collection and redistribution are permitted
These are entirely different concepts.
When building software that connects to an external service, developers need to review more than the code license. They must separately examine the service’s terms of use, official API policy, database rights, trademark use, privacy requirements, and restrictions on automated access.
What Turned the Issue into a Major Controversy
Earlier code in the K-skill repository stored the session ID of a Blue Ribbon premium account in a proxy server environment variable and used it to retrieve nearby restaurant data. Blue Ribbon’s own documentation described the nearby restaurant feature as premium content.
What happened after access was blocked caused even greater concern.
When Blue Ribbon’s server began returning 403 responses to automated requests, the project added features designed to conceal signs of automation and make the client appear to be an ordinary browser. The relevant PR description explicitly listed methods for evading bot detection, including removing navigator.webdriver, disguising browser information, and changing browser fingerprints.
Reading a public webpage is one thing. Recognizing that a service operator has blocked automated access and then technically circumventing that block is something else entirely.
Any legal judgment would need to consider the specific terms of use, the nature of the data, the scope and frequency of collection, and whether the data was used commercially. From a development ethics perspective, however, a 403 response or an account suspension should not be treated as just another technical obstacle. It may be a clear signal that the service operator does not want automated access.
Why the Community Was Divided
The reactions I saw in the community broadly fell into three groups.
The first was strongly critical. Sharing the session of a paid account through a proxy to access premium data, then merging a bypass after the service blocked access, was difficult to excuse as a well-intentioned open-source experiment. Many also argued that the project had confused publicly available code with permission to use external data.
The second group worried about excessive attacks on the individual developer. They suggested that a project begun as a personal experiment may have grown faster than expected before adequate operating standards were in place. Instead of public ridicule or personal harassment, they argued, the developer should be given an opportunity to correct the problems.
The third group argued that this should not be treated as one developer’s mistake. Similar problems will keep emerging as AI agents begin accessing and acting on real services, so projects need formal procedures for reviewing data provenance and usage rights.
I am closest to the third view. More important than blaming one person is understanding how a feature like this could be built, published, and widely adopted without meaningful checks along the way.
The Accountability Gap Widened by Vibe Coding
This case looks like one consequence of careless vibe coding.
AI can quickly uncover a website’s hidden request patterns, generate code that calls unofficial APIs, and connect proxy servers with browser automation. A feature that once would have taken days can now be completed in a matter of hours.
The problem is that implementation has accelerated, while review has not.
AI can readily answer, “Can this code be built?” It does not decide on our behalf whether we have the right to use the data, whether we should keep accessing a service after it blocks us, or who will be accountable when a feature is distributed to thousands of people.
Vibe coding itself is not the problem. The same thing could happen even if a person wrote every line of code by hand. But AI dramatically expands the range of features and services that a single developer can handle. That also means a bad decision can become a product and spread to many users much faster.
As the cost of generating code falls, the investment in review and accountability should rise.
How Projects and Companies May Respond
K-skill has already begun reviewing the data sources, access methods, terms of use, and trademark usage of many features in the repository. The creation of more than 60 legal review issues suggests that the project itself recognizes the problem may extend beyond the Blue Ribbon feature.
Open-source AI agent projects are likely to need standards such as these:
- Document each feature’s data source and whether an official API is available.
- Do not reuse paid accounts or sessions through a shared proxy.
- If there is no official API, confirm whether automated collection is permitted before proceeding.
- Do not treat 401 or 403 responses, CAPTCHAs, or device blocks as obstacles to bypass.
- Record reviews of terms of use and data rights, not only software licenses.
- Provide a per-feature shutdown mechanism so problematic functionality can be disabled immediately.
- When using an external service’s name or logo, avoid implying an official partnership.
Companies are also likely to strengthen their defenses. We may see more rate limits and bot blocking for automated requests, more restrictions tied to accounts and devices, and more frequent changes to unofficial APIs. Many companies may also add clearer provisions on AI agents, crawling, and data resale to their terms of use.
Blocking every form of automation, however, is not necessarily the best answer. If AI agents become a new kind of user interface, companies should also consider offering limited official APIs and partnership programs. Contracts can define the permitted uses of data, request volumes, display requirements, and revenue sharing.
Open-Source Freedom Does Not Erase Other People’s Rights
Open source is a commitment to share code freely and improve it together. It is not a declaration that data another company spent time and money creating is free for anyone to use.
The lesson from this case is neither the simplistic conclusion that all crawling is illegal nor the optimistic assumption that anything available on the internet is fair game.
In an age when AI can write code for us, the developer’s role does not diminish. If anything, the responsibility to decide what to build, how far to connect it, and when to stop becomes greater.
I hope this controversy does not end as another episode in which one developer is attacked and then forgotten. It should be an opportunity for South Korea’s open-source and AI development communities to look beyond code licenses and review data provenance and service permissions as well.
