I run a pretty decently-sized OSHW project that sells both b2b and b2c, and the biggest hurdle I can see is that this guy really likes making hurdles for himself.
Literally every single one of the "business hurdles" can be either trivially solved or ignored completely.
Payment processing takes 5 minutes to set up through PayPal or Stripe, and invoices can be generated manually for the few customers that actually ask for them through free online software like this:
https://invoice-generator.com/
The rest literally don't matter at all, at least not until you're selling >$1k worth of software a month. I don't mean just practically, I mean legally, at least under Australian law. If things are significantly different in the UK or NL, I'd be very surprised!
(I wouldn't call "Marketing" a hurdle either - it as much work as writing the software and requires as much skill!)
Of the technical hurdles, the only one that is an actual that needs to be solved in order to release an MVP is "Website with payment processor and downloads". Set up a $5 Wordpress droplet on DigitalOcean, install WooCommerce and spend an afternoon customising things. Go Shopify and eat the comission if you want to make things even easier. The rest can come later, once you've validated that a market for your product exists at all!
Agreed with all your points, but to be fair, when starting on this it can easily feel as a burden, at least it did for me. I also sense some insecurity, which is a very human trait. And not in the least, it can be good to understand where you are starting with, including all the details, even though it might drive down motivation knowing all the details :) I prefer stepping in naively and figuring things out later on :)
1. In my experience, he wouldn't need to start a company right away, only when it really takes of. In the context of income tax in the Netherlands, there is a grey area between hobby and commercial activity, which is not easily defined. Only when it starts to structurally be part of his income, does he need to write it on his income tax papers and register a company. That won't be needed when he is only taking off. (Try or try not, there is no do (Yodi) ).
2. In regards to setting up a registered company, you do get lots of sollicitors at the door and on the telephone. He already mentioned the prepaid phone, not sure if a postbox is possible and what it costs. But for now, it is not needed, see point 1. (edit: the KvK doesn't allow a postbox as address, but there are companies that offer using an address of their business centre for around 500 Euro a year).
3. Setting up a website with WooCommerce or Easy Digital Downloads is easy peasy. At first I didn't go this route, expecting this would be burdersome. I used a marketplace which took 30% of my sales, in practice even a bit more. Two years later I started to get unhappy with that (their support was awful) and switched to WordPress/EDD with just PayPal payments and it has been just great. I should have done that right away from the start. To be fair, my marketing is already taken care of because of a free/gratis main software package.
> The rest literally don't matter at all, at least not until you're selling >$1k worth of software a month. I don't mean just practically, I mean legally, at least under Australian law. If things are significantly different in the UK or NL, I'd be very surprised!
At least if you are in Germany you need to have a business incorporated when you want to sell to customers or businesses. You need to have a tax number/ID.and you need to provide not only an invoice, but in case of software also updates (at least from next year on, if you not have the customer explizitly opts out).
> At least if you are in Germany you need to have a business incorporated when you want to sell to customers or businesses.
No. You can act as a GbR. It’s a good idea to incorporate a limited liability company to shield your personal property from liability, but it’s not a requirement. If you do, a UG mbH will do just fine and is simple to set up, but requires proper bookkeeping.
You need to register for tax and at the Gewerbeamt likely (depends, ask a tax accountant about your specific case) but both are trivial. You do need to provide an invoice, but there are tons of options to make that simple - a word template may be sufficient.
A single person can't found a GbR. For that you need at least two people. And yes it is trivially easy to register for it. Also taxes are not too difficult.
> I don't mean just practically, I mean legally, at least under Australian law. If things are significantly different in the UK or NL, I'd be very surprised!
glad to see aussies here! however do know that the bureocracy in europe (EU and friends) and rules for small business operations are indeed significantly different (many more compliance requirements) than in australia. one thing that aussies will often find surprising are the compulsory monthly costs for running you own business (let alone a company)
European law is unfortunately very unfriendly to small businesses. For example, sending a correct invoice is a requirement, and you have to store them for at least 5 years. That can be done only if you have set up a corporation or self-employment and have obtained all the necessary identification numbers. Fortunately Stripe made things much easier, but still - beginning to process cards is lengthy. Paypal in Europe takes a very big commision and they will block your account and ask for the same lengthy card processing process after you make few thousands in sales. Taxes are hard to file yourself even if you do only local sales, and becomes impossible to manage yourself once you sell out of EU.
I’m selling an AGPL licensed app that allows to access IMAP/SMTP accounts over REST (https://emailengine.app). At first I sold it in a way where AGPL version was completely free and public, but you could pay to get the same thing with a MIT-license. Turned out that no-one cared about the license, everyone was happy to use the free AGPL thing, so I changed it in a way where the app is dual licensed under AGPL and proprietary license and you need a “license key” to fully unlock it. As it’s AGPL with source code available from Github you can freely remove that license key check, just a 1-line change. It’s still a big enough of a hurdle that I’ve actually gotten some customers.
I've been obsessed with those kinds of strategies for (A)GPL software lately. If it's true, like the critics say, that customers like locked-down, dumbed-down software, there's no reason we can't do that with GPL stuff - even though it can be easily bypassed in then source, and other distributors can sell clean versions, plenty won't.
GPL software should use the same predatory tactics as proprietary, and trend chase. Focus primarily on trend-chasing and marketing, focus on getting cash by any means necessary other than not making the source available. Market hard, dual license.
Dropping a license check in (as long as it's not obfuscated or intentionally confusing) is very cool in my opinion, and I wish you luck. Thanks for adding to the commons.
> GPL software should use the same predatory tactics as proprietary, and trend chase. Focus primarily on trend-chasing and marketing, focus on getting cash by any means necessary other than not making the source available. Market hard, dual license.
I'd rewrite this as "People who want to make money from GPL software should ...", because GPL software in general doesn't have to have a commercial goal.
Yes, it's AGPL with source code publicly available, but if you remove that license key check yourself, you have to make it public, effectively broadcasting that you don't pay for software. In a way, it's naming and shaming. The alternative is using the fork of someone else who has done so and complied with the license, but then you're suddenly dependent on some random downstream and who knows what else they have mixed or might mix into it or just give up merging from upstream eventually.
I wanted to integrate your project in another open source project that I was contemplating of working on. However, the licensing bit made me think twice about that. While I could see that under the terms of GPL I could easily remove the code that checks for the license, and that the code was not hidden or obfuscated in any way, but at the same time it just felt against the spirit of the project to do so for anything other than purely personal use. Hence I am evaluating other projects for my use case.
I think this approach of dual licensing is well suited when the intent is to let people audit source code freely for evaluation or personal use purposes, but then pay up when they wish to use it in their public/commercial projects.
How did you setup your contributor license agreement (assuming you have one in order to incorporate external contributions that you want to dual license). Just a GitHub PR template where they have to check a box to confirm they agree ?
I'm in a fortunate enough position that the day job pays the bills and I enjoy it, such that I don't need income from my open source efforts.
However, about a year ago I did two things:
- Enabled sponsorship through GitHub and Liberapay.
- Put my GPL apps (freely available on FDroid) on GPlay for $1.
Since then, I've made a fun amount of ~$300 in little donations (a combination of one off and recurring sponsorships). Although a tiny amount of income in the scheme of things, it is still thrilling each time someone kicks a small donation my way even though there is no obligation to do so. Itis a nice pat on the back for things I do for free anyway.
Also, given that I do zero self promotion and very minimal nagging (just in some of my release notes), and given I spend probably less than a total 7hrs a week on all of my projects combined, it makes me think that this could be ramped up if I was to dedicate more time to it.
Some things I try to do with each project to help gain traction:
- Release often, so it appears at the top of the FDroid front page regularly.
- Take i18n seriously so that people around the world can benefit from the apps.
- Foster a sense of community and inclusion in any discussions (e.g. GitHub issues and PRs).
I also try to add new apps whenever a new idea comes along. Hopefully a large diverse range of apps will find use with more people.
Hopefully in the future that $300 will grow to $500, $1000, or even more.
The author says "I'm a firm believer in free software."
I interpret that as someone who has a firm belief that proprietary software is immoral, or at the very least, distasteful.
That would include being opposed to the proprietary add-ons of an open core.
And that would be a reason to leave money on the table. (Analogously , I have a relative who owned a grocery store and refused to sell tobacco products, believing that doing so was immoral.)
In general, I think open core is an advertising model. In broad strokes: "Free software" uses a moral argument against proprietary software. "Open source" uses a cost/benefits argument that open source development is more effective than proprietary. "Open Core" uses the profits from proprietary add-ons to subsidize the open source component, which is the loss-leader marketing the proprietary add-ons.
One model that's worked for me, at least for desktop software, is to release an AGPLv3 core and minimum version that works on Linux, and charge for Windows and macOS versions that are proprietary.
If you go the route of using an (A)GPL core, make sure all 3rd party contributions are made under the terms of your CLA, or otherwise reject them.
> If you go the route of using an (A)GPL core, make sure all 3rd party contributions are made under the terms of your CLA, or otherwise reject them.
If someone goes down this route, does the rejection have to be automatic? Does looking at a pull request without a CLA "taint" me in a way that I cannot implement it again? I am asking partly because I am curious and partly because I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe).
These are things I never worry about at work. I can look at stack overflow and copy x.filter(x => x.blabla...) and change the bla bla until my javascript works (I don't use filter every day so it is difficult to remember this syntax in my head).
Your comment intrigued me so I did a slight bit of digging.
> I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe).
The repository is indeed archived, but is still available on GitHub. It was changed in 2015 [0]. The older notice is as you recall:
> Pull requests will be rejected from authors who have read any decompiled official Minecraft code.
The current notice [1] adds some other ways the formerly rejected developers could get involved:
> If you are a developer, you have two paths. If you have not read the Minecraft source code, you are what we call a "clean dev", and you should stay that way. If you have read the source code, you are what we call a "dirty dev", and the way you can contribute is different. If you are a clean dev, you're welcome to contribute to this repository by adding features and functionality from Minecraft Beta 1.7.3, fixing bugs, refactoring, etc - the usual. Send pull requests with your work.
> If you are a dirty dev, you are more limited in how you can help. You can work on projects that are related to TrueCraft, but not on TrueCraft itself. Direct contributions that you can participate in includes the website and the artwork. You can also work on things like helping to build a community by spreading the word, participating in IRC or the subreddit, etc. You may also work on reverse engineering Minecraft to provide documentation for clean devs to use - see reverse engineering guidelines on the wiki for details on how you can do this. Under no circumstances may you ever share any code with a clean dev, decompiled or otherwise.
> Does looking at a pull request without a CLA "taint" me in a way that I cannot implement it again?
I'm not a lawyer, but I'm under the impression that if someone wants to sue you for IP infringement over something like this, they can. Doesn't mean they'll win, but that can still cost you time and money defending yourself.
If you do look at the code, I'd make sure your implementation is far from how the contribution was implemented.
Here's what IP Watchdog says[1]:
> Copyrights cover the actual “expression” of an idea, but not the idea itself. In other words, it covers the lines of code but not the functions that they perform. The functions can be protected as trade secrets, or they can be patented. Sometimes it’s difficult for someone unfamiliar with IP law to separate the functionality from the expression in source code. This so-called “dichotomy between idea and expression” is particularly confusing with respect to software, and was addressed in the case Whelan Associates v. Jaslow Dental Laboratory and then again in Computer Associates v. Altai.
The article[1] then expounds upon literal and nonliteral copying and how it applies to source code.
There's an idea in some software communities that you can't "unsee" code. So if you've seen the code even once, you're "tainted" and you can't be permitted to work on the clean room implementation anymore. This tends to be used most often in projects attempting clean room implementations of proprietary software where they want to maintain clear provenance of the code.
The question is, is this based on actual case law or is it just an extreme form of paranoia?
It's not an extreme form of paranoia. I see it as a cost-analysis. It's cheaper to defend any copyright infringement criticism or lawsuit when using a pure clean room design.
> In NEC Corp. v Intel Corp. (1990), NEC sought declaratory judgment against Intel's charges that NEC's engineers simply copied the microcode of the 8086 processor in their NEC V20 clone. A US judge ruled that while the early, internal revisions of NEC's microcode were indeed a copyright violation, the later one, which actually went into NEC's product, although derived from the former, were sufficiently different from the Intel microcode it could be considered free of copyright violations.
However, such a lawsuit will be much harder and therefore more expensive to deal with.
It's much cheaper to make the argument that none of the developers had access to the original source or reversed-engineered design, so any similarities must be result of functional constraints or general knowledge.
Honest question (I am totally ignorant about these things): If you did this, would you be able to accept patches from the community on the open core? Or would releasing your proprietary code violate the GPL of the coder who sent the patch?
I would say that it depends on how the core and addons are attached and how the core is licensed.
If the core is a library, and licensed under LGPL, the proprietary add ons can dynamically link to it without issue. You could take community contributions. This would not be true if the library was GPL. Anything that links to GPL has to be GPL compatible (make source code available).
If the proprietary addons are libraries and the core links to the addons, the users could violate the GPL when they link to them, unless you as the original author of the core, specifically enumerate the addons in the license you distribute to them. You would not be able to take community contributions in this case.
If the core communicates to the addons without adding the addons to its assessable region, such as talking over pipes or sockets, you would have no licensing issues even if the core is GPL and has taken community contributions.
I’m not familiar with how that works. Would you ask contributors to give you a traditional copyright license to their code (world wide, royalty free, non-expiring, right to redistribute, modify and sub license)?
You'd only accept contributions under a CLA that assigns copyright to you or your company, allowing you to distribute the code and its derivatives in any manner, and under any license, you want.
Only to yourself with all rights reserved to yourself, too.
You then transfer the license to an oversea entity that then licenses back to your majority owned company.
This is the professional business with software licenses as there is no physical good to ship, it is in principle a good way to transfer money accepted as a common business transaction (paying licensing fees), supported by tax laws for international trade (e.g. often various tax exemptions).
> Consider sponsoring me on Github. It means the world to me if you show your appreciation and you'll help pay the server costs.
>You can also sponsor me by getting a Digital Ocean VPS. With this referral link you'll get $100 credit for 60 days.
Asking people for money right at the top and putting referral links to help pay for server costs does not generate much confidence that selling GPL software is a viable business model.
Selling GPL software is objectively a terrible business model. If the entire proposition behind buying your software is "it'd be a pain to build this myself so I'll pay someone to compile the binary then give it to me", the only thing I can infer is that you have an unnecessarily painful build process.
Supporting GPL software, on the other hand, can be very viable. Another good option is licensing data to be interpreted/rendered/whatever by your GPL software.
End of the day, people don't buy software. They buy solutions to business problems. If the business problem can be solved for free by building the FOSS software yourself, there's no reason to pay the creator. On the other hand, if the creator sells "I will solve X business problem for you, this is an example of some of the FOSS software I will use to do so, but in the event this software is unable to properly solve the problem I will take whatever steps are needed to ensure it is solved to your satisfaction", it makes darn good sense to pay that creator to solve that problem.
Your example proposition assumes the source code is available at no cost from the developer, which isn't necessarily the case.
It's true that nearly all GPL'ed (and FOSS) software is available for download at no cost. But there's nothing in a FOSS license which requires a vendor to have a no-cost distribution mechanism.
The "Selling Free Software" sales proposition is that you can pay to get the GPL'ed software directly from the developer, or find an existing customer willing to distribute it to you for free, or at a lower cost. The latter step may also require additional diligence as now you have two vendors in your supply chain.
Patronage is like the new normal for supporting people creating things online. My only rub is I don't need a VPS and I'm sure as heck not going to support anyone through a Microsoft-owned venture. Payments don't need to be tied to corporations but a lot of people hate crypto (and the exchanges take a substantial cut). At least Liberapay is open, low-fees, not trying to be a loss-leader start-up, and not trying to be a social network.
On an unrelated note: I accidentally opened the OP in another browser where I don't have uOrigin and PrivacyBadger etc. installed and it's so full of ads one can barely read the article. Why would anyone put that many ads on their personal blog?
Cool. I suspect this model will mostly work, but only if the price of the app is low enough to not justify a lot of inconvenience by compiling it yourself or maybe getting it from f-droid. I like this model a lot, apps like OsmAnd do the same.
It’s tempting to think you can price GPL software at some “sweet spot” where customers think it’s worth it and you recoup your development costs. But then someone who hasn’t incurred your development costs can undercut you, even while offering the same or better service.
At least with AGPL software, if this happens, it will force those competitors to release their secret sauce, too. Those competitors will have to open source all of their changes, meanwhile as the copyright holder, you're able to release proprietary modules or changes at any time, and those competitors are out of luck if they want to use them. Should they attempt to compete on feature parity, their additions will need to open source.
In this case, we are talking about client side software. It runs locally on the device. This means that the distinction between the GPL and the AGPL is not really relevant. And any competitor preparing modified binaries would also need to release their source.
Go and look at simple mobile tools. This person is selling Foss apps on google play store pro version but pro version is also on f droid for free and github.
Look at the downloads of pro versions and tell me if they haven't found it sucessfull
> People have asked me what I think of the fact that other people can then also redistribute the source code, or compile a binary and provide that for free. I'm fine with that, as said, I'm a firm believer in open source / free software.
What??? They’ve admitted to a flaw in their method to get income, which is that they’re making it trivial for competitors to offer the same product. Their response is that they’re a believer.
I would have appreciated a response like dual licensing, or going into consulting for their app, or using trademark to enforce ownership over their version.
It makes sense if you see it as a hierarchy of priorities:
First priority: Believe in making open source / free software where other people can exercise the associated freedoms.
Second priority: Want to make income, it's difficult or impossible, but whatever methods are searched for to overcome those difficulties, the income goal is still secondary to the first priority. Dual licensing and trademark might both be rejected on that basis. Consulting would be fine.
That makes sense, but it’s not a complete answer because to accomplish priority #2 the author has to go through additional work, such as applying for a business license, getting a domain name for their business, getting a pre-paid cell phone, and having their home address listed publicly. This risks receiving business solicitations at his home address.
If you have the first priority, why go through the trouble of the second priority? What I’d like to see is a plausible theory of monetization that accounts for the possibility of competitors redistributing his code. There may be one, but I don’t see it.
As someone who tried the same approach, I think I can help.
I sold software to pharmaceutical R&D groups. As a supporter and author of free and open source software, I wanted to see if I could apply the ideas from "Selling Free Software".
Pharma companies are tight-lipped. Researchers often have to submit their talks for legal review before presenting it in public. I've hear that developers at some pharmas also need to submit patches for legal review before sending them upstream.
Few pharmas distribute in-house software, which 1) they consider it a proprietary advantage over their competitors, and 2) like most in-house software, has a low level of documentation and testing, with the expectation that the authors and maintainers are directly available.
Pharma companies also have the money to pay for software, and internal developers who are able to do some maintenance if needed.
Finally, about 15 years ago, a company in my field decided to triple the price of its software (the owner was no longer really interested in producing software). This was deeply embedded in many projects. It took one company about 2 years to migrate to a competitor. So the owner made 6 years of revenue in two ... and made pharmas a bit more cautious about their licensing. This strategy isn't possible with FOSS licenses, which I think would make an advantage in sales.
(This is not specific to FOSS licenses. My current proprietary licenses also allow in-house support, no time limit, no limit on the number of CPUs, and no restrictions on where those machines are located.)
So my "theory of monetization" is that 500 pharmas and biotechs were willing to pay $25K for a top-of-the-line niche product which took about $300K of engineering time, and that I would get 50 or so customers before the source would be distributed to possible competitors. 50*25000 = $1.25M > $300K.
Plus, it would take time (and money) for possible competitors to get up to speed with understanding how the product works. And they also couldn't make much money from it as I could always lower my prices, once I made back the engineering costs.
Things I didn't factor in were:
1) I'm lousy at marketing (never got 50 customers)
2) Commercial vendors entered this space, with independently developed products (driving down the sales price)
3) People don't want to buy a $25K product without being able to demo it, and if I insist on only FOSS distributions (or components I use require it), I can't provide evaluation-use-only licenses.
4) Academics are an important user base as they publish papers (advertising) and their students go on to work at pharmas. My theory of monetization meant I couldn't sell to them as they expect no-cost or highly-discounted licenses, while being the most likely to put a FOSS component.
As a result, I gave up, and now offer various levels of proprietary licenses for the source distribution, plus pre-built binaries for general base use, and a license key to unlock additional features.
Textual is a good example of this working IRL for me. Their app is one of the best IMO IRC clients on MacOS, is open source [1] and is also sold on the App store and their site.
So in the case of Textual, it’s a convenience for the user to download from the App Store than to clone and compile and get through code signing. If I’m broke, have a MacBook, and know how to build and modify a project, I can get textual for free, which is a nice option to have. On platforms with app stores I can see this being viable for developers.
I am aware of VLC being removed from the iOS App Store years ago because the license agreement for the App Store said that developers had to have sole control over the source code. I’m wondering if this requirement was removed, which would allow Textual to exist on the platform with its licensing.
I can see licensing an open source project, for profit, as BSD being riskier than GPL because I could take their project, add my own additions, publish the product on the App Store (under a different name and branding) and never release the source code. At least with GPL, I would be required to share my modified versions of the source code with users of the product, which could be reintegrated into Textual.
Pixen was the opposite. It was open source and sold on the App Store but then people just took the code and put their own low effort Pixen-likes on the App Store. No more OSS Pixen.
The idea behind licensing as GPL is that you offer support, subscription, or relicensing. The problem I see is his target niche is crowded already, not that he's using GPL. Using AGPL would be better because you work around hosted services.
If Paul Davis is around, I'd be interesting in hearing their take on the subject given their experience with Ardour (which is open-source GPL, but official binaries cost money). As far as I know, Ardour has done this for at least a decade, so I assume it's been reasonably successful.
Edit: it occurs to me that Paul is probably asked about this frequently, and maybe has already said some words about this, so any relevant links would be useful too
He's around though! No particularly good links, and your summary almost says it all anyway.
When I started working on Ardour, I didn't need to make any money from it. By 2009, it started to seem clear that I did, and fortunately Radiohead had just released "In Rainbows" using their "pay tunnel" approach (can't get it unless you pay but what you pay is up to you). I wasn't a Radiohead fan but I thought there was something interesting in the idea.
Ardour has remained GPL (v2+) licensed, so the current situation is this:
* you can get the source without charge (github or our own tarball)
* if you want a prebuilt binary, we ask you to pay something (any amount above US$1)
We set the "default" price (the one in the price box, that can be edited) based on your IP address and OECD data about the cost of a mid-priced meal for 2 without alcohol in (roughly) your (apparent) location.
We also added subscriptions, not like Adobe etc., but just regular periodic payments, mostly because they help smooth out the income flow between releases. They are available at the US$1, 4 and 10 per month, to try to cater to the wide variety of incomes worldwide. There's a huge churn in Windows-based subscribers (e.g. 10 cancellations a day, 10 new ones). You get free upgrades as long as your subscription is active (and obviously for a GPL project, there are no other consequences to it ending - the software keeps working as ever). We have on the order of 6000 subscribers these days (with the aforementioned high rate of churn).
Linux distributions are obviously free to distribute it as they wish. There are one or two resellers on ebay etc. also, who I just try to ignore.
During COVID our total monthly revenue grew as high as US$20k/month, and have settled back to about US$17k/month. The income is divided between two full time developers (I'm one of them) and we've built an "escrow" account of more than US$60k over the last two years. Some of this currently being used to pay someone I discovered on HN to rebuild our website, and we hope to pay for more development work next year.
AFAIK, we are one of the most successful "user-funded" GPL projects in the world. Blender has way more revenue, but AFAICT, most of it is not from users.
> We set the "default" price (the one in the price box, that can be edited) based on your IP address and OECD data about the cost of a mid-priced meal for 2 without alcohol in (roughly) your (apparent) location.
I think Krita (a painting app) does something very similar. Source is freely available under the GPL, but they sell binaries on the windows and macos app stores. It's not a photoshop sized business, but apparently pays for a couple full time developers.
This article highlights the contortions developers go through when trying to "sell" their open source product. The GPL family of open source licences let you charge for the distribution of the source code.
The oft-repeated suggestion of selling support for your open source product is probably the least attractive option to solo developers or small teams.
An alternative is the 'source only' option. It's not open source but it gives your customers the ability to adapt the source code to their circumstances.
If you are creating a B2B product (i.e. selling to profit-making businesses), the 'source only' option let's you do the one thing GPL licences forbid: charge for the source code.
For some open source advocates the term 'source only' is a dirty word. It's up to you to decide whether it suits your product.
I posted an 'Ask HN' question on this topic the other day:
Ask HN: What are you thoughts on 'source only' software products?
Literally every single one of the "business hurdles" can be either trivially solved or ignored completely. Payment processing takes 5 minutes to set up through PayPal or Stripe, and invoices can be generated manually for the few customers that actually ask for them through free online software like this: https://invoice-generator.com/
The rest literally don't matter at all, at least not until you're selling >$1k worth of software a month. I don't mean just practically, I mean legally, at least under Australian law. If things are significantly different in the UK or NL, I'd be very surprised!
(I wouldn't call "Marketing" a hurdle either - it as much work as writing the software and requires as much skill!)
Of the technical hurdles, the only one that is an actual that needs to be solved in order to release an MVP is "Website with payment processor and downloads". Set up a $5 Wordpress droplet on DigitalOcean, install WooCommerce and spend an afternoon customising things. Go Shopify and eat the comission if you want to make things even easier. The rest can come later, once you've validated that a market for your product exists at all!