How can I deal with this (predatory?) scenario?

Question

This question is related, but it is different to this one: How can I forbid shady resale practices?

Scenario:

Suppose that a small team or startup (company A), develops a good software project, which works in a browser (HTML, CSS, JavaScript, images, etc.), called here W₁ (from website), and they release it under a FOSS license (i.e GPL).

W₁ can be used at no cost. A wants to use a business model for open-source software, such as professional services, branded merchandise, donations, crowdfunding to add new features, etc. (I will use the term "collateral business", for short)

Because company A has limited money (since the project novelty, it has poor notability), they cannot pay enough publishing services to increase the notability of W₁ and hence it is difficult to reach the pretended collateral business conditions.

Meanwhile, the company P, a medium or big size one and more prominent, takes the source code of W₁, makes modifications, mainly to adapt the software for P image, not in software functionality, and releases the "derivative" work on a different website W₂.

Because the company P has more resources (money, workforce, etc), it is much easier to promote W₂, reaching notability and eventually achieving the conditions for the collateral business model. P has also much more notability (as a trademark) at which W₂ can be attached to.

At the end, W₂ becomes a success, and W₁ cannot. Even worse, given the W₂ success, W₁ appears to be a clone of W₂, when it is actually the opposite.

Notice that company P has no violated any license, if they released the derivative source code under the conditions of the license (using the same license, giving credit to the original authors, etc.)

Even thought the new source code refers to the original authors, final users rarely inspect the license of the software they are using.

Could this scenario be considered unfair?

If so, how can it be avoided? The following are several options:

A. Company A can release W₁ as closed-source at the beginning, and release it as FOSS when it has reached enough notability. It comes with another situations:

A.1. Would releasing W₁ as closed-source affect its notability/success? I think it would not too much, because as I said, people tend to not read licenses in order to check whether the product is FOSS or not.

A.2. Even if were closed-source, being a website, the sources are available because there are not "compiled" or "object" form of web content (excepting, maybe minified/obfuscated JavaScript).

B. Adding The Commons Clause to W₁. I have doubts, because the prominent opinion is that using it makes the entire software not FOSS. Also, it says about "selling the software", but in this case, neither A nor P pretend to sell the product, but using it for "collateral business".

C. Using other (or combinations of other) FOSS licenses. According to this answer:

Whether there is any other license you could've used for "The idea is that a seller would have to give full disclosure so that buyers would know which features of the software they are actually paying for, versus what they can already get for free.": Well, the MIT license already covers that. There's also the LGPL, BSD, Apache license and Mozilla Public License that do what you want.

But they also say about "selling" the software.

The questions are:

1. Can the "Collateral business" be (legally) considered part of "selling the software"? (if so, options B and C could apply)

2. Do you know a scenario that prevents the "predatory" scenario described above? It is preferable (but not mandatory) if it uses FOSS licenses (or a combination of them).

Answer 1

TL;DR: Open Source is not about fairness, but about Software Freedom. It is irrational to publish Open Source, and to be then surprised that others are exercising their freedoms. Once a company has clear expectations about why they want to do Open Source, they might be able to use tools such as CLAs or trademarks to that effect. In the best case, such an adversarial viewpoint isn't even needed.

---

First of all, Open Source is not a business model. Open Source might be part of a business model though. As a corollary, Open Source is simply not a good fit for some business models. It might be better to not make some software Open Source at all rather than be disappointed that other actors are actually using the freedoms you granted them!

Second, the defining feature of Open Source might be the freedom to fork. If A is not a good steward of the Open Source project, other actors such as P must be able to step up and run a fork of the project. For example, when OpenOffice was sold to Oracle, the community was not happy about that and continued development under the term LibreOffice. Some actors try to prevent this e.g. through Contributor License Agreements that privilege themselves over the community, but in the end one shouldn't run an Open Source project if one has a problem with the limited control. In the end, all that the original developer of an Open Source project could control is the trademark. For example, there are many Firefox forks, but only one “Firefox” because Mozilla holds the trademark.

This brings us back to your scenario. If A wants to publish open source software for some reason, it makes no sense to fear that P might fork it, because this would be P's good right. Attempts of A to monopolize economic exploitation rights would render the result Not Open Source (which is fine, but out of scope here). Instead, common strategies include:

• Collaboration. If both A and P derive value of the software and publish their modifications under compatible licenses, then they could work together and merge each other's forks. In order to benefit from the other party's contributions, they would both have an interest in coordinating with each other and not diverging their code bases too far. A successful example of this is Linux, where many companies that would otherwise be competitors work together because they all benefit.

  The danger here is that one party does the majority of the work. This party might feel exploited (e.g. see the Elastic v Amazon spat). The party doing the majority of work could also steamroll the other party, and ignore their needs. This is a danger to small companies stewarding an Open Source project.

• Open Core or Dual Licensing. A has an advantage because they have intimate knowledge of the software. They might use their experience to create useful extensions, which they then sell under proprietary terms. They might also use their copyright control to dual-license the software under more commercially friendly terms. As long as this is reasonably priced, no other commercial actor will have an interest in competing with that offering. It makes no sense for P to start a competing development (expensive!) if they could just license the technology.

  The problem is that such approaches generally rely on A having a monopoly on the project, e.g. via a CLA so that they are not bound themselves by the license terms. A will also find that even the most copyleft Open Source license will not prevent competing commercial use. Thus, many actors that have tried these models have switched to licenses that are Not Open Source (especially in the database space).

• Trademarks. In an Open Source project, the trademark is the only IP that is typically not licensed out. As already mentioned, Mozilla uses this to make sure that Firefox always refers to their software, not to potentially dodgy forks. This is generally unproblematic: if someone wants to start a competing project, they'll have to pick a different name. Perl also has an interesting license that effectively says “either you publish your modifications as Open Source, or you'll rename your program so that it won't interfere with the Standard Version”.

  In your question, you have already pointed to a huge limitation of this: trademarks are only worth something if they are recognized. A fledgeling project would not have widespread recognition. But I don't think that is a huge issue since communities are not typically interested in names, but in whoever seems a reasonable steward of the project. I've already mentioned the OpenOffice → LibreOffice migration. As a more recent non-software example, consider the Freenode → LiberaChat exodus.

  Open Source licenses help here in so far as that they require attribution of the original. Both Apache-2.0 and GPL-3.0 have explicit provisions for retaining reasonable attribution notices. If P forks A's project, they would still have to include A's notices in all copies of the software. Downstream users can then decide for themselves whether they would rather stick with the original by A, or if the modifications by P are a value-add.

To finally address your specific questions.

1. What does “selling a software” mean? Nothing. Whatever it means, an Open Source license will not prevent it. The Commons Clause defines “Sell” very broadly, also including collateral business such as consulting, but the Commons Clause is very much Not Open Source.

2. Can predatory behaviour be prevented? I don't think so. I think there's a lot of disappointment from companies which have a business plan like “1. Open Source. 2. ???. 3. Profit!”. That cannot work. Instead, I think the proper approach is to ground the expectations about what doing Open Source means.

   • Is a company interested in increasing Software Freedom, and just wants to make enough money to feed its devs? That's probably doable without a lot of regret (though there are many counterexamples – making money from systems-level software is especially hard).
   • Is a company using the Open Source offering as a sales funnel towards paid services? The math may or may not work out, but it's irrational to be disappointed when another company starts eating a large slice of the sales pie.
   • Is a company only doing Open Source for “personal” use? Yeah no, they'll be severely disappointed when other companies exercise their rights under the Open Source terms.

   At this point, it might also be worth considering that most Open Source projects are not wildly successful. By itself, code is worthless. Projects are of social, not technical nature. Unless a community forms itself around the code, it doesn't really matter if the code is open source or not. This also means that just throwing some code on GitHub is usually irrelevant (and I have published many irrelevant projects!). A company will not save money by doing Open Source, because there are no droves of highly experienced but bored devs just waiting for an opportunity to contribute something. Fostering Open Source communities takes real effort.

So the “trick” is to be aware of the limitations of Open Source. If a business cannot succeed when other actors exercise their rights, then maybe an Open Source strategy just isn't a good fit for the business. Sometimes this can be addressed by legal mechanisms such as trademarks. Often, this can be addressed by redefining success – competition doesn't have to mean that I starve. While I would love to see more Open Source in the world, this is just not always sensible given the market realities.

Answer 2

1. The use of the non-FLOSS Commons Clause would probably prevent this insofar as it prohibits collecting "fees for hosting or consulting/ support services related to the Software." Rebranding the software and selling merchandise is probably allowed, but any paid service or support is probably not allowed.

2. I don't see this as being a large problem. I am not an expert in business plans, but I note the following:

It must be well-known to paying customers that W₂ is also open source, because P had to offer the source to them under the GPL. I would not expect paying users to believe that W₁ is a clone of W₂ but rather that it may be a fork of it. Indeed the situation is actually the opposite, but I don't think it matters much: if A can convince customers they can competently offer services around W₁, I think they can demonstrate similar competence around W₂. They can truthfully claim to have been offering solutions in the W problem space for longer than P.

Since A prudently selected a copyleft license, they can pull down any useful changes P makes and include them in their own offering. In the words of the GNU Manifesto, about a free operating system:

GNU will remove operating system software from the realm of competition. You will not be able to get an edge in this area, but neither will your competitors be able to get an edge over you. You and they will compete in other areas, while benefiting mutually in this one.

If people trust W₂, then A can usefully claim their offering is powered by identical code and supported by experts in the domain. It is quite possible A could never have achieved the level of success and public awareness that P enjoys with W₂, and their status as a competent competitor to P may be advantageous marketing.

As for selling branded merchandise, I see P relying mainly on their P-related trademarks, and folding W₂ into the family of P trademarks. I think A will be able to succeed in capitalizing on their marks about as well as if P had never gotten involved.

Answer 3

Could this scenario be considered unfair?

No. It is simply a bad business plan of company A.

The GPL and other open source (as in freedom, not beer) licenses are exactly what they are. There is no "if, when or but". One reads the license, follows it to the letter, and that is that. There is no moral, ethics or fairness here.

Company A was able to read the GPL, they applied the GPL out of their own volition. Nobody forced it on them, certainly not company B. Company A had all the information beforehand - they knew they were small, they knew that they probably would not be able to be able to use the software to gain financial benefit. They just failed from a business point of view.

Nobody can take the software away from A. They are free to keep trying to come up with a working business plan. They can join forces with the other company (i.e., pull B's fork back into A's code base and thus benefit from all the improvements). If B manages to have success off the software, then not because B somehow stole anything from A. B cannot force any user of the software to use their fork, except by throwing out better quality code (which, in turn, A can always pull back and merge in their original fork).

If B decides to, for example, create a paid service on top of the software, then the software is still free. B cannot lock users into their version of the software using their paid service - any user can always get the open source software. This is fair; B is providing a service, and is getting paid for it.

Answer 4

In what way is this unfair? You gave P the software under the condition that they follow the terms of the license. As long as they're obeying the license, they're doing exactly what you asked. Are you upset that they're making money? If that's the case, use a license that expressly forbids commercial use. You can't simultaneously give someone permission to do something and also be upset that they're doing it.

For a strong copyleft license like the GPL, P's version is a derivative work and thus must also be released under the GPL. Whoever buys the first copy can re-distribute it for free, so P's business model isn't going to pass the sniff test with the legal department. They'd have to provide some sort of value-add that can't be duplicated.

In this specific case, you're talking about P creating a commercial website that's powered by your software. There's more at play here, though. P is also paying for the infrastructure hosting their site, creating content for the site, handling customer orders, etc. None of that was copied from the original project, P is adding real value to the original and there shouldn't be a problem with them profiting from that additional work.

Since this software is for a website, I recommend looking at the AGPL which is designed for web software. Source code for P's version would have to be made available to anyone who uses the website, not just those who get a copy of the website software.