2

Suppose Product X, produced by for-profit Company X, is released in two versions, a GPL "community" version with full source available and a paid commercial version for which source is not offered. The commercial version is built from the same codebase as the GPL version but includes a number of "commercial features" only available in this paid version. The business model of Company X is selling the commercial version and supporting that commercial version, while offering the GPL version on an as-is community-supported basis.

What stops me from taking Product X's community edition source code, adding the commercial features myself (based solely on the descriptions on the product comparison page for Company X), changing the name of the program (to avoid branding issues?) and re-releasing my version with the added features under the GPL? Suppose I started my own business providing support for my version, but for a lower price than Company X? Would Company X have any legal recourse against me for "stealing their customers" assuming they could reasonably prove that they lost many customers to me since I'm offering a better deal (free program vs. paid, cheaper support)? (For example, assume they had statistically significant survey results indicating people left for my product, while simultaneously demonstrating a significant loss in sales)

Alternatively, suppose I simply copied Company X's business model. I take the GPL version and only add in functionality for plugins, releasing this plugin-enabled version under the GPL. Then I release my own paid plugin under a commercial license. Now I undercut Company X by charging less for both the commercial plugin and for support. (Come to think of it, this feels like it could be a way to violate the spirit of the GPL...)

Or perhaps is Company X in GPL violation for even doing this business model in the first place with a GPL community edition and a commercial product based on the same code?

1 Answer 1

3

What stops me from taking Product X's community edition source code, adding the commercial features myself [...], changing the name of the program [...] and re-releasing my version with the added features under the GPL?

Absolutely nothing. One of the freedoms that open source software gives you is exactly this.

Would Company X have any legal recourse against me for "stealing their customers"

No. (Disclaimer: legal jurisdictions vary. I can't see how this would stand up in an English court, but I'm not a lawyer).

I take the GPL version and only add in functionality for plugins, releasing this plugin-enabled version under the GPL. Then I release my own paid plugin under a commercial license.

I don't think you can do this though. It's pretty clear that the core code and the plugin form one body of work and so the GPL would apply equally to the plugin.

Or perhaps is Company X in GPL violation for even doing this business model in the first place with a GPL community edition and a commercial product based on the same code?

Assuming they are the copyright holder of all the GPL code in the product (or have appropriate licenses from the copyright holders), they are fine as the copyright holder is never obliged to follow the terms of the GPL - the GPL is a grant of additional rights to other people, not a removal of rights from the copyright holder.

5
  • I'm interested in your take on plugins. If an app is GPL and supports plugins, do all plugins have to be GPL? Suppose I wanted to sell a plugin for Audacity. Audacity supports VSTs which clearly do not need to be GPL. If I were to mod Product X with a plugin framework and then sell plugins, why would I need to make them GPL? Let's say Product X was an audio app and I wanted to add VST support. Suppose Company X sells it's commercial features as integrated into the code, not as plugins, but I add VST support then replicate the pro features as VSTs. . I'm curious as to where this line is drawn.
    – fdmillion
    Aug 10, 2021 at 22:51
  • @fdmillion Derivative works of GPL software must be GPL. Companies like nVidia do argue that the majority of their driver is not derived from the Linux kernel, but a wrapper layer is, and the wrapper layer is the only part that is distributed under GPL, but because of the GPL rules they can't convey the wrapper+driver together to the user as one product, instead they have to ship separate parts that get combined together on the user's computer and it's a big hassle.
    – user253751
    Aug 17, 2021 at 9:09
  • @fdmillion so if nVidia's interpretation is correct, you can ship an VST-to-Audacity wrapper plugin under GPL, but you can't ship it together with any VSTs that aren't GPL. The VSTs obviously aren't derivative of Audacity, and your plugin is not derivative of the VSTs, so there is no licensing problem.
    – user253751
    Aug 17, 2021 at 9:09
  • @user253751 but based on that assumption then I could indeed take the GPL code, rebrand it, add plugin support (with the plugin support code being GPL), reimplement the pro features as a plugin, give away the rebranded GPL version, and sell the plugin as long as it's not considered part of the core GPL app. Of course now that I've added plugin support as GPL, anyone else could make the pro features as a free and/or GPL plugin. But at that point it's just like OpenOffice "reimplementing" Office. Interesting discussion.
    – fdmillion
    Aug 31, 2021 at 14:34
  • @fdmillion You might still be in trouble if your plugin can be considered a derivative work of the GPL app. That's been tested in court even less than the rest of the GPL. Obviously a plugin that was created without any reference to the GPL app cannot be a derivative of it, but now you are designing one specifically to integrate with the app...
    – user253751
    Aug 31, 2021 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.