Selling my own GPL software, part 1: a lot of hurdles
raymii.org
raymii.org
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!
It can be a psychological hurdle for people who hate and haven't accepted the concept of marketing.
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.
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).
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.
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)
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.
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.
>trend chase
>getting cash by any means necessary
>Market hard
I think you have a distorted view of the commercial software world. Of course you can find some bad apples but the majority just isn't like that.
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.
...for the users of the modified software, not everyone. If the only user is you, having the source code on your own machine is enough.
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.
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.
From direct experience, selling GPL code rarely works. And when it does, you know you're leaving a ton of money on the table (for no reason).
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).
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.
In this case, you can choose the license for your own binary distribution. And you can change the license if/when it becomes necessary.
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).
Thank you in advance.
> 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.
[0] https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f...
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.
[1] https://www.ipwatchdog.com/2017/02/07/facebook-oculus-zenima...
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?
We know that modified derived software can be sufficiently distinct from its base that the original copyright no longer applies. Quoting https://en.wikipedia.org/wiki/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.
If you have a patent then that protects your invention, even if I unknowingly and independently come up with the same invention.
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.
>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.
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.
Yes but who here wants to work in support?
On the other other hand, it means that there is a big incentive from the software's own developers to ensure that the software needs support.
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.
That said, it's still a terrible business model.
It reminds me of Newspaper websites these days. I think this is a statement about the current state of the web.
Look at the downloads of pro versions and tell me if they haven't found it sucessfull
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.
1. https://github.com/Codeux-Software/Textual#original-limechat...
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.
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.
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.
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.
Yup, I've become a "software hoarder" ;)
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
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 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.
Nice idea. Which data source do you use for that?
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?
Eh, I don't know where you've looked, but Stripe is one of the biggest around and you don't need a business bank account..