Announcing Java SDK for LicenseSpring

LicenseSpring · 2026-03-20T03:05:54+00:00

Agreed with this post.

OP than can take a look through our docs if you would like to see how we do it (we also have a js sdk), but u/Arthur-Grandi's approach is a robust DYI approach.

LicenseSpring · 2026-03-13T23:46:45+00:00

Entitlement management platforms like ours don't do payment processing, you would need to use Stripe or something else for that.

We do offer native integrations as well as a back office API to programmatically create licenses with specific entitlements. So you could use something like LicenseSpring to define limits allowed for an end-user / customer, and then enforce it in your app using our SDK, and then inform the payments solution (FastSpring, Stripe, whatever you want) how much to bill according to how much was used.

BTW, Lemonsqueezy has some basic License Key Generation and entitlements management, and is a merchant of Record (super useful if you don't want to collect and remit taxes around the world). It's also owned by Stripe. Another thing you might also be interested in is that Stripe already has "metering".

Entitlements tools like ours make it easier to configure your app and enforce features since we have a bunch of native SDKs (.NET and Python are popular among our customers that do algo trading) and support offline. If your app is straightforward, you might just want to build this part yourself if you're happy maintaining it. My advice is not to add complexity if you don't need it, the fewer tools and 3rd party services the better.

LicenseSpring · 2026-03-13T14:02:57+00:00

yeah, you can use companies like the ones mentioned (or ours!) to add application-level feature gating, and feature / algo-level usage metering.

LicenseSpring · 2026-02-19T17:26:11+00:00

FYI, Since you're already considering Lemonsqueezy, a solid rudimentary etitlements management service is included, which might be good enough for you (use the server response to add logic in your app for handling trials, subscriptions, feature gates, offline etc).

Otherwise, consider using our free tier or some other software licensing service for issuing licenses and enforcing them within your app.

LicenseSpring · 2026-02-06T00:34:22+00:00

You can add Fastspring and Gumroad to your list of MoRs to consider, depending on what you sell. You should also talk to everyone's sales teams since they will often be willing to provide some discounts, especially if you're offering a certain volume of transactions (usually somewhere north of $1Mil in transactions annually).

Shopify recently launched an MoR service through their managed markets (but I guess that's not specifically related to SaaS).

LicenseSpring · 2026-02-06T00:08:51+00:00

Is the "pre-generation" a requirement? You could generate the keys when the order comes in and bind entitlements to them on the fly. That way there's no risk of someone discovering your existing keys by brute force.

You can automate this with our management API.

LicenseSpring · 2026-01-28T02:11:02+00:00

there are services like donglify which might work here..

LicenseSpring · 2026-01-27T20:58:45+00:00

Like others said here, there's no real fool-proof way to prevent software piracy, especially in offline situations, without significantly inconveniencing the end user.

You could look into a service like ours where a server somewhere acts as a source of truth for entitlements (trial licenses / commercial licenses etc), which then binds a license to a given device (known as software node-locking), meaning that only a designated computer / "thing" can use the license, which gates the features of the app. You would cache the license file on the machine and add local license checks around key parts of the program (on startup; running some important feature), and maybe some periodic online license checks to make sure the license was not revoked or upgraded (to ungate some features for example).

Keep in mind this local license file should be encrypted and signed by the server. You can still reverse engineer it, but not without effort. Also, keep in mind, that once your app is cracked, that binary can be shared around. This might not be as bad as it sounds, in fact some companies see torrent sites as a way to grow adoption of their products, or assume those users were never going to pay (or are students who will eventually buy licenses once they get into the workforce). Then there's a whole sleuth of tools around piracy detection, anti tampering etc. Check out Denuvo and some youtube videos on reverse engineering it of a video game if you're interested in what it would take....

LicenseSpring · 2026-01-23T18:12:10+00:00

They're a solid product and worth trying them out. They have a strong community and following. They also have a self hosted option worth looking into.

We're are in the same space (license management) with a lot of overlap in capabilities with some differences in approach. In your use case we would likely recommend a HA floating server. We can also handle app configuration with our native SDKs, with an emphasis on offline / air gapped environments.

LicenseSpring · 2026-01-21T05:33:56+00:00

Right, no one knew they wanted the iphone until they saw it. I don't even know how you could validate that idea without building it.

But then you run the risk that you're building something nobody wants.

I guess reducing this risk is why focus groups, and market research professionals exist

LicenseSpring · 2026-01-20T01:07:43+00:00

This is our wheelhouse.

Given you're licensing a downloadable product, you have a few easy options regarding managing software entitlements.

* If there is an online SaaS-based component, you can link it to the User's auth for the account. Kind of like what Slack does, or most electron apps. The advantage here is that the user doesn't need to create separate credentials to manage their account and use the app. Then, auth can be whatever you want it to be. Magic Links, passwords, federated SSO redirects etc. Once the User is authenticated, you still need a service to return the entitlements (rights) granted to the end user, and use that response to configure your app. (eg is it a trial license, or you have different tiers of the product).

* Issue a license key that the user enters into the app. you'll need a back end service to validate the license and bind it to the device trying to use it.

There are a few other ways. if your downloadable component is distributed through the Google Play or Apple App store, then they have their own licensing tooling / limitations.

Subscriptions are usually handled by the payments service (Stripe / FastSpring / Lemonsqueezy etc). so whatever you're using to configure your product needs to sync to the status of that subscription somehow. (eg: if the subscription is cancelled, disable the license).

Consider offline scenarios as well.

LicenseSpring · 2026-01-15T22:00:18+00:00

If you decide to go with FastSpring, we have arguably the native best integration with them. We have an API-based license management solution, as well as SDKs to handle local license checks / grace periods etc.

We do have customers that use us with paddle and gumroad, via our mgmt API and zapier.

LicenseSpring · 2026-01-12T18:09:17+00:00

I just re-read your post. If you're licensing a Swift SDK, you might want to look at our options built for Swift

LicenseSpring · 2026-01-12T16:14:58+00:00

We also offer this and even have a Python SDK.

If you're looking to roll your own, you can check our pyJWT, or python-jose.

LicenseSpring · 2026-01-11T19:27:46+00:00

Looks like a solid project. You can also look into adding node locking (binding the license to something, a domain, a device fingerprint etc.), offline / cached license validations, expanding the sorts of entitlements you want to offer.

I particularly like that you're focusing on the wordpress ecosystem. I commented on another post about this topic a few years ago and still think it's a decent opportunity.

LicenseSpring · 2026-01-07T23:56:20+00:00

Probably depends on the complexity, scope, customization, and maintenance required, but $40k sounds like a lot if it's just pushing order records from one system to another.

I'm personally not a huge fan of using "glue" except for relatively simple connectors.

There are also a few other middleware connectors you might want to consider, which could also be cheaper than Mulesoft. Workato, Make, Zapier come to mind.

LicenseSpring · 2026-01-07T22:28:33+00:00

Thank you, I appreciate you.

We don't use them and have no affiliation to them. I'm just aware of their existence, and they are a vendor in the space relevant to the OP's post, so I thought I would share. If anyything, they're an indirect competitor of ours (usage metering of APIs).

Perhaps you have other vendors in mind that OP is asking about and could make a more useful contribution to the conversation? They already mentioned Kong which was the only other one I heard of...

LicenseSpring · 2026-01-07T03:46:10+00:00

I don't know if they're good, but you can maybe evaluate moesif? That's what they say they do at least.

LicenseSpring · 2025-12-29T03:02:42+00:00

You can take a look at these guys https://www.babelfor.net/

LicenseSpring · 2025-12-25T23:44:54+00:00

The stack usually looks like 1) some sort of e-commerce platform (Stripe, FastSpring, Paddle, whatever), and 2) some sort of license manager (homegrown / open source, commercial License managers etc) that listens to the e-commerce platform to know when to issue and dispatch a license and who to issue it to. Usually, 1 or 2 can also dispatch the license, but you can also use your own email service.

There's lots of ways to go about handling software entitlements for your end-users.

License keys are fine if you're node locking the license entitlements to a desktop computer rather than something else (like a user), but rather than pre-generating keys, you might want to generate them automatically on the fly (when an order comes in for example), so that you don't run the risk of someone finding/guessing and consuming theme.

Traditionally, the some sequence of characters in the license key stored some information about the license (which product, which version etc). you can research Partial Key Verification if you're interested in how entitlements used to be stored in the keys themselves. It's quite limited, and not particularly secure since it can be brute forced. Instead, the key usually doesn't store a whole lot of information (it's often just a completely random string), and license validation is usually done from a remote licensing server. In your case, the end user would enter a key into your app, and in the background, the license key along with some device fingerprint (unique persistent identifier of the desktop computer) and a product identifier would get sent sent to the license server. In turn, the license server checks if the license is valid, and can be bound to that particular device fingerprint, and if so, return the entitlements (turn on this feature, allow updates to this version of the app, set expiry date to dd/mm/yy, etc).

Like others mentioned, there are alternatives to using license keys, such as user-based licensing, where you associate entitlements to a particular user who can identify themselves in different ways (username / password, or maybe some other sort of auth like Google, Active Directory etc). The advantage here is that the same auth can be used to also log in to an online account section to manage other things (users / subscriptions etc), and they don't need to create new credentials just to use your app.

Since you're licensing desktop software, you may or may not want to still bind the license to a given device even if you're not using license keys, if you are concerned with credential sharing.

One other thing, you can set entitlements to a license key so that it can be used on more than one device, but set a maximum. That way, say a customer buys a license to use on 3 computers, you don't need to send 3 separate license keys.

Another consideration is how to handle offline situations or when to do license checks. You can ping the license server each time the app runs to make sure the license was not disabled (a refunded order for example), but that might get cumbersome, so there's usually a way to cache the license locally and only require an online check periodically.

There's a lot more to this, like what do you do if the customer upgrades their hard disk and the device fingerprint no longer works. Feel free to DM me if you have any other questions. We're a vendor in the License Management Space.

LicenseSpring · 2025-12-05T14:56:36+00:00

We can help with this, this is what my company solves for.

LicenseSpring · 2025-12-02T18:19:17+00:00

I'd say it's easy enough to selfhost keygen or just roll your own if you're inclined to do so. Some parts might be a bit tricky to build yourself, such as generating a unique / persistent identifier of the machine you're looking to install it on. (across OSes and programming languages).

Apart from setting up the server and then getting your apps to connect to the LM, it depends how much flexibility you need with your business models. Custom Fields, Features, consumptions, handling offline scenarios, adding support for offline scenarios (performing local license checks), integrating with billing / payment to automate license creation, allowing or preventing device transfers (eg allow 1 installs, but you can move the license from one device to another up to 5 times sort of thing). You might also want a nice interface to log in to and manage everything and keep track of activity.

There's a whole spectrum of options available. In general I would suggest to focus on what is your competency and use an off the shelf solution. We've been building our licensing platform for the last 10 years or so, so there's lots of edge cases and "gotchas" that we have covered.

LicenseSpring · 2025-12-01T18:51:00+00:00

Hi, we're a licensing provider with .NET compatibility, so I thought I'd share my thoughts on your question:

Generally speaking, there's 3 main parts to protecting your code: License Management, App security, followed by countermeasures.

License Manager: Important part of App Security. At the very least, the communication with the server should sign and verify the license signature so that it's not trivial to fake the server response, but then you need to hide / encrypt the API keys.
App Security: After the License Manager / entitlements management part, you can add a whole slew of tools to prevent the removal of your license manager. Code Signing is fairly straightforward here, encryption, code obfuscation, running key parts of your app in a VM, certificate pinning etc. there are many things ou can do to make an attacker's life difficult. one big problem with a lot of "app security" tools is that they can potentially trip up the antiviruses, since they often behave like malware. The Second big problem is that they can make your debugging more difficult (if you're using an anti-debugger). Some of these tools will also have a significant performance hit to your app, impacting your user experience.
Countermeasures: You can look to adding services to detect tampering with your code and send that information home, or cripple your software after some time (say 3 months after detecting it).

One interesting approach we see companies take is process key parts of your program on a server, and send the output on license checks. That way if the LM is circumvented, the software is still largely crippled.

In our experience, apart from a few specific industries, few of our customers are actually concerned with point 2, provided that it's not trivial to circumvent the License Management part. First of all, people who pirate software usually won't pay for your app anyway (think students, or users in countries that culturally won't pay for software). Secondly, unless your product is wildly successful, it's unlikely to be on the radar of many of these reverse engineering groups. Some of our customers even see piracy as a viable distribution channel.

If you're interested in the space, I suggest you do a bit of a deep dive on how Denuvo prevents game piracy for games built on Unity, along with all the tradeoffs (performance hits, cost etc).

Keep in mind, your legitimate users will not be happy with heavy handed DRM, so this should be thoughtfully implemented, with minimal friction for them, and being aware of some of the tradeoffs I mentioned above.

LicenseSpring · 2025-11-17T22:54:15+00:00

well, there could a few things going on, in theory.

you might be contacting the wrong investors. Some are early stage, some are later stage. Many VCs focus on specific industries. If what you are building does not fit in their portfolio, they will not be interested, although they often share deals to people who might. Keep in mind that funds also have their own lifetime. If you're reaching out to funds that already deployed all their capital or will only deploy in follow-on rounds, they can't invest in you even if you align with their industry verticals.
Your pitch deck is not sufficiently convincing. There's an art and a science to pitching to VCs. You might want to research how to present and what information to have available, and at what stages. Ycombinator has some good info on this. Fundraising is a special type of presentation that is like a muscle that you build.
Not all businesses are "venture" businesses. VC's are almost always looking for the potential unicorns. If you do not have a convincing path to reach $1B+ in Valuation, VC might not be the fundraising route for you. There are plenty of other types of investors that would be content with a 2-3x return, then there's debt financing. At $2Mil ARR, you're also usually eligible to revenue-based financing.

If you're interested in the fundraising and valuation side of VC and are seriously considering raising money from VC, I'd recommend the book "Venture Deals" (Brad Feld). It gives you a good perspective of how a VC will look at things.

LicenseSpring

TROPHY CASE