Concerns around a paid plugin author uploading opensource plugins

JetBrains Marketplace
1

Got a bit of an honestly “yeah this kills the little joy I had left” situation - our opensource plugin intellij-elixir has been forked, and has been submitted to the Jetbrains marketplace as a paid plugin, without attribution.

Ours: https://plugins.jetbrains.com/plugin/7522-elixir
https://plugins.jetbrains.com/plugin/32247-elixir-pro
Even boasting here: Reddit (he did none of this).

We’re Apache 2.0 licensed, I honestly am more bummed /unimpressed that the code is being used for profit more than anything - it doesn’t violate the license (nor should it, that’s the point of the Apache 2.0 license!), it’s just tiring.

The plugin authors business name is also Jetplugins, which is pushing it a bit.

It’s incredibly lazy, it doesn’t even rename their distribution. :face_with_bags_under_eyes:

So I got curious, and decided to dig.

Out of the 20 paid plugins, I took a look at a couple, and I found https://plugins.jetbrains.com/plugin/32553-solidity-pro is a fork of https://plugins.jetbrains.com/plugin/9475-solidity , which is MIT licensed. No attribution either in this, which is actually a violation of the MIT license.

I haven’t bothered looking through the other twenty plugins, but I’m willing to bet they follow a similar pattern.

Jetbrains - whats the stance on this, is this acceptable?

This sort of shit kills the opensource ecosystem, with “developers” just essentially reuploading plugins :face_with_diagonal_mouth:.

No attribution, just money going in their pockets.

3

although the license prohibits reverse engineering there’s a few signs that it’s heavily vibe-coded and barely tested (judging by 100’s of commits in author’s private repo and bugs, e.g. Rename of function output shows dialog with prefilled identifier NameArityInterval(name=outcome, arityInterval=ArityInterval(1, 1)) and then not working anyway even if correct identifier typed / won’t rename usages, which is a bit deceptive for a marketed feature)

4

There was additional followup at Absolute file paths in <orderEntry /> for libraries for no apparent reason · Issue #1 · Jetplugins/elixir-pro · GitHub where the author seems to have no idea how licenses work (just remove them) and not understanding how weird and awkward it is to do this in the first place.

5

Good catch.
What bothers me the most is that the author seems to have turned copying open-source projects into a business model to make money off them. Once or twice would have been okay, but he’s going too far.
I’m going to change the license for my open-source projects from MIT to, I think, AGPL-3.0 right away.

6

We’re witnessing the death of permissive good faith open source when people like this show up…

It just seems.. Like this is something where JetBrains could and absolutely should take some action?

Also - you’re saying the plugin was taken without renaming the distribution? I swear I saw a JB response in some thread somewhere on here that there is intent to implement logic to disallow releases where classpaths for example are identical - basically, my interpretation and is that what you’re pointing out might be genuinely persecuted by JetBrains.

Actually clicking through to the author you can see the beautifully claude-coded webapp:

And, I haven’t gone through every single release here to check it.. But isn’t basically everything they uploaded just a 1:1 rip off with a license requirement slapped on it?

I honestly don’t see how this could, in any way, be justifiable and allowed. The project being MIT Apache 2 or whatever other permissive OSS license you can come up with is one thing.

But I don’t think it does (for the very least it shouldn’t) mean that it should be treated with this permissiveness on the JetBrains plugin marketplace. It literally seems like impersonating the plugin, since clicking through the reviews and reddit I get the feeling that many might not realize what is going on, that the author is some random guy who just stole the code and published it as his “Pro version”…

I wish that JetBrains was more strict with managing the marketplace from the get go. I see so many low effort, low quality plugins around (that even seem sketchy) without problems. And then when this happens…

Why should any author want to open source and publish a plugin to the JetBrains marketplace if he gets zero to no protection from low effort copies and impersonations that are violating even the few clauses the permissive licenses have?

7

BTW, just to follow up, it’s not a “similar plugin”, it’s literally an unattributed fork.

And I found some others, which are now MIT violations. Fun.

  1. Solidity Pro (plugin #32553) – MIT violation
  • Original: Solidity (plugin #9475), source GitHub - intellij-solidity/intellij-solidity: Solidity plugin for IntelliJ · GitHub, licensed MIT, Copyright (c) 2016 Sergey Tselovalnikov.
  • Solidity Pro is a package-renamed fork (me.serce.solidity → dev.jetplugins.solidity): ~65% of the original’s classes are present with identical names (e.g. SolidityParser, _SolidityLexer, ide/SolBraceMatcher), and 78 resource files are byte-for-byte identical.
  • The MIT license requires that “the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” Neither the copyright notice nor the license text
    appears anywhere in the Solidity Pro distribution. This is a license violation.
  1. Slint Pro (plugin #32913) – MIT violation
  1. Elixir Pro (plugin #32247) – Apache-2.0, attribution missing
  • Original: Elixir (plugin #7522), GitHub - KronicDeth/intellij-elixir: Elixir plugin for JetBrain's IntelliJ Platform (including Rubymine) · GitHub, Apache License 2.0.
  • Elixir Pro is a fork (org.elixir_lang → dev.jetplugins.elixir) that ships the artifact literally named intellij-elixir-2026.1.11.jar and bundles the unmodified intellij-elixir.jps-builder.jar and
    intellij-elixir.jps-shared.jar from our project. ~71% of our classes are present verbatim and 65 resources are byte-identical.
  • A paid closed-source fork is permitted under Apache 2.0. Apache 2.0 §4 requires that a copy of the license be included with the distribution, and none is present.

Now these ones are mentioned, but the licenses again stripped.

Repackaged open-source colour schemes (the 5):

So can I confirm if just republishing opensource plugins as paid plugins is acceptable?

edit: the editor here changing - > to → makes me sad

8

@joshtau thank you for your thorough analysis, it really helps the evaluation of this matter.

9

Hi guys, thanks for chiming in here. I see your concerns, and thank you for raising them. The concerns raised by Joshua were valid; I was indeed violating the MIT license by not including them. After Joshua raised this, I’ve investigated the issue, and it was caused by overly aggressive Proguard task, which removed these items. I’ve addressed this for all reported plugins, and republished them.

It’s never my intention to rip people off or not provide credits where they’re due; in all plugin descriptions, when the plugin does build on an open source version, there’s a reference to it, and in certain cases I recommend using the Open Source version.

I’m providing support on all of these plugins, as you can see in the public repo, and I’ve spent an incredible amount of time fixing plugins. For example, the Elixir plugin doesn’t work on Window out of the box, and doesn’t deal with multi project files, didn’t support debugging (not sure if does now). I’ve fixed and improved all of that, which took several weeks, and with that I believe I’m providing a better experience than the original plugin.

The small fee I’m asking is not for the software I’m building, but it’s a small amount of money to keep the maintenance of these plugins sustainable, and to deliver the quality which can be expected of JetBrains products and plugins. I’m unfortunately not in a position to do this work for free.

Cheers,
Erik

10

Hi Erik,

Thanks for following up here.

I’m not going to dispute the additional work you claim you’ve done on the Elixir plugin, and I’m not installing it to check what you’ve changed. The additions you list are at best, a mixed bag.

We’ve (intellij-elixir) also haven’t been able to work on many features as we’d like (time commitments, health, family), mostly due to maintenance burden due to drastic changes in 2025.x, 2026.x. Especially around coroutines. You benefited from that work, the whole process of updating the plugin was something that has caused a fair bit of fatigue/burnout.

We (well sh41) added Windows, WSL support etc - which we’ve lodged multiple bugs about having to use internal APIs at the moment.

If the plugin was dead, sure, it’s still shitty, but wouldn’t have minded as much.

Curious: how many changes do you think you need to make to a maintained open-source plugin before the stance above is justified?

If every open-source plugin gets this treatment from developers who want to make money, how many changes does it take before it becomes a closed-source paid plugin, and we end up with countless variations of SomePlugin Pro Reworked (The Next Generation)? One feature? Two? Two weeks of work?

Could I go and take every open-source plugin in the marketplace and claim I made them, from scratch?

The other major problem is that the Elixir, Slint and Solidity plugins all have active maintainers and public repos. These aren’t abandoned projects.

Let’s be honest

But let’s take a step back and look at what you’ve posted publicly on social media, your responses on the GitHub issues, and some responses I have to your slop.

Let me start with a simple question:

@Bodiam.1 - Were you honest, when you published the plugin, about where it came from?

I don’t believe you were, and I don’t think this was ambiguity or confusion about licensing.

On the 23rd of June 2026, you posted to Reddit that you decided to write a completely new plugin for IntelliJ called Elixir Pro.

SCR-Firefox Nightly-20260905-ssij
SCR-Firefox Nightly-20260905-ssij1979×595 104 KB

It wasn’t until 31 August 2026, when a trial user asked outright whether Elixir Pro was a fork, you told him the community plugin is “mostly LSP based” while yours “reimplements the whole language through PSI” (issue #2, 31 Aug 2026, 3:33 PM GMT+8).

The next day, on issue #1, you called intellij-elixir “the source” your plugin is “quite divergent” from (here), and a couple of hours later you said you didn’t think the licence required attribution (here).

Was the plugin completely made from scratch, by you - as you claimed on Reddit, a fork, an inspiration or what?

@Bodiam.1 - When were you going to be honest about this?

It’s not just attribution - you were outright lying.

I’ll quickly break down your claims, what you said publicly before anyone asked.

  1. “I was indeed violating the MIT license … I’ve addressed this for all reported plugins.” You fixed the three code forks the same day, and credit for that. But Proguard doesn’t edit plugin.xml or Marketplace pages, and it doesn’t write Reddit posts. That part is on you, Erik. You took the intellij-elixir main branch, from my estimate, mid-June 2026, with a series of open PRs from @sh41, and mwnciau’s HEEx pull request, so it’s not like this wasn’t pre-planned. You did research. You knew what you were looking for.

On the themes: Bearded, Gruvbox and Lucide got third-party notices on 4 September; Panda and Absolutely still ship none. Bearded’s upstream turns out to be GPL-3.0 rather than MIT (my mistake above), and your new notice now declares the whole plugin GPL-3.0. That is a different obligation from MIT: the GPL requires you to make the source available to everyone you distribute the plugin to, including paying subscribers. Where do they get it?

  1. “It was caused by an overly aggressive Proguard task, which removed these items.” None of the three upstream jars (intellij-elixir 24.0.1, intellij-solidity 2.4.11, slint-idea-plugin 1.6.1) bundles a licence file, so there was nothing inherited for Proguard to strip; the licence would have to be one your own build added and then discarded, across six Elixir Pro releases over ten weeks, without anyone noticing. That same Proguard config kept the SourceFile attribute on every one of the 2,883 classes in your jar, which is not what “overly aggressive” looks like. And it can’t explain the descriptions, or the Reddit post where you announced “I decided to write a completely new plugin for IntelliJ called Elixir Pro”.

  2. “In all plugin descriptions … there’s a reference to it.” Not in Elixir Pro 2026.1.5, 1.7, 1.8, 1.9, 1.10 or 1.11 (June to August), nor in Solidity Pro 2026.2.2 or Slint Pro 2026.1.5. The references, the licence files and the comparison page all appeared on 1 September, the day I posted in the GitHub, and this thread opened - when you finally stopped lying.

  3. The original “didn’t support debugging (not sure if does now).” It has since March 2017. The tree you forked has 111 debugger classes; 110 of them are in every Elixir Pro build under debugger/, next to your five-class DAP adapter. Your own day-one description advertised “Debug real Elixir, graphically. Set breakpoints in .ex and .exs files”. That is our debugger. (Unless you mean DAP?)

  4. “The Elixir plugin doesn’t work on Window out of the box.” The WSL support in your jar (sdk/wsl/WslCompatService) is Steve Hall’s, merged upstream in January. On 23 June you wrote “I have no way to test it on Windows”, while upstream was running a Windows CI leg on every push. Huh.

  5. “Doesn’t deal with multi project files.” Umbrella and multi-module handling has been in the plugin for years. The one concrete multi-project bug on your tracker (#1, absolute paths in .iml) had already been reported on our tracker by the same user (intellij-elixir#3926), because your output was byte-identical to ours. You inherited that bug from us, fixed it on your side, and then cited multi-project support as a reason to pay you. We fixed it upstream on 2nd September 2026.

  6. “This plugin is quite divergent from the source, that it’s not an easy 1:1 copy.” About 76% of our class names are in your jar verbatim, roughly 80% once the renamed classes are traced back. You’ve never rebased: every build from 2026.1.5 to 2026.1.12 sits on that June snapshot, and the one piece of upstream work you have pulled in since is Steve’s Symbol API pull request (#3866, merged in July), which shipped as your “native rename” on 1 September. The main jar is still called intellij-elixir-<version>.jar. Your own “Why Elixir Pro” page now says “a commercial fork of IntelliJ-Elixir, not an unrelated rewrite”. Divergent how? New features on top, sure. That isn’t divergence. And even the HEEx support you advertised from day one is mwnciau’s pull request from our tracker (#3696, open since June 2025), taken before we merged it: 34 of the 39 classes under heex/ in your jar carry the same names, and both HEEx icons are byte-identical to the ones in that PR.

  7. "I believe that one is mostly LSP based, while mine reimplements the whole language through PSI." What the fuck are you talking about. The PSI implementation is ours: 734 classes under psi/ in your jar, plus the lexer and parser generated from our Elixir.flex and Elixir.bnf, with those file names still in the bytecode. The LSP layer (LSP4IJ plus Expert) is the part YOU added. I don’t know how you posted such nonsense with a straight face.

  8. Your why page is incredibly ironic - Elixir Pro's value comes from what happens after that baseline: more framework awareness, more automation, more diagnostics, and a product team responsible for turning those pieces into a coherent day-to-day experience.. Can you share your team? Did they help you create the completely new plugin?

I could break down this entire page and how it’s just open PRs and work you took not just from IntelliJ Elixir, but a bunch of other plugins, and the factual inaccuracies, but I believe this is enough.

None of this changes the legal position, which I’ve never disputed. It’s very confusing for users of the JetBrains ecosystem and for plugin developers, because it wasn’t clear you’d taken someone elses plugin until you were called out on it.

Stop gaslighting, and distracting - you were dishonest from the start, and being called out for it made you finally admit to it, but then tried to make it a “why do you have such a permissive license?!” issue.

I’m not disputing that it’s legal when done properly; that’s the point of Apache 2.0. But your response here shows you knew exactly which licence you were working under, the comparison page you cite was created that same morning after a trial user asked whether this was a fork - it didn’t exist for the first eleven weeks on sale. And the Elixir Pro licence texts went in only after they were pointed out. If this is the business model going forward, I’d recommend reading up on licensing and attribution before the next one.

We all have to eat, and should be rewarded for our work.

But taking maintained open-source plugins, applying some changes, closing the source, claiming it as your “completely new plugin” as a brag on Reddit, and shipping without attribution and bullshit misinformation until called out, then doing the minimum (wrongly, as well), sets a bad precedent for the entire ecosystem. I’m embarrassed for you.

“I believe I’m providing a better experience than the original plugin” is a weak argument when most of that experience is the original plugin. We’ve worked hard on ours too. The Elixir plugin is 12 years old, comes with a lot of legacy code, and it took a ton of work to get the EDT/coroutine migration done.

I’ll leave it to JetBrains at this point - if they would like a full timeline of everything, let me know.

Josh

b0golo
b0golo500×1090 62.8 KB

11

And? Is that forbidden?

it’s open source so by all means it means you give permission to other people to fork and republish it if they want. I am not an expert in software licensing so I could be extremely wrong here, but the OP, as shady as he might be, did nothing wrong (except for the attribution shenanigan which can be easily solved)

If your plugin was closed source and was copied anyways, and has a non permissive license then yeah perhaps. But other than that, it’s just a “sucks but that is life” situation.

12

100% for the opensource ecosystem, I push for it so much in various projects. I’m actually starting a nonprofit ATM as well to help prosper these further.

People can do with the code whatever they like - that’s the whole point, and can make paid plugins if they want, that’s absolutely fine.

But the problem I have is lying, attribution, and slop.

Does this whole process kill the entire idea of the opensource ecosystem here on Jetbrains, kill the vibe of the Jetbrains marketplace, etc?

The marketplace should be curated properly.

Tldr

Substantial rewrites, improvements or changes to plugins with proper attribution :+1:

Slop plugins, plugins without proper attribution and low effort :-1:

13

I agree with you 1,000%, @joshtau . Taking an open-source project, making a few tweaks, and selling it as a paid plugin should at least require approval from the original maintainer.

“Open source” shouldn’t mean taking someone else’s hard work and doing whatever you want with it—it’s meant for learning, collaboration, and finding solutions, not for repackaging it as your own commercial product.

To make matters worse, with modern AI tools, people are now even easily reproducing closed-source, paid plugins, the solution must come from the Marketplace team.

14

This is a spectacularly unsympathetic take for someone in a pretty awful situation.

Quite apart from that, it also ignores a real incentive issue that JetBrains will have to think about - if they want a real OSS ecosystem around plugin dev, this is a serious disincentive to plugin authors to OSS their code.

15

besides that it is also not always the case – because it is tough to prove that someone stole code by decompiling or with AI when the new stolen plugin is also a close source…

16

Again correct me if im wrong but no laws have been broken here. You put your software open for the world to use, and the license usually allows other people to take your work and even resell it. So unless it wasn’t the case, e.g. the main author closing the plugin and Erik cloning it without restraint, nothing wrong here.

If monetization is the problem, then it’s your fault for not monetizing it; if it’s copying that is the problem, then don’t make it open source.

And if it’s AI (lol) then, grow up?

I would shut up if Erik was actually selling shady plugins. I even expressed my discontent to many of his plugins because they were pretty lackluster and the way he responded was not particularly pleasant; but he didn’t do nothing wrong, apart from forgetting to mention, which he did, albeit after the fact and after claiming it was his, allegedly.

17

Says who? Thats such a naive point of view haha

18

I will correct you – yes currently the “law” is not broken but that is the point of this thread to ask JetBrains to change their policy to prevent such situations – that I think you also named it “sucks” …

19

I’m completely fine with anyone forking opensource plugins and doing what they want with them, if they follow the license. That’s the point of opensource. I’ll always wear my opensource hat and fight for Apache 2.0/MIT licenses.

I’m also not batshit crazy like Wordpress vs wpengine, I don’t care about contributions. I care about attribution and being honest.

I’m not here to make money on opensource plugins - I do it to scratch an itch and/or fix problems.

I also, want to clarify:

  1. I have no problems with closed source plugins. I think this is a GREAT thing for the ecosystem. There’s some amazing plugins. Get your company to pay for these. You can also claim these back in certain countries on tax. (I do).
  2. I have no problems paying for good software - I pay quite a bit to support these, and will happily do so.
  3. I don’t care about using AI for shit (if you understand what you’re getting out, I suppose?), it’s 2026. I never mentioned this. It’s great when used properly and can really help research, understand how to modernise codebases, make changes.

What has rubbed me the wrong way is:

  1. Erik claimed he made the plugins, and wasn’t clear about it until asked about it. He mentioned this in the Reddit post, and followup posts made on Reddit.
  2. He claimed he didn’t know how the intellij-elixir plugin worked, which reads as he doesn’t know much about it (when he obviously did).
  3. He didn’t attribute the intellij-elixir plugin (or others) or even mention it, at all. He claimed Proguard, but that’s a weaksauce argument.
  4. The “Why Elixir” page created after he admitted is factually incorrect.

Also, more of a gripe, but the Elixir Pro plugin seems to have (I’m guessing, given the speed of releases) auto-accepting review Marketplace release process, it seems. We still have manual review process on the opensource version. We finally got certain Internal APIs to be accepted and allow-listed each review.

I guess, what I would like Jetbrains to clarify on is “How many changes does it take to justify a closed source plugin fork of an opensource, maintained plugin?”.

The JetBrains Marketplace is supposed to be curated.

This is shit for the JB opensource ecosystem, which for years has been a bit quiet, I was really hoping with all the work people like @jakub.chrzanowski, as well the countless JB employees and JB opensource community have done pushing forward so many great opensource iniatives, it just feels like we need a stance.

20

I’m playing devils advocate here on purpose, mainly because the same thing happened to me when I started monetizing the Material Theme plugin, as the open source owner of the VSCode theme of the same name started threatening me of plagiarism.

Obviously it’s not the case here, but while your concerns about shady attributions are valid, the quiproquo seems to be about whether it’s fine to make money off others’ work. And most of the comments here are upset that this particular developer is profiting off others’ hard work, and as you stated clearly “after which point can we tell whether a plugin is a reasonable fork or just a copy of another?”

Anyways, I think in general you’re right to ask for clarification about this stance. If JetBrains changes their TOC to forbid such practices or if they clarify that it’s ok, at least it will be clear for everyone.

21

Thanks, now I have the perfect place to point users who tell me I should open source my plugin. I couldn’t have made a better argument against it than you have.