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.

[sandstrom]

I disagree.

Take Sidekiq Pro for example. It's offered under LGPLv3 and a commercial license. Here are some of the companies that are paying for it:

• Netflix
• Adobe
• Oracle
• Digital Ocean
• Heroku

https://sidekiq.org/products/pro.html

That said, I do think you (@faisalman) should basically copy-paste the license, FAQ and purchase flow from Sidekiq, or some other software project that has done this transition.

Companies won't be bothered by the cost, but they will care about 'ease of purchasing'. This is a mix of terms/license, payment methods, distribution, etc. Regarding distribution, I'd go with plain download (this is the approach that Docker desktop took, which I think will serve you better than private NPM -- that's a lot of hassle).

All this said, I still think it could be the end of your project, because getting someone to fork out money is always difficult. But I don't think a commercial license in itself is a blocker.

[TIncorviaITLS]

Sidekick Pro has an existing license and an infrastructure for billing. So far, the UA.Parser.JS license appears to be an idea. Until there is an acceptable EULA, a payment infrastructure, etc. there will be little uptake. QUESTION: how many licenses have been sold to date?

[faisalman]

@lancedockins @sandstrom @TIncorviaITLS

Thank you for the thorough evaluations. It's really valuable for us to get to know from the enterprise-side perspectives. We see some interesting points to be considered within this transitioning process. Thanks!

[TIncorviaITLS]

Please post a link to the terms and conditions of your commercial licenses. I see that there are fees for the commercial licenses, but I do not see copies of the licenses (i.e., the terms and conditions related to the commercial licenses). Thanks

[jkjustjoshing]

I went to the website, saw the table for the different licensed versions, and wanted to use the MIT licensed one. But there's no indication of how to do that. I poked into the /dist folder, expecting 2 versions, a stripped down MIT one and a beefier AGPL one. However, no indication of that.

It's only once I snooped around the issues and find this one that I understand how the MIT vs AGPL license works, and know I need to use 1.0. Your messaging on where the divide is and how to acquire the MIT licensed one should improve

[faisalman]

@TIncorviaITLS @jkjustjoshing

Thank you for pointing. I'll work on enhancing the clarity of the licenses.

[castarco]

@faisalman I'm having doubts about which one is installed when we install it from npm and set the version to 2.0.0-beta. Is it the MIT one? or the AGPL/privative one?

I have no trouble with paying for the license, but of course I want to be sure that I'm getting the more complete one, and it is very unclear how to obtain one or the other.

On the other hand, I'd have preferred to go through sponsorship instead of going through Lemonsqueezy, for clear reasons: it's a win-win situation since it slightly increases the visibility of the sponsor as well.

[faisalman]

@castarco

If you installed it from ua-parser-js package then it's either MIT (v1.0) or AGPL (since v2.0).

But since you have purchased the PRO license, you are allowed to use the @ua-parser-js/pro-business package which is released under private license. This has been described in the provided link within the same email as license key. I'm sorry if the instructions isn't too clear.

As for the license acquiring method, I'm currently using Lemonsqueezy as I found it to be easy to setup and pay, however, if one have trouble using it or prefer to use another method they can also purchase the PRO licenses from my GitHub sponsors page: https://github.com/sponsors/faisalman?frequency=one-time

[zhoulei-source]

If I am using the free version 2.0 beta of ua-parser-js and I do not make any modifications to it, do I need to open-source my code? Can I use it for commercial purposes?

[ljharb]

Will the v1 line (the one the entire ecosystem is likely to remain on for the duration) receive security vulnerability backports, or is it explicitly End of Life?

[faisalman]

Will the v1 line (the one the entire ecosystem is likely to remain on for the duration) receive security vulnerability backports, or is it explicitly End of Life?

@ljharb we’ll try our best to keep the v1.x line alive and well. It will certainly get occasional updates, especially when it involves vulnerability bugfix.

As can be seen that since the license change was announced at v1.0.35, v1.x is still getting updated several times:

https://github.com/faisalman/ua-parser-js/releases

[ljharb]

Awesome, thanks for confirming :-)

[kamikazechaser]

@faisalman

I personally support the change to AGPL-3.0 + offering a PRO license to those who fear the strong copyleft principles and "viral" nature of (A)GPL. OSS development needs to be sustainable and your proposal is fair enough.

There is some FUD in this thread that AGPL-3.0 is an "unsafe" license. Yes, you cannot use an AGPL-3.0 licensed library in a proprietary system or even import it in an MIT licensed project without making either software open source and GPL-comptible licensed as well.

However, there is the alternative of the PRO license being offered (which you are not coercing anyone to use). If they don't like the terms of the AGPL (Copyleft/FSF/GNU principles) they can always pay and obtain the usually more permissive commercial/PRO license.

[aagorelik]

As 2.x is now AGPL, we can't use it in our software (or migrate from using 1.x) - our security/provenance scanners (ie Docker Scout) pessimise our image ratings due to the use of AGPL (even though used unmodified), something we can't afford having enterprise clients. As it seems, 2.x branch will be a priority in terms of new features and support, hence seems unlikely that 1.x versions will be in the focus - we are stopping using the library altogether and look for alternatives. Just a feedback - you are obviously free and fully entitled to pick the license that you see fit.

[faisalman]

Hi @aagorelik, Thank you for your feedback! In addition to AGPL, we also offer PRO licenses for more permissive use -if your security scanner allow for such commercial license. I’m sorry to hear that you have to leave. I’d be happy to get more suggestions on what we should improve.

[nwalters512]

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.

It sounds like what you actually want is the LGPL license, as that permits linking without restrictions while still requiring that one release their changes. The AGPL is much stricter. For Node/JavaScript, it's broadly agreed that requiring or importing AGPL-licensed code triggers the virality of the AGPL and would then require the enclosing work to also be licensed under AGPL. I don't know that this has ever actually been tested in court, but I'm not interested in testing that myself.

As it stands, it's unclear what license I should pick if I want to give you money. "PRO Business" is not listed as allowing "unlimited use". What limits to the use are there? It's listed as being offering a permissive license. What license is it licensed under? I run an open-source project that folks can run themselves, but also offer a hosted version. Is buying a licence sufficient to cover my own commercial use, as well as all use of my project by others? If not, what license option do you recommend here?

[faisalman]

Hi @nwalters512, For your use case, I recommend the PRO Enterprise License option, which allows you to distribute your software that includes UAParser.js to an unlimited number of customers. However, this license includes the following restriction clause: "You may not deliver a Project that contains The Code as an open-source Project that might be used for commercial purposes by the general public, except with our written consent". To address this, I can provide you with written consent in the form of a license addendum for your specific situation.

[nwalters512]

Unfortunately $600 is untenable for me right now. Thank you though.

My unsolicited advice: I'd strongly encourage you to update your original post on this issue to make it clear what the AGPL license requires of users. It is not as simple as "you just need to provide the source and changes that you've made to the library". You're free to license your code as you see fit, but you shouldn't mislead potential users about what using AGPL-licensed code will mean for them.

[faisalman]

Thank you for your advice. I truly hope I’m not misleading anyone. Here are some articles that share the same perspective that I’m referring to:

• Understanding the AGPL: The Most Misunderstood License
• The falsehoods of anti-AGPL propaganda
• Java and AGPL 3: How Far Does the License Extend Into a Web App?

Although, I do agree that there are various interpretations of the AGPL license, and that this should be discussed more to avoid misunderstanding.

[nwalters512]

The first two articles essentially deal with the case of interacting with an AGPL-licensed binary in another process (e.g. a database that's communicated with over a socket), which is broadly considered not to be a derivative/modified work under GPL licenses. us-parser-js is not such a piece of software; it's a library that will live in the same address space as the code that is using it, and it's generally held that such static/dynamic linking does constitute a derivative/modified work (or at least this question hasn't been fully settled in a court). This is the point of view that the FSF takes in their GPL FAQs: https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic.

If you want your code to be licensed under "the perspective you're referring to", I believe the LGPL license is what you want, as that permits linking (importing/requiring) this library without also requiring that the library/application using it also be licensed under a GPL license, provided that one does not modify ua-parser-js. If you do actually want to license under AGPL, you should update your description of the obligations under AGPL to be more accurate, or at least include the FSF's position on the matter and let folks make an informed decision.

[faisalman]

I see your point, and I apologize if the current explanation regarding the license's potential effects contains inaccurate viewpoint. I'm continuously work on improving the description to be more comprehensive. Thanks!

[forty]

Hi there, happy new year 🎉 I'm discovering this just now well after the battle :) Also came here for unsolicited advice (sorry 😬 ) and too late anyway ^^

When doing such a license change, IMO it would be better to publish the new-licence code under another package name (like ua-parser-js2), then mark the old one as deprecated. It would make easier for dependent packages to notice the old version is now unmaintained (or mostly unmaintained), and would avoid "trapping" users that might upgrade a bit too carelessly (which I'm sure is not the goal here, but still, given the state of the JS dependency ecosystem, it is bound to happen).

Regarding the license choice, my feedback is:

• as an individual I really like the AGPL and I think it's great to avoid private companies to take advantage of your free work
• as an employee of such company, I cannot really use those libraries and my employer is probably not going to pay for such library, so my only option is to hold to v1 until we find a replacement (don't get me wrong, the # is reasonable, but it's just not in the culture to pay for open source libraries. And I can understand why they don't want to go there, on our main backend project, paying $600 per package we depend on would cost ~$100k and I'm sure it's far worse on frontend projects ^^)

Anyway, good luck and thanks for your open source work 🎉

[TristanWasTaken]

As many have already said, it should've been relicensed to LGPL-3.0 or MPL-2.0 because lgpl only enforces the copyleft clause for the library code* and mpl only for the file.
*The legal wording of lgpl's copyleft clause still makes it unusable for a few companies.

The license change to AGPL-3.0 makes this library unusable for any software that isn't licensed under AGPL-3.0 (ish) or doesn't want the final result of their code to be force-licensed as AGPL-3.0 because of the copyleft and network clause.
Yes, this also affects OSS.

If you care about your work not being abused by services and still being usable as, you know, a library, then you should've chosen a license like BUSL-1.1. OSS licensed code being comercially used (even when abused) is still in the spirit of truly "open" source.

The Business Source License (this document, or the “License”) is not an Open Source license. However, the Licensed Work will eventually be made available under an Open Source License, as stated in this License. This is a paramaterized license. The license parameters are: restrictions on usage, a change date, and the open source license that will govern usage of the software after the change date.

Saying that 2.x is OSS doesn't matter anyways when it's unusable for most users of 1.x. While not an OSS license, changing the license after 4 years to Apache-2.0 OR MIT or MPL-2.0 would still be more permissive than AGPL-3.0 ever will be for libraries.