[dllthomas]

As you say, it depends a lot on the project, but you're thinking too narrowly when it comes to types of projects. IME, dual license is most applicable to libraries that might wind up in native applications. With, say, "GPL or pay us for proprietary" a company trying to ship a native app is faced with the choice of not using the library, paying for the library, or releasing their product under the GPL to use the library while avoiding paying for it.

[Abishek_Muthian]

Have you seen such dual-licensed library with GPL? Just curious for a real example.

[dllthomas]

https://www.sequencejs.com/licenses/ seems to be a real example, with the free option being GPLv3.

[Abishek_Muthian]

Interesting find, I took a cursory look at their GitHub[1] and they seem to accept PR from outside but I didn't find any explicit mention of copyright transfer; Perhaps because there's no separate version of sequence.js for commercial use(Just use case differentiation).

[1] https://github.com/IanLunn/Sequence

[dllthomas]

> there's no separate version of sequence.js for commercial use

A separate version is "open core", not "dual license" - that's a different business model.

Use case differentiation by means of providing the same thing under different licenses is what dual license (or multi license) means. One license (say, GPL) will be appropriate to some use cases (downstream open source projects) but not for other use cases (downstream proprietary software) and so the latter has to pay for a license other than the GPL.

> I didn't find any explicit mention of copyright transfer

It's possible they know the people who've submitted code outside of github and handled it out of band, or that github has some way I've missed of requiring submissions to assign copyright in a way that wouldn't be visible to us. It's also possible they're being legally reckless and might be subjecting their paying customers to potential (if perhaps unlikely) copyright claims from their submitters. There is nothing about it being the same code under both licenses that would imply they wouldn't need their submitters' blessing in some form to sell their code under the proprietary license, and the more implicit blessing the more likely it'll wind up in court at some point.

[colejohnson66]

Not the GPL, but Qt GUI toolkit is famously LGPL-or-cash

[Abishek_Muthian]

Ah Qt! I knew we often discussed about license of some project. Thanks.

Once again, LGPL being more permissible than AGPL shows IMO the need for having a permissible license for the dual-license.

[dllthomas]

> the need for having a permissible license for the dual-license.

A more permissive license generally improves adoption. For the same level of adoption, a less permissive license drives more revenue in the dual-license model. Maybe a permissive license is still the way to go (certainly getting adoption is often difficult), but it is not the dual license situation motivating that. Contrast a "give away the software and sell support" business model, where (sufficient) adoption is everything and more restrictions on the license doesn't do anything for the business.

With a maximally permissive license, I hesitate to call it "dual licensing", as it stops being the license your paying customers are actually paying for but rather hosting, support, or warm fuzzies.

[Abishek_Muthian]

> a less permissive license drives more revenue in the dual-license model.

But we've so far encountered just one example for that, Even there we don't know the financial status to claim whether it's indeed more successful (revenue wise when compared to a permissible license).

On the other hand we have numerous successful products (by revenue) with permissible licenses incl. those sighted in the OP.

Then again, We all know the fiasco with Elastic.

[dllthomas]

> incl. those sighted in the OP.

Which? I didn't see any using a dual license approach in the OP?