Had anyone encountered this before? Is this a common practice? The scenario seems bizarre to me and I'm surprised that it's allowed.
Ask HN: Derivative product license that forbids use of FOSS version?
1–4 of 4 posts
Re: Ask HN: Derivative product license that forbids use of FOSS version?
#2I can think of a couple of reasons why the company might suggest this; the most obvious being that they don't need to guess how many instances your enterprise is using. Whether it makes sense to you and whether the Apache license allows for that kind of legalese is still another matter.
[PS.] you might want to add an "Ask HN:" prefix to your submission subject line
Re: Ask HN: Derivative product license that forbids use of FOSS version?
#3Is there a difference between the products, or is it just the Apache versus commercial license? Ie. will you be able, but not allowed, to view and make changes to the commercial product? I can think of a couple of reasons why the company might suggest this; the most obvious being that they don't need to guess how many instances your enterprise is using. Whether it makes sense to you and whether the Apache license all…
The commercial product extends the open source project to add other capabilities. The source for these extensions is not distributed. (The result is a tool distributed in binary form).
Re: Ask HN: Derivative product license that forbids use of FOSS version?
#4Is there a difference between the products, or is it just the Apache versus commercial license? Ie. will you be able, but not allowed, to view and make changes to the commercial product? I can think of a couple of reasons why the company might suggest this; the most obvious being that they don't need to guess how many instances your enterprise is using. Whether it makes sense to you and whether the Apache license all…
> Is there a difference between the products, or is it just the Apache versus commercial license? Ie. will you be able, but not allowed, to view and make changes to the commercial product? The commercial product extends the open source project to add other capabilities. The source for these extensions is not distributed. (The result is a tool distributed in binary form).
If such separation is not possible, the commercial version spells trouble. For one license wise, but on a technical level it's probably a fork. A fork might have its own security flaws and bugs, but will also need to maintain updates and backports from upstream / main branch. The commercial entity is responsible for this, whether they intend to or not.
In theory, this could lead to a better commercial product, but in practice I would recommend sticking with the FOSS version.