Does anyone genuinely make their choices for what product to use based on if its source is available?
I don't want to read the source code, I want to use the product. If there is a bug, I want you to fix it. If you don't fix it, why am I paying you / using it? Assuming I am a programmer (many users aren't) and make my own patch, and you don't merge it, I'm still screwed. Source only helps me if I'm the one running the code. So the fact that your SaaS is source available has no bearing on my use of it.
Lots of businesses have agreements with vendors to keep the source code in escrow, in order for the business to be able to ensure continuity if the vendor goes out of business or abandons the product.
> We hereby irrevocably grant you an additional license to use the Software under the Apache License, Version 2.0 that is effective on the second anniversary of the date we make the Software available.
This is one of the reasons I personally went fair source/source-available. I was already sharing my code with my biggest customers via escrow, so I thought I'd just simplify and share with everybody and give everyone the same benefits i.r.t. continuity and longevity.
They can either maintain it themselves, or let another party do it for them, indeed. The contracts specify under which circumstances the code can be released, but usually it's going out of business or cancelling a product.
It's something we had to deal with in a previous job where we (as a small company) sold products to Global 500 companies. Either we agreed to this, or there would be no deal. Every time we released a new version to those clients, we would place the updated source code (along with documentation and tooling etc) in escrow.
When I've done it in the past, it was a vaguely tech-savvy law firm (the hard part isn't really the storage, it's the "evaluate the conditions of the escrow contract release terms".) (IIRC recommended by the customer but we had some independent validation - I think one of our VC's law firms had dealt with them before?)
We also had to details on how to actually build the product from the source, though I think they mostly just trusted us on that as long as we supplied a separate document - and by trusted, there were penalties spelled out in the contract about that too. (We were in good shape releng-wise but I expect a lot of companies would have to clean up their act to actually comply with that part.)
Those release terms are interesting to think about. I’m wondering how to spell out in a contract the difference between selling your company to a firm which will maintain the software well vs selling it to someone who will ruin it and/or do the most bare minimum? How can one draw the line?
Escrow in general refers to a third party acting as an intermediary trusted by both parties. This works for source code, but also for money, goods, or anything else. Say if I want to buy a large diamond from you, you hand it over to the trusted escrow service, I give them a big pile of money. Once they have the money, they give me the diamond, and then give you the money.
Only in the case of source code, I give them the code, and they won't give it to you until I go out of business. They get paid for that, of course. In our case, we uploaded source code an escrow service's servers.
Source available can be helpful if you want a local dev setup or testing environment.
>Source only helps me if I'm the one running the code
Many times I've gotten better support when I open a Github issue and send the link to support--usually I can get around all the canned troubleshooting steps and get to an engineer quicker.
>So the fact that your SaaS is source available has no bearing on my use of it
You can tell if the product is garbage before you pay for it (does this place review changes, do they have automated tests??)
imo it's still helpful although small. If you're looking to run it yourself, sometimes source available can quickly be ruled out--especially if your company reviews and tracks license terms and doesn't want the headache of something custom/complicated
If you're a large commercial software house, with $$$$$ of revenue riding on things working/being able to develop features quickly the usual "contact support, tell them about issue, wait for fix" flow can cost you a lot of time and money.
Even large businesses that don't produce software as a product often have internal dev teams that customize third party software to their needs (at least in the particular vertical that I'm involved in).
It's immaterial in these cases whether the code is properly open source or not, but being able to go in yourself and fix minor bugs that are blocking you in hours/days rather than the weeks/months it might take the vendor to get back with a fix is practically a hard requirement for any dependencies that are core to your business.
I'm not an OSS zealot but when there are many options available all of similar quality, or I don't care about advanced features, I almost always pick the OSS alternative. e.g. music players, pdf readers, note taking software, etc.
In this case since it's more of a SaaS I don't know if I would make that choice, I'm not familiar with billing software however not being 3rd party dependent and knowing you could self-host later if needed sounds useful.
I think a big value prop is that it reduces vendor lock-in, especially when depending on a new company. If the company fails, you can self-host and even fork. You can also choose to self-host for compliance reasons if your sector doesn't jive well with multi-tenant SaaS.
Yeah. Part of why I picked Kong at a previous job was that it was modifiable and open-source, and the enterprise plugins were modifiable and source-available. It allowed us to deploy custom versions of them for our own use-case.
Source available is a no man's land. People who want source code also want MIT (or similarly permissible license). People who don't care about source, don't care if it's available.
I have contributed plenty of bug fixes for tools we use at work. I have never had any concern about the license or philosophies of the maintainers, because at the end of the day, all I cared about was unblocking my work. The fact that they own my code is inconsequential to that goal. A rising tide lifts all boats, and so on.
Maybe he works for a proprietary-software company that wants to just take the code and never give back. Or maybe he is dissatisfied with lots of OSS licenses being mutually incompatible.
But it is weird that just MIT seems to be acceptable to him, I would think some BSD licenses variant would be OK as well. But maybe even an acknowledgement of the hard work of others is too much to ask for...
When the source is not available, I don’t have to think about whether or not I can use it.
When the source is available, I need to carefully consider what the license is, and if it’s anything other than MIT I’ll have to go through a whole approval process to use the thing. Any experience with corporate means you know the thing cannot be used if you value your sanity.
I just fundamentally believe that making the source available should be the same as making it free/unencumbered. If you need the legal system to enforce your license for you something is going wrong.
>People who don't care about source, don't care if it's available.
Presuming the customer is a single person. Plenty of business software is sold as proprietary with some source available pieces -- where the business doesn't care about the license, but IT wants to maintain/adjust/integrate the customizable parts.
From what I see it's basically BSL (and BSL was used until 4 months ago). It's neat that the new license is using “plain English” language, but were there any specific problems with BSL that prompted this change?
The short answer is that FSL was designed as an evolution of BSL that doesn't allow for as much variance in what the license means in practice, i.e. it got rid of the "additional grants" and mandates a shorter, fixed expiration date.
As I understand it, nothing FSL does couldn't be expressed in a modified BSL but having it as its own license makes it less ambiguous by not allowing for much variation beyond which specific license it converts to upon expiration.
To add: the problem with the BUSL was that every variation of the BUSL was effectively its own license. The FSL reins that in so that a company's legal department could approve FSL full-scale, allowing all FSL projects to be used. The same full-scale approval could never happen for the BUSL due to the variances.
Thanks. My initial reaction upon reading the submitted title was dismissive because I dislike when companies mimic the prestige of open source by saying "source available" while having a practically proprietary license.
This is the first time I've seen FSL and it is quite nice. Surely "source available" is the wrong term to label the license with.
> mimic the prestige of open source by saying "source available"
no, its just the correct term, we literally ask people who use the wrong license to change their terminology to "source available", lets not punish people who do it right from the get go
You misunderstood my comment; we probably agree. If something isn't open source, it shouldn't be labeled as open source.
I'm saying that there ought to be a more descriptive term for this license to differentiate from the usual proprietary "source available" licenses. ezekg's comment gives an appropriately descriptive label, "Fair Source".
> I dislike when companies mimic the prestige of open source by saying "source available"
It can be a practical need, rather than a prestige grab. Some people can only sink time into developing their software if sales of that software pay their bills. The redistribution rights granted by an open-source license somewhat conflict with this, by allowing another party to appropriate their original work and use it to undercut them. (This is part of why a revenue model based on services, rather than sales, is often encouraged in open-source.)
Meanwhile, the author might very much want to offer customers other rights granted by open-source licenses, like the ability to inspect the code, or to have it audited, or to modify it, or to build it from source as an assurance of what instructions are being executed. This is a situation where "source available" makes sense.
Looking at it from the other direction, some potential customers will only accept software that grants the latter rights, but don't care about redistribution rights. "Source available" is a viable option for them as well.
I wonder if it would be helpful to have a new, clearly defined term for a class of licenses granting inspection & modification rights without redistribution rights, and explicitly protecting users from additional restrictions like fees for source access. That could help make licensing of this kind easy to identify and understand, and if that meant wider acceptance, perhaps more developers would be willing to release their source code to users.
(I do see "Fair Source" mentioned in another comment, but I haven't investigated to see if it aligns with what I'm describing.)
Thanks for sharing! Got an answer to my question about updates there in the FAQ:
> How exactly does the two years work?
> The two year timeframe applies to each software version that is made available. Methods of making software available include pushing a Git commit, publishing a package to a repository, or mailing out a CD in a tin. For example, one could clone a repo, run git checkout `git rev-list -n 1 --before="2 years ago" master`, and—if LICENSE.md is FSL—use that version under MIT or Apache 2.0.
So the key is to download the source for each version you use and record the date and the current license text. Also, use the oldest version you're comfortable with since it converts the soonest. I'm thinking for down the road when new releases are under a different (even commercial) license and the pull the source for old versions. Then cost starts to go up a lot. Not saying it will, but I hope the software is successful but that sometimes leads to bad things for customers.
> The Tax Solution page doesn't make it clear as to whether it handles US State Sales Tax problems?
I will fix that. It handles US State Sales Tax to some extent. So it has state tax rules and thresholds. So will only apply the tax if the threshold or there is a nexus. However, it doesn't have the polygon tax areas that would be needed for cities. For example, Illinois doesn't have SaaS tax but Chicago does. That is very high on my list of things to do. But you could work around that right now by doing it on a customer level. Where you set the tax rate for the customer.
But I will definitely improve that text on the tax page to explain how it hands the US tax issues.
I had to do a ton of googling. It's super super hard. There are various websites that have a collection and then you need other sites for other collections.
Ugh...the tax shit in the US is so annoying. At least your e-commerce system is meant for a single kind of transaction, I worked on a more multi-purpose system (that was also open-sourced! https://github.com/workarea-commerce/workarea) that handled everything from physical items to buy online pickup in store to digital items to subscriptions. It was a LOT of work getting that tax system in order! We usually recommended our clients work with a company like Avalara or TaxJar (which is now just Stripe) so they wouldn't need to take on the burden of taxes, but a lot of folks didn't and just used our stuff. It got confusing lol...
While I'm aiming at just one market. The tax system supports having multiple. You can define products as physical or not. Define which tax type it is and then define the tax rules per country for that tax rule.
I'm going to be adding integrations with tax jar to help make it easier for keeping tax rules up to date. Do a daily/weekly check for tax in each area and then save it.
Sales tax in the US is exceedingly complex. It's simply out of scope for most companies to tackle without using a specialized sales tax vendor. To properly create a model of just US states' rules, you need to take into account dozens of factors like product type, exemptions, various address types, fulfillment info, and more.
You can get to a basic level of compliance fairly easily with state- and customer-based rates in select circumstances. But unless you dig deep, you will get things wrong, and you will only know about it when you get a potentially expensive audit years later.
Context: CTO of [Taxwire](https://taxwire.co), writing software for sales tax.
Once I was long-distance cycling in the USA during the summer, and rather fond of chocolate shakes. Somewhere at a fast food place, I got asked if I was eating in or taking out. I asked what the difference was—it seemed incongruous to ask on such an item when that’s the entirety of the order. My curiosity was rewarded: apparently there was an extra tax in that city on one or the other; so I did whichever was cheaper (and honestly, either drinking it inside, or sitting on my trike).
I even came across taxes that were only present in half a city, even—one side of a road but not the other, that kind of thing.
>like Illinois charging for certain digital services
I live in IL and haven't heard of that. Generally if something is a 'sale' it's taxed though. I miss the old days when anything purchased online was some gray area they couldn't figure out if they should tax or not.
>Chicago’s 9% amusement tax extends to all “amusements that are delivered electronically.” If you stay home and watch a movie, you pay the same tax rate as you would if seeing it in theaters.
I miss the good ole days when Boomer politicians didn't realize you could buy things on the internet (or that it even existed) and everything was without sales tax.
So, let's look at what actually happened. Boomer Bill Clinton signed the Internet Tax Freedom Act into law in 1998, prohibiting taxation of internet sales to support the growth of commerce on the internet (which itself was invented by Boomers and even older generations).
Much much later there were efforts to tax sales on the internet no matter where in the US, and for good reasons.
What's up with repeating the word "Justice" so much? Shouldn't you be writing "President of the United States Ronald Reagan, Leader of the Free World (Justice Anthony Kennedy)", etc?
The main difference is that the source code is available under a FSL license and after two years converts to the apache 2.0 license... compared to Stripe where the core part of the system is closed source and proprietary
Ok but it integrates with Stripe, right? If you still need Stripe anyway you may as well use their features directly rather than go through an indirection layer?
It’s actually better to use a buffer layer so your own payment logic is platform independent, eg if stripe bans you accidentally you can easily use another payment provider
I agree it would be great in this situation but currently it only supports Stripe, and they don't mention plans of supporting any other payment platform.
That being said, this does not look to be targeted at small businesses and that problem is one that is only faced by small businesses. Small operations need to have every payment system they can get their hands on (lest one of them throw the ban hammer). A killer feature for smaller operations would be multiple payment integrations.
* Control the templates of your pdfs
* Control the templates of your emails
* Control how your emails are being sent
* It makes having multiple subscription items a lot easier.
* It allows you to define tax rates on a customer and product level
* It allows you to define tax rates on a country and state level
* Have multiple brands on the same account
Also, it's a lot cheaper than Stripe Billing even the cloud hosted version is. Stripe Tax is even more expensive.
Again maybe I'm missing something but since it's built on top of Stripe, I would expect that it does more than just Stripe. Otherwise I don't see why I would try to install this?
It's no joke, really. I worked on a product (B2B, not consumer software) that was primarily sold in the US and Germany. Not only did we leave the product in American English, but the Germans requested that we force all numeric inputs/outputs to use American formatting (period for decimal point, comma for thousands separator, even on computers configured for German formatting). To them, it was American software and thus it made sense for it to be in American English. Their English was certainly better than our German.
TLDR:
i18n is more than just using translation tools; it requires collaboration among developers, translators, and designers. Developers need good DX tools, translators need TMS or CAT tools, and designers need translation visibility in Figma. Proper i18n is a continuous process and should be integrated from the beginning to avoid major issues.
Disclaimer: I have a connection to one of these companies, just want to share some knowledge. I strive to be as neutral as possible.
Fun fact: I'm German and know the challenges with the UI. It's a love/hate relationship!
The problem with i18n (internationalization) is that many developers and product owners believe it’s only about implementing a library and letting Google Translate, DeepL, or even ChatGPT do the rest. As most of you already know, that approach doesn't work well for German speakers. My language will break/destroy your UI design.
The real issue with i18n is that it involves many stakeholders throughout the process. Here are the most important ones to start with:
Developers: These folks need to implement a library and want a good DX (Developer Experience). It means You should choose a library with an IDE extension (e.g., VS Code's Sherlock i18n, i18n Ally).
- Libraries: Please use something that utilizes .json files. Formats like .po are cumbersome and will cause many issues.
- Use tooling that supports an ecosystem around it, like lint rules, to save time and effort.
Translators: Ideally, your preferred solution includes a TMS (Translation Management System) or a CAT (Computer-Assisted Translation) tool.
Designers: If your designers can't see the translations in tools like Figma, your UI will break, and users will complain. Figma plugins like Parrot, Phrase, or Weblate can help (just search for 'i18n' in Figma's marketplace).
All the apps mentioned are just a few examples among many tools available.
Conclusion:
The important stakeholders in this process are Developers, Translators, and Designers. i18n is an ongoing process, not a one-time task. If you start your app or project with i18n from the beginning, the annoying parts are manageable, and it won’t cost you all your nerves.
Why are people still complaining about this? It doesn't try to pass as OSS when it is not, it makes an effort at transparency when they didn't need to, seems bootstrap with an entrepreneurial spirit. That should celebrate, kudos!
German as well. I guess it's AI translated on a string by string basis, therefore translating the same thing into different words when it's in another paragraph or list item (missing context).
Signed up for the free trial... but I cant see anything on the dashboard, only a blank page with an Environments h1. :(
Cool concept though.
Oh! and the ui from the screenshots is way better than the live version
I was very surprised to see that it's localised (at least into German) and even has an imprint (in the German language version at least) despite being based in the UK.
I guess my main concern with using it as a SaaS would be that it's located outside the EU (which creates GDPR headaches despite what "GDPR compliant" services outside the EU will tell you) and whether this also means it can be adapted to comply with any given country's laws (e.g. in 2025 laws will come into effect in Germany and the EU that will place certain requirements on B2B "e-billing" such as using a specific XML format).
> I guess my main concern with using it as a SaaS would be that it's located outside the EU (which creates GDPR headaches despite what "GDPR compliant" services outside the EU will tell you) and whether this also means it can be adapted to comply with any given country's laws (e.g. in 2025 laws will come into effect in Germany and the EU that will place certain requirements on B2B "e-billing" such as using a specific XML format).
Well the UK is GDPR compliant it literally has the entire GDPR law as GDPR (UK). If there is an issue in the future I'll just move the company to Germany. The servers are currently in Germany. I will be implementing everything and anything to comply with EU laws.
With what company? All good if it's a EU company like Hertzner, but it can still give GDPR headaches if you are hosting on e.g. AWS in Frankfurt because Amazon is still a US company.
Basically, the US is not compliant with GDPR because of a couple of laws, which I've forgotten the name of. Some courts have found that because the company is US then even if the data is in the EU a US court can force the company to hand it over. This is why Google Analytics is illegal in a few countries.
I feel I should bring up that in the EU there almost exists two worlds when it comes to GDPR: Germany - and the rest of the countries.
I’ve made software for the childcare industry, where the data concerns are greater than most other industries.
Nobody had any problem with AWS, or really any non-EU vendor, as long as they lived up to the GRPR agreements and could provide the usual agreements.
Only in Germany would you run into requirements to either host in Germany (at worst) or at least within EU (at best). Additionally, there’s a lot of German specific laws on top, that simply aren’t in the other EU countries, and the general population is also much more concerned about data privacy and residency than any other EU country.
It was a world of difference, and honestly enough for me that I would not enter the German market again if it meant needing to comply with any additional effort than the rest of the EU market.
A bit more of a rant: The hosting solutions in Germany are also quite atrocious once you get to a certain scale. Lack of proper managed services, tons of instability, insane maintenance policies, poor security support (eg no 2FA for many). Once you’ve gotten used to how AWS/GCP/Azure handles things, it’s hard to go back to that world.
That EU Sovereign Cloud will help nothing. The basic facts remain the same. Amazon is a US company and the US government can force Amazon to hand over the data using a secret FISA order. They can force Amazon to add a backdoor to get the data if they have to.
> I feel I should bring up that in the EU there almost exists two worlds when it comes to GDPR: Germany - and the rest of the countries.
Well, Germany isn't the country that made Google Analytics illegal. Other countries do care.
> Nobody had any problem with AWS, or really any non-EU vendor, as long as they lived up to the GRPR agreements and could provide the usual agreements.
I was in charge of the tech for a massive man in the middle company in Germany where we integrated with lots of companies to provide data for other companies. Noone had an issue with AWS because they were all using it. It's consumers who care and consumers who will make reports and it's companies that will pay the fine.
> With what company? All good if it's a EU company like Hertzner, but it can still give GDPR headaches if you are hosting on e.g. AWS in Frankfurt because Amazon is still a US company.
Says Hetzner (with only one r) in the first FAQ, "Is BillaBear GDPR Compliant?", on the homepage.
[ETA:] Could of course have been added after you asked here; I only checked it out just now. [/ETA]
> Yea, the EU really needs to fix the EU-US GDPR issues. It's not like the US will.
And how would the EU "fix" the issues posed by the US's disregard for privacy? They tried several times but Schrems keeps tearing it down by pointing out the basic fact that you don't get a pass for violating civil rights by being the US.
So in other words, the US would have to change (or limit the scope of) its laws? Then yes.
But the implication was that the EU could do something to make such a treaty work and other than repeal and replace GDPR I don't see any way as long as the US insists on playing secret police when it comes to foreign data subjects.
There is nothing more enjoyable and fun than developing on a mature, boring tech stack. We might be able to keep web devs more than a year if the kneejerk choice wasn't React or Angular (Vue3 is a joy).
Who decides what is "boring"? Plenty of people have stuck with React for nearly a decade and components just as old continue to work in the latest version of React. Meanwhile, Vue 3 is such a breaking change from Vue 2 that people either abandon Vue altogether or chase bugs with the 2-to-3 bridge. Does that make React "boring and mature" compared to Vue 3? If not, why not?
I don't want to read the source code, I want to use the product. If there is a bug, I want you to fix it. If you don't fix it, why am I paying you / using it? Assuming I am a programmer (many users aren't) and make my own patch, and you don't merge it, I'm still screwed. Source only helps me if I'm the one running the code. So the fact that your SaaS is source available has no bearing on my use of it.