Announcement: The Upcoming Version 2.0 Will Be Released Under Dual-License: AGPLv3 License / UAParser.js "PRO" License

[faisalman]

Hi All,

We've been announcing this change in a discussion page two weeks ago, but since it might not reach the large part of the community, we will provide more details about the change here:

TL;DR all the past and future releases of version 0.7.x / 1.0.x remain MIT, while version 2.0.x will be under AGPL.

What the license change means

Starting from version 2.0 you'll be able to choose between using our regular free & open-source license (under AGPLv3) or PRO license. AGPLv3 is an OSI-approved open-source license from GNU, pretty much same as GPL, only with an addition of network clause. If you opt for the free version of UAParser.js, you just need to provide the source and changes that you've made to the library. If you opt for the PRO License instead, you don't have to open-source your modifications. We offer 3 tiers of PRO License: Personal (non-commercial), Business (1 license per project), and Enterprise (indefinite projects).

Note that if you are using the current stable version of v0.7.x / v1.0.x then you won't be affected by this change since this new license will only applies to v2.0.x upwards. You can continue using those old versions as usual without the need to revisit the terms as we have no plan to re-license them. The development for those versions also won't get prioritized, alhough they might still get occassional updates, particularly for bugfix-related updates.

Behind the change

Looking back, after more than a decade, what initially started as a for-fun and for-learning side-project, has been slowly growing to become a popular module in npm, with almost ~12M downloads per week, and are being used by top tech companies, with a little to no incentives.

Looking forward, we still want to continue develop this small project to be even more awesome. For it to be successful we are aiming for a sustainable model that works for an open-source project. In the past two years, we have tried the voluntary donation route with a little success. This time, we decide to try a new model where we can get paid for maintaining the project while still keep it Free & Open-Source.

Future roadmap

Lately, Chrome has been freezing its user-agent in favor of their new proposal for a user-agent client hints. Although other browser vendors like Apple & Mozilla doesn't support it, but with Google's massive share of browser usage, incorporating User-Agent Client Hints data on top of the existing User-Agent seems inevitable if we still want to get a reliable detection, like avoiding the vague Android K, differentiate Windows 11 from 10, Brave from Chrome, etc. On top of that, other major browsers that doesn't support client hints also starting to freeze some part of its user-agent, which made feature detection the only route to identify iPad from macOS.

These kind of future-proof detection enhancements, along with some new cutting-edge features, better tooling support (ESM, TypeScript, etc), more extensive test, helpful documentation, and other best practices, will be available in the upcoming version 2.0 of UAParser.js.

Finally, we are aware that collaboration will be the key for this plan to be successful. If you have something to ask or offer, please don't hesitate to drop us a question here or email us directly.

Thank you!

Faisal Salman
Maintainer of UAParser.js
https://github.com/faisalman

[philstools]

When using an unmodified, CDN-hosted, version of the (2.0) library, does the website javascript code need to be AGPL too?

[MarioRicalde]

1. The corporate-like message makes me wonder about who is "We"?
2. Will this money be going to past, active and future contributors? If not, what is the strategy?
3. Will this change affect third-party services like: "51 Degrees", who forked and made a monetized offering and has rather aggressive techniques to acquire costumers, documented in issue Is this package a lead generation tool for the "51Degrees UAParser" cloud service? #634 ?
4. Will there be any guarantees for paying customers in regard to situations like: Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js #536 ?

[faisalman]

Thank you for the questions, please allow me to give my view on these matters:

@philstools

From my understanding of the AGPL license, only the code that contains what's considered as a derivative work that needs to be released under AGPL-compatible license as well.

@MarioRicalde

1. "We" means the team behind UAParser.js.

2. Collected fund is intended primarily to support the team members that regularly maintain the project. Only after a certain threshold reached, we'll then be able to allocate some fund to be distributed to all contributors fairly.

3. This change doesn't affect past/future forks of v0.7 / v1.0.

4. No guarantees, but you can easily check the provenance statement of our published npm packages and verify its integrity by using security tools of your choice.

   

[Nikemare]

@faisalman Please have a look here: https://snyk.io/learn/agpl-license/#closed

AGPL is a strong copy left license. I'm not sure if this is really what you intend to do.

I think LGPL, MPL, CDDL or EPL, which are all weak copy left licenses, might be what you really want to achieve.

[faisalman]

@Nikemare @TIncorviaITLS which license would you suggest? We're aiming for an open-core model to simply maintain a mutual balance between us and our users.

[ketys-from-meiro]

Is Android K thingy already addressed in v2.0 or will it come later?
Why/when should I choose to use paid version of UA-Parser library? We're currently using it as dependency as-is in our JS SDK in business.

[faisalman]

@TIncorviaITLS

From our perspective of an open-core model, in UAParser.js case, v2.0 can be regarded as a combination of v1.0 (the open & limited "core") + some added features (the commercial add-ons / "shell").

@ketys-from-meiro

The Android K issue has been addressed in v2.0, please see #648.

You should choose the paid version only if you need the features of v2.0 but don't want to comply with the AGPL license.

[MarioRicalde]

We need a lot of clarity on these terms: "Core" "Shell".

The change from MIT to AGPL will cause your application to be removed from virtually all credible open source projects and open source and commercial products and SaaS offerings. Or, the existing MIT version of your application will be forked and maintained outside of your control.

This. 100%. Not to mention that the license change is happening in such a "weird" way (small notice, not a lot of traction.. etc). We are not sure if we should trust this or the maintainer after these moves.

[faisalman]

@MarioRicalde

We need a lot of clarity on these terms: "Core" "Shell".

https://en.wikipedia.org/wiki/Open-core_model
https://dev.to/ryandawsonuk/the-open-core-business-model-363n

In UAParser.js case, basically:

(v1.0 as the "Core") + (some new features like client-hints, feature-detection, etc as the "Shell") ==> v2.0

This. 100%. Not to mention that the license change is happening in such a "weird" way (small notice, not a lot of traction.. etc). We are not sure if we should trust this or the maintainer after these moves.

Thanks for the insight. Any idea on how to announce the change as to not be considered weird? We're thinking about adding a postinstall message but it has been considered as a spammy behavior.

[sandstrom]

@faisalman A few thoughts:

• Look at https://sidekiq.org/, they're a fairly successful paid open-source project.
• I think the approach of using licenses for different groups (the table) is overall a good one.
  • The good thing with life-time is that it's easy for companies, just pay once and be done with it. The problem though is that your cashflow won't be great after the initial spike. An annual fee might be better.
• As an alternative to paying via credit-card, maybe you could also offer the license to anyone paying above X in Github donations. That way, companies that are already using Github donations can use that payment mechanism.
• For code workflows to work properly, don't use a private NPM registry. Instead, just make it a license thing, where companies are obligated to pay, but there won't be any technological check to enforce it (like a private NPM registry would). The trouble with private NPM registries (like FontAwesome has), is that it causes a lot of work to set it up. So many will just look for an alternative library instead of bothering.

[faisalman]

@sandstrom

Wow. Thanks for the thoughtful inputs!

The good thing with life-time is that it's easy for companies, just pay once and be done with it. The problem though is that your cashflow won't be great after the initial spike. An annual fee might be better.

Indeed, our idea is that by offering a one-time payment we hope that it would make it easier for companies/developers to spend their development budget. While we also realize that it would make our revenue to be unpredictable on the other side, but it's something that we can accept at this time. We'll try to reconsider this at some point though.

As an alternative to paying via credit-card, maybe you could also offer the license to anyone paying above X in Github donations. That way, companies that are already using Github donations can use that payment mechanism.

This seems to be easy to implement yet overlooked by us, will definitely try it! 👍

For code workflows to work properly, don't use a private NPM registry. Instead, just make it a license thing, where companies are obligated to pay, but there won't be any technological check to enforce it (like a private NPM registry would). The trouble with private NPM registries (like FontAwesome has), is that it causes a lot of work to set it up. So many will just look for an alternative library instead of bothering.

Agree 100%! We prefer to provide the migration experience to be as seamless as possible. Currently we are publishing the packages in public npm registry under our organization scope: @ua-parser-js with the license agreements as the only difference.

[lancedockins]

@faisalman A few thoughts...

I had never actually heard of your library until today as I was looking for a JS-based UA parser script to use in one of our company projects. We can write our own. But we try to be efficient with our time when possible.

In any case, I definitely represent the kind of company that would seriously consider purchasing an Enterprise license. In fact, I actually came very close to buying one today. This licensing issue, however, is the thing that stopped me from doing so. Companies that can afford an Enterprise license are going to think a bit differently about scripts that have any connection whatsover with a strong copyleft license like AGPL3. We have a lot of proprietary pre-existing projects that are entirely incompatible with open source copyleft licenses. While your UA Parser script is great, it's most definitely not worth the risk that its use in a pre-existing proprietary project would "infect" all separate and pre-existing code.

Just to keep it short:

• So much as mentioning AGPL or GPL (particularly later versions like version 3) creates a nearly insurmountable perception of copyleft risk for commercial users. MIT and other free licenses that have no copyleft risk do not scare away companies that can afford commercial licenses. Anything GPL does.
• You aren't offering a lot of clarity around what the text of the commercial license is. So there's no way to know what you would be getting into after a purchase. Considering that the free version is AGPL3, it's reasonable to assume that the Pro version is going to be somehow restrictive - at least substantially more so than the MIT license. The question is how restrictive and that is going to determine whether a company would so much as consider a purchase here.
• The chart/table that you provide comparing editions mentions AGPL3 in a way that makes it seem like it still applies to Pro versions. You definitely need to fix that chart if you're saying that Pro versions are NOT subject to AGPL. No one is going to risk using AGPL software in proprietary or private projects. And they absolutely are not going to pay to use AGPL code in those projects. Private/proprietary and AGPL are completely and totally incompatible. So there can't be even a hint of risk or uncertainty about that if you want a company that can afford such a license to pay for one
• There's probably going to be some question about whether you can even legally dual license AGPL code as Commercial or not. I'm no lawyer. I suspect you aren't either. So just saying that it's OK and that it poses no risk isn't going to be good enough. For private/commercial projects, it has to be 100% absolutely clear that there is no risk or possibility of AGPL/copyleft licensing in any way affecting their projects due to the use of your script.

For a commercial/private enterprise, copyleft is a HUGE risk. It's so huge that a lot of companies will not touch any project that even suggests that it has a connection with GPL or AGPL. The only time that I've seen open source projects used by private companies, those projects have been either MIT or similarly licensed (as your script has been until now) MIT and similar licenses are known to have no risk of copyleft for the private company. There's a reason for that. There's just no room for gray areas with this stuff for private companies. It's either safe to use or it's not. If there's even a question of whether it's safe to use, that falls into the "not safe" category by default for most companies.

When a package is deemed unsafe, a company that can afford a license like this has a few options:

• Write their own
• Fork a pre-existing version that was on something like MIT and then maintain it internally
• Use something else

They typically can afford every one of those and all of those are going to be safer than using anything that "might" have a copyleft connection (and definitely lacks clarity about that).

Given all of that, I think you might be undercutting the overall goal with AGPL + Pro. As others have already mentioned, AGPL + Pro will likely delist the project from a lot of distribution channels that it currently enjoys but if you're also scaring off any commercial buyers with talk of copyleft licenses, then the entire project is just going to head to the trash bin rather than get funded.

For what it's worth, you might try to change this to something that appeals to all existing user groups that you work with right now. That might be something like:

1. Having two distribution channels - old and new.
2. Old could be MIT (as it has been) and would just get something like bug fixes (with a time delay for non-critical bug fixes)
3. New could be purely commercial and would be where new dev and features go. It might make sense to have some degree of support included with your Pro licenses as well. You might also give bug fixes out immediately as they are available rather than on a time delay. E.g. you could provide critical bug fixes to both branches and non-critical ones on a time delay. Maybe something like a 2 week delay for critical to hit the old branch and a 3-6 month delay for the non-critical bug fixes to get from new to old.
4. As you hit major milestones, you could roll the current "new" version down to "old" and put it on MIT and you could make a new "new" branch that would become the new Pro version. That would serve as a breakpoint that would justify a license upgrade for Pro users if they wanted to maintain support, access to new features/bug fixes, etc in the "new"/Pro version.

There are other ways to monetize like support programs and such too. But the model that I'm suggesting has several advantages over the AGPL + Pro route that you're proposing:

• It won't piss off a large chunk of your existing user base (that won't pay for Pro)
• It won't scare off a large chunk of your existing user base (that would be open to Pro but won't touch anything that mentions a copyleft license)
• It won't jeopardize your existing distribution channels because you'd still be distributing the old branch with minor maintenance (even if less often) under the MIT license
• It provides an actual incentive to buy a Pro license to the companies that can afford it but without the perceived copyleft risk of using your project

I know that while I won't touch a project that has any perceived risk of copyleft for our private projects (even if they "say" that they have a pro license that isn't copyleft), I not only will but have purchased pro editions of projects that do something like I described above where an old branch/version is MIT and the new/feature/R&D branch is Pro only with some limited support.

Take all of that for whatever it's worth. I just thought it would help you to get the perspective of someone that is fully inside of the demographic that you're trying to court with these Pro licenses (since I came close to buying one until I saw the AGPL connection).

[TIncorviaITLS]

@faisalman: for enterprise software companies, the surprise license change from MIT to AGPL is the end for your project -- it will be forked under MIT or simply removed. If you value continued control of the project, consider reverting to the MIT license.