> And even if we created or found an applicable license, who would enforce it? We are a small team of four software engineers from Switzerland and we have neither the knowledge nor the means to report license violators.
Everyone who goes "just release it under XYZ license" misses this one key part. There are next to zero examples of small companies successfully enforcing their software copyright. It is expensive and takes a team of lawyers to do so.
> There are next to zero examples of small companies successfully enforcing their software copyright.
Not so. Consider: If it did happen, would you hear about it? Consider also: Why do huge, multinational companies invest so much in open license compliance programs and program offices?
I have personally helped small companies and even solo developers enforce license terms for their software. And I have seen plenty of instances of developers doing so without paid lawyer help. I have also helped small companies and solo developers sell commercial licenses for projects under copyleft, noncommercial, and other licenses meaningfully limiting permissions. Those customers have the source code. If they could simply flaunt the rules, there'd be little cause to pay for exceptions.
Why aren't these stories all over my blog? Because I can't run around blurting client confidential information. California Business and Professions Code 6068: "It is the duty of an attorney to do all of the following: ... (e)(1) To maintain inviolate the confidence, and at every peril to himself or herself to preserve the secrets, of his or her client."
There are exceptions. Sometimes at least the first part of the process happens in public, as when a company gets called out by a dev on Twitter. Those tweets are out there. And they can work when the developer's primary leverage is public relations. That tends to be true against violators that sell or hire among developers.
There are also takedown requests under the Digital Millennium Copyright Act. Sometimes, getting a company's repository, web app, or other online presence taken down for copyright infringement is all the leverage a developer needs to make a violator stop, or even kick off a settlement conversation. And DMCA notices are definitely something devs can submit themselves. I have represented clients on the receiving ends of many such requests, some of which also involved social media name-and-shame campaigns.
When settlements do get reached between private parties on license violations, they're almost always confidential, or neither side has any incentive to be loud. The activist organizations doing enforcement, like SFC, tend to see the press releases announcing settlements as big parts of the payoff for enforcement. But they are the exception, not the rule. Search around the Web for "settlement agreement form". I'd bet nearly every one you find has a built in "confidentiality" or "nondisclosure" part built in.
It costs too much money to enforce, takes too much time and payout is very small even if you win ( you won't -- you will probably settle for a fraction after wasting years of your time and hundreds of thousands of dollars )
Source: a friendly customer is an attorney specializing in just that.
I do this open-related law thing for a living. I know fellow specialists, and there aren't that many of us. I'm not aware of any colleague in private practice specializing in open software license enforcement as such. Even staff attorneys at open source foundations that enforce split their time across advisory, compliance, and other matters. And those foundations don't do so many enforcement claims anyway, in absolute terms.
If you know an exception, that's great, please connect me. kyle@kemitchell.com. If they're actually specialized in high-stakes copyright litigation among firms with legal budgets in the millions, there's no need. I know those folks. I wouldn't refer small or solo firms at their rates. I'd suggest they may not be adequately adjusting for scale. Nobody sees the whole industry.
As for the view from my own two eyes, I have absolutely billed solo-developer clients for work on settlements and license deals following license violations who were happy to pay and came away with a nice profit. I have also seen developers drive lucrative deals pointing out violations of license terms without any attorney assistance at all.
> Are you seriously explaining litigation costs to a quite well-known attorney working in this space?
Yes, I am. The attorney's goals are not aligned with developer's goals because developer pays the attorney, not that the attorney pays the developer. Attorney makes money from developer(s) regardless of a developer(s) making money off the violation. It is bonkers that seemingly educated people do not understand this.
Fighting IP battles from a perspective of a little party that has IP against a giant that is violating little party's IP is a fool's errand. Rarely the fool wins. That's why there's no market for litigation financing in IP like it exists for litigation financing of ambulance chasing.
> Google "contingent fee". Then "copyright act registration attorneys fees"
I don't need to - you, as an attorney, are not going to take every case on contingency. You are only going to take cases that you think you are going to win and you are likely to collect. In most of cases you would require a minimum payment from a client. In those cases the client will probably be fucked.
Is this less true for commercial licenses, though?
If someone's going to violate your licensing terms, they don't really care which license they violate, and it's not like it's hard to find pirated software.
If a company has to go onto a pirate website to get a copy, that's going to throw up red flags in all but truly corrupt organizations.
If, on the other hand, a piece of software can be downloaded directly off the company's website, it's pretty easy to gloss over the fine print that says "if you comply with terms X, Y, and Z".
True in many cases, but I suspect the ones violating the license are more interested in getting free benefit of the software than they are in the philosophy of making source available.
It's almost trivial to create it yourself for anything written in C# or another .NET language. ILSpy and similar tools have existed for quite some time.
I'd like to see source trusts like the code is given to an authority that will make it Apache/MIT/BSD if conditions are met. Let the creators draw the line in the sand. Company goes bankrupt. No new release for 3 years. Or maybe always release the code from 5 years commit by commit. Just to prevent abandonware and lost sources. Should be sufficient to preserve commercial viability.
"The Business Source License (this document, or the “License”) is not an Open Source license. However, the Licensed Work will eventually be made available under an Open Source License, as stated in this License."
You seem to be missing the whole point of this thread. They wanted something like a "source trust". The BSL provides something like that, as long as you aren't worried about people breaking the license without concern for legal consequence.
The code eventually becomes open source after certain criteria are met. No one in this thread claimed that BSL-licensed code is immediately open source.
If you're of sufficient size that you are a risk to a company's bottom line, I've got news for you: they probably already have a stake in you going bankrupt. Companies buy insurance against their business partners going bankrupt all the time. One such means is called a credit default swap (CDS).
We are having a similar discussion for the startup I am working on (Caido.io). We are bootstrap and would like to make a living out of our work. We just don't have the luxury of VC money where we can open source and worry about making money later.
Our compromise is that we are open sourcing anything that is not the core of the application for now. If we have enterprise / cloud features down the line, we will open source the core.
I would really like to live in a world when open source doesn't necessarily mean gratis or direct copy by a competitor, but I have yet to see that work for desktop applications.
I love open source, but commercial software is completely fine in my opinion. I think the idea that there needs to be a way how open source can be monetized is very damaging to the idea itself. You can do that through support and expertise of course, but can also sell the software itself.
You can also open source it later if you are established but you can also choose not to. The advantage of open source is that you may be able to leverage the ingenuity of people outside your company, get them invested in your software. I believe most are in open source to share code with each other, not necessarily to build a business.
Most people that make money with open source don't really offer the software, they offer the whole package of a solution that can solve a problem for business customers. But not every form of software can fit into such a scenario.
Dunno. Recently, I had good luck with AGPL dual-license models. Most competitors wouldn't touch that with a 10-foot-pole. At the same time, we could build a contributor community. It cut off some sales, but build far, far more.
I've seen other organizations do well with cloud hosting or support models. There are plenty of open source unicorn companies doing those sorts of things. Highest-margin "price doesn't matter" contracts will generally go to the author of a tool.
It really depends on the business plan. I've been pretty successful with both open and closed source models, and in retrospect, I think they wouldn't have worked swapped around.
The logic you're giving doesn't really make sense: "We just don't have the luxury of VC money where we can open source and worry about making money later." or "Our compromise is that we are open sourcing anything that is not the core of the application for now. If we have enterprise / cloud features down the line, we will open source the core."
Open source has significant business upsides. For example:
- If I'm buying from a small startup, open source reduces the risk of what happens when the startup goes under, or if a business goes Oracle and decides to take advantage of me once they have lock-in.
- It builds ecosystems, networks, traction, visibility, and distribution. For small companies, those are hard problems.
- It allows external contributions. Conversely, on the customer side, if a vendor won't fix a bug, I can.
- On the customer side, it gives me transparency into roadmaps and development.
Right now, I'm now at a big company, and I generally tend to buy open source. The build-versus-buy decision is purely economic, and economics usually goes towards "buy." Open-source gives most of the advantages of "build."
The relative cost/value of those is an analysis that depends on your specific business model. Making the decision otherwise -- pretending open-source is some kind of charity -- is bad business.
Good points, like I said we are still discussing it internally and I like some of the points you made.
For now our target customers are individuals that happen to be very good with computers so we can't expect juicy support contracts. That is why we think that if we can pivot to that model (enterprise support) open source would make sense.
We try to as transparent as possible in the meantime with public roadmap, open sourcing non critical parts, etc. At the moment we don't want external code contributions to the core so I think our model make sense.
>> Dunno. Recently, I had good luck with AGPL dual-license models. Most competitors wouldn't touch that with a 10-foot-pole. At the same time, we could build a contributor community. It cut off some sales, but build far, far more.
Not sure about building a community around that. AFAICT most people don't want to make contributions under a CLA knowing that you can build the commercial version incorporating their work. Some will, but I look at things like QCad -> LibreCAD and it just didn't work - the "open" version of the commercial branch is ahead of the community one now.
These are kind of case-by-case decisions. It depends on the contributor community. In the case referenced, we did have a CLA. Most of the potential (and actual) contributors were academics, supported by their universities or by research grants. AGPL allowed full scientific transparency, without any real downsides. There were other contributors who were turned away by the CLA, but it was not an unreasonable trade-off. We still had hundreds of contributors. And we did release a small piece of the system under Apache, because we wanted an industry standard for an API/format. Having that piece under Apache encouraged competitors to adopt it (which didn't really happen, unfortunately).
On project I'm currently leading -- and I can't speak for success yet -- is AGPL without a CLA. Most of the business value comes from network effects. A good analogy would be if Facebook had started out AGPL (or Wikimedia, for that matter). The code has little value independently of the community and partnerships I'm building. AGPL allows for full transparency, which has a ton of value in the market we're targeting (at least for people who think through these things deeply). For people who don't think deeply, having an FSF/OSI-approved license gives name recognition and opens doors.
I'm leading two major projects. The other is pursuing a closed model because it makes sense there.
I can't speak for any specific case. All I'm trying to say is it's an in-depth case-by-case analysis. Businesses which pick closed because they "want to make money," open "to contribute," BSD to "be more open," or similar knee-jerk reactions are doing it wrong. It is a complex analysis, and my case is different from yours.
What kind of problems does AGPL have? Seems like a great choice for someone with commercial plans since it gives you a strong competitive advantage against anyone who thinks of just reselling your software/service.
That post actually supports my point. He made some bad arguments against AGPL, but this key part highlights the point I was making:
> … as well of depriving them from having no competitive advantage for making any suitable profit from it.
That’s exactly what I want if I’m planning to make money from my open source project. I can release it as open source so that users can study it, contribute, audit it, self host it, etc. while at the same time avoid worrying about an Elastic Search situation.
Obviously, whoever wrote that is coming at it from a different perspective than I.
>I would really like to live in a world when open source doesn't necessarily mean gratis or direct copy by a competitor, but I have yet to see that work for desktop applications.
What would open source possibly mean, if not at least the latter? If you're a free software person then competitors being able to directly copy your code for nothing is part of the moral imperative you chose to stand for. Absent that imperative, open source still allows for proprietary sub-licensing.
You don't have to open source your code if you don't want to, nor do you have to give it away for free if you do.
For me open source is to give the assurance to users that we are not doing shady things and that no matter what the business does they will continue to be able to use their software.
What assurance does it give? I could "open source" the cmd files of my go app but keep the core libraries proprietary and the only folks who would call me out on it are the ones who understand what I did, everyone else will just see some folders in git and releases filled with binaries that aren't FOSS and think nothing of it. There are numerous examples of open source software doing shady things like telemetry and calling home too.
It also doesn't necessarily guarantee future use of the software unless someone is going to step up and maintain it. Keeping software current/compatible is quite onerous, especially for GUI apps.
... and how do you give users that assurance? By giving them free access to the source code so they can validate it, rewrite it and redistribute it if they want.
Being able to make a living is more important than open sourcing. Keep in mind that these other open source companies likely took that decision because they thought they would earn more money than keeping it closed source. It's a user funnel.
Open source just implies that by economic principles, the market price for the respective software will soon converge to the marginal cost.
Just to give another example how open source software might have a price: start a Kickstarter campaign which will release a software product as open source as soon as, say, 100,000 USD or EUR is reached.
> Open source does not mean "gratis". See for example this historic order form of software offered by the Free Software Foundation:
That's the example that's been shown for the last 30 years, Richard Stallman making a buck selling copies of Emacs and GCC during a period in the 80s and early 90s, when infrastructure constraints made it cheaper, or feasible in the first place, for the user to order software to be shipped on physical media rather than downloading it from the net.
Either there are no more examples of businesses that have lived off selling copies of Free desktop software, or the FSF really doesn't care enough to look for one in the last 20 years.
Other examples of entirely open source projects that have paid, full time developers include all of RedHat, Godot, Blender, Linux, Python, Django... the list is very long.
Yes but we're talking specifically of Software targeted at consumers or niche professionals, what "Independent Software Vendors" sell, it's good that some infrastructure projects get corporate sponsorship and that RedHat funnels some money from its server software business to the Linux desktop, but this is, rather noticeably, not spurring development of Linux desktop applications now, or last year, or in the ten years prior.
> Open source does not mean "gratis". See for example this historic order form of software offered by the Free Software Foundation:
If the best example in support of your thesis is a "historic order form" (not even a revenue statement!) from 30 years ago, way before the ubiquitous availability of high-speed Internet, then you might want to rethink your position.
Your second example with Kickstarter stretch goals doesn't change much imho, it's a one-time payment which won't really work long-term for a company, and after the release it's the same situation again. In the end that's still not payment for the software itself or the license to use it, but for development with the typical risk of investment.
Selling units of something is different from one-time patronage. There's no way you'll employ more than yourself by doing 100k fund raisers for your work, and Software often requires teams.
If this were economically viable, it'd be happening often.
> Once you open source a project, it is out in the open.
Gitlab disproves this.
E.g., they have no solution on the horizon for dealing with spam for their open source Gitlab Community Edition. That means that for common use cases like having an instance open to the public for participation in GSoC, a gitlab-ce instance will get eaten alive by indonesian casino spam (or whatever the current spam offerings happen to be).
But they do have a solution for their proprietary Enterprise Edition which uses a proprietary blob. One of their employees suggested I just switch to that version because it's apparently available free of charge.
The other possibility is to use whatever they run on their gitlab.com service. In that case it's not my instance so the license doesn't really matter as much. Nevertheless, I'm almost certain they are running their proprietary spam filter there so it's not open source either.
In conclusion, this is a perfect refutation of the author's point. Start open, run a service that's free of charge, and slowly cut off the flow of key features to the open source version (or simply do not care about that flow).
Gitlab are under no obligation to open-source specific features - rather, if the software is licensed under an OSD-compliant license, anyone has the right to fork it and add their own spam filtering. That's what openness is all about.
I'm telling the author that there's virtually no threat of anyone forking gitlab-ce, for any reason whatsoever. Even though "anyone has the right," as you say, and even though the lack of spam filtering there makes gitlab-ce essentially useless as a public-facing repo service.
Author claimed that open sourcing would equal less money for author. My argument is that is not a given nor even likely-- it depends on specifics wrt complexity of the software, difficulty of maintaining it, relationship of dev to users, etc.
It seems like more and more companies are doing this. Kind of concerning. Is true FOSS going to fade away one day?
Chromium no longer has sync, so we currently have no usable browsers that support Google's stuff.
The last 15 years of open source progress seems to have been driven by big companies rather than the community.
Community driven FOSS doesn't even seem like a reasonable idea at all given how much work it is, and how completely thankless it is, so most of what we get there is just "scratch your own itch" type stuff, often fairly useless outside a really specific use case, rather than the real pro-grade packages.
Arch seems to be eating some of Debian's dev base, and Arch is built from the ground up for highly customized "just enough" setups.
It seems like the community mostly just cares about privacy and tinkering these days.
What's going to happen to the "Windows-like" side of FOSS?
I think it's a bit of a pendulum. The enthusiasm and excitement for open source was largely driven by the locked-down environment of the time. Access to source and high-quality free software with source was an exhilarating novelty.
But now we're kind of saturated, and used to it. Practically everything is free, it's not exciting anymore. New open source projects feel like just a drop in the bucket. Creators don't get the same sense of accomplishment from releasing new code.
It may be necessary for a whole new generation to experience how shitty it is to be stuck with for-pay locked-down software that gradually rots beneath you, juggling library licences, phoning IT help lines for trivial problems, and having to ship every few years to some new (expensive) hotness.
I don't know, there are a few companies I've seen around lately that have an open source "core" with proprietary business add-ons. Teleport and Tailscale for example. The Tailscale CEO wrote a post about it recently that got traction on here: https://news.ycombinator.com/item?id=29736369
> Chromium no longer has sync, so we currently have no usable browsers that support Google's stuff.
Yes, Google has been not only anti-competitive, also very anti-FOSS. Google has been slowly making Chromium project more closed source. The original article of this thread is an evidence of Google's harmful effects on FOSS eco-system. Now other companies are also retreating on their open source effort because of Google.
Chromium doesn't have sync. That's enough right there that I wouldn't consider using it.
Firefox is usable-ish but they reject a lot of Google's tech, and seem to have no interest in the modern vision if the web. Even on some safe features they're years behind.
Brave is mostly open, but they have started following FF, actively removing Google's features from Chromium rather than adding permission toggles.
You would think that the app people use the most would be top notch in the FOSS world, but we have very few FOSS options, all with the same Mozilla philosophy, except Chromium which is getting closer to being a reference implementation rather than a usable browser.
Meanwhile closed chromium browsers like Vivaldi and Chrome itself are pretty great.
> Chromium doesn't have sync. That's enough right there that I wouldn't consider using it.
Personally I've never used the sync features of any browser. Can't that kind of thing be done with an extension?
> Firefox is usable-ish but they reject a lot of Google's tech, and seem to have no interest in the modern vision if the web. Even on some safe features they're years behind.
In my experience, Firefox works fine, despite Mozilla's long history of atrocious decisions. Its performance is competitive with Chromium (the winner depends on the benchmark/website). Compatibility issues do occur but are rare.
What do you mean by no interest in the modern vision if the web?
Nothing can be done with an extension because extensions don't exist on mobile browsers. I hear FF might get them but I doubt Chromium will for a while.
Chromium seems to want to be an apps platform with full desktop power. Everything from web serial to the battery status API, yo keyboard layout stuff, gets either summarily axed, nerfed, or at best begrudgingly added after a long time.
Mozilla doesn't do permission prompts or settings. Their priority seems to be getting rid of all ability to do tracking even at the expense of real use cases.
Personally I'm a fan of MariaDB's "Business Source License". Enough of the benefits of open source that I can trust your product, but enough of the benefits of closed source that you can use whatever monetization strategy you want.
Shared source that becomes truly open source after 5 years. This means that if the company managing the source code does really poorly someone else can fork it commercially, but only the version from 5 years ago. This protects users in the cases the managing company goes out of business, or goes evil, but still lets them put in arbitrary commercial restrictions.
I wonder - would it be a good idea to release the source code a few versions old? Competitors likely already have implemented similar things so no major corporate issues. Not open source, just source-available, so no issue with Amazon running off with the code. And power users/fans can add their own additional software which likely will still work with newer versions.
Of course, I'm likely missing several things - I'd be grateful if someone could point these out. (I've been thinking of this strategy not just in this specific case but in general.)
Well, for one thing you might be missing is that software doesn't change drastically between versions these days. Specially if you factor rapid release cycles in. So whatever is present in your new version is just a small set of features compared to all that is available on your older versions. People might simply be tempted by the FOSS version, not because it is FOSS but because it is free. A ton of people use FOSS software not because of all the ethos of free software but because it is gratis. If an old version is already useful enough and available as a fork, it will be hard to tempt some one to pay for your full version.
I was not referring to one numerical version behind but rather one "version with significant features" behind, sorry should have been more clear.
The cost point is very valid. Of course if I were to put out any code (I'm not a full-time developer) it would be as a hobby so monetization would be a bonus. I wonder if Kreya/others etc could offer some customer service that's so much of a benefit that corps want it (maybe like what Red Hat does). Though that'll also add complexity... a chicken and egg problem I suppose.
The "we want to make money" argument is pretty weak when desktop software like Ardour demonstrates that it's still possible and feasible.
The "we don't want to be stuck with a too-permissive license" argument is also pretty weak when there are a lot of licenses besides MIT (and when they, being the copyright holders, can relicense at any time; sure, the cat's out of the bag for already-released code, but for future versions that ain't necessarily the case).
One counterexample doesn't make an argument "weak", if there are thousands of cases to the contrary.
About what percentage of FOSS developers do you suppose make a living wage from their software?
It's like pointing to a successful pop singer or pro athlete as an example of how it's possible to get rich doing those things. Possible? Certainly -- but only a minuscule percentage of the kids who start out in sports or music ever make it.
> One counterexample doesn't make an argument "weak", if there are thousands of cases to the contrary.
Are there "thousands of cases to the contrary", though? About what percentage of FOSS developers do you suppose even try making payment a prerequisite for a ready-to-run official binary? Or for that matter, about what percentage even attempts to monetize at all?
That's what makes the argument weak: it reeks strongly of "we've tried nothing and we're all out of ideas".
There's open source backend software and there's full-stack / GUI oriented software and in my limited experience, I don't think the latter always makes sense.
Smarter people than me have articulated their points about that:
"Placemark, the application, won’t be open source. I didn’t even consider the possibility: open sourcing the application layer of a product just doesn’t work. You get all the downsides of community support, white-labeling, process friction, confusion around why people have to pay, confusion around whether to use the open source version or the paid version, and none of the benefits."
I think the dream is to open source the standards, protocols, backend engines, etc. But man, whenever you have to think heavily about a user interface, things get really hard. How do you decentralize design of something?
Here's a possibly novel take – the modern interview process for software developers is causing more and more projects to move to these non-FOSS licensing terms.
"Wait, what? What could convoluted interview processes possibly have to do with licensing?"
Well, developers need to make money somehow. In the past, releasing your software as FOSS allowed you to display your skills for software development and feature planning out in the open. Often, you'd be hired on the basis of those demonstrable skills at a paying job even if you didn't make money on the product itself. Multiple engineers I know went through very abbreviated hiring processes, being pretty quickly waved through if they had worked on FOSS in any significant capacity.
Today, that's not the case at all, and any interview process for a high-paying job seems to have 5-6 rounds of arduous interviews, no exceptions. I have conducted around fifty or so interview processes for dev positions at a non-FAANG company, and "look at the candidate's FOSS experience" isn't on a single one of them. I don't think I could get any major FOSS contributor exempted from a single interview process at my company on the basis of their experience. The case of the Homebrew creator and Google is reasonably well-known [1].
Well, the natural response is going to be for them to work on their own product, and not open up the source code unless they get paid for it. Which is what software devs are doing these days, in increasing numbers.
Sounds plausible, but I dunno how prevalent that really is, though. Do that many people write OSS code just to get hired?
I've never once made a contribution or started a project primarily because I thought it would get me a job or other professional recognition. I contribute to projects I think are worthwhile, to those that I benefit from and want to give back to, and to things that "scratch an itch" either personally or professionally.
> Do that many people write OSS code just to get hired?
No, I meant that in the past, it was a significant incentive to release code that you were already working on for a company or product as FOSS, i.e. "Even if this company or job doesn't work out, the open-sourced code is a good way to demonstrate my technical capability". I am talking real, commercially capable tools.
I would say that not too many people wrote OSS code to get hired, but a high number of people might have open-sourced existing code on the basis that it might help them get hired some day. If you haven't tried to build a company or product based on your code, then this wouldn't apply to you (unlike the Kreya devs).
I think it’s extremely common. Just look at all of the LinkedIn profiles with links to Github. Schools tell their students to do this because it will help them get hired, even though that’s probably wrong in the vast majority of cases.
If you’re looking for a job, don’t have a network/personal connections, don’t have an amazing resume, etc then what can you do? Either spend months grinding leetcode so you can get an entry level job working on ads, or contribute/build something (open source or not) to get your name out there and pad your resume.
From what I've seen the vast majority of that just produces lots of copies of tutorial projects repeated over and over again, as that's far easier than actually coming up with a new project that's of use to other people, or getting involved, learning the process, and becoming a contributor on an existing one.
I've seen that advice everywhere, but _never_ actually seen someone become an ongoing OSS contributor as a result. I'm sure it happens, but I question how often and how much of an impact it actually is.
I like the idea of a promise that all code will be open sourced at a 2 to 3 year delay. I have seen this model in use, and it disincentivizes competitor forks (especially if that open source is GPL) while still allowing paid versions.
I don't see why there's a need for this explanation. If your end goal is to sell the software you make you shouldn't open source it.
The main use case for open source is software you USE, you release it into the wild so others also add to it and it becomes better for everyone to USE. See programming languages or frameworks. You're not selling the OSS, you're getting others to improve the OSS that you then use to create a closed source product.
Open sourcing software you intend to sell means it's either a trojan horse or someone else just sells it (in one case dishonest, in another case you get exploited).
It really seems they're trying to get things right, but are afraid of the competition. In my opinion this is because the company and the product is new to the market. Once they know that their income isn't tied to them being closed-source, they might change their position on this, or they will keep their customer locked-up because they're afraid of them running away.
This seems to be missing the point : Freedom for the users on one side, and sharing knowledge on the other side.
Here you have neither of the two and the only reason is fear. If your startup isn't successful and you have open-sourced your code, it's probably not because of the competition using your code, but because you're not solving a problem that people need to be solved.
For an app like this, open sourcing non-business-critical parts of the app a perfectly valid way to go about it, like they are doing with the templating library. You still get visibility, testing and the occasional bugfix from the community.
Another possible way to go about it is open-core: Open source version, with more advanced features on a closed-source solution. Contributors to the open source version have to waive off some of their rights in order for this to work, though. There are tools that automate most of that these days.
I wonder if a nice source available license comes about, similar to how we have common ones for FOSS like MIT which are well understood and easy to apply.
A source available license allowing for personal modifications, sharing with other licensees, contributing fixes that might not be a priority to the dev is present with projects like Unreal Engine and a few other examples I can think of. However they are all bespoke licensing.
As someone who remembers when most apps were desktop apps this seems a strange point. I suppose it's a better look than what the actual header for this section should be which is "we want to sell this for money"
I respect that they have reasons not to release Kreya as open source. Fine.
But claiming "We love open source" is a blatant lie: the article makes it really clear that they only love the aspects of open source that are to their advantage. They should better honestly write this.
No, it's not: the point is that they're basically saying "we love it as long as it's someone else who loses potential profits, not us". This is kind of a significant, and not a semantic minor detail.
If one believes that open source something can lead to a loss of profits, then one must believe also that the open source software they have likely used has already made that sacrifice. It's easy to appreciate the sacrifice of others but then fail to make it oneself.
"We love all-you-can-eat buffets, just not the part where you pay for it (so we climb through the window of our local Golden Corral to make our getaway)"
"I love all you can eat buffets but today I'm not really that hungry and it throws off the balance of cost to result so I think I'll just get a sandwich."
Do you practice unconditional love? Among the people you love in your life...is there not a single aspect or behavior they exhibit that maybe annoys you a little bit or you wish was different?
"I love you, and I love it when you do favors for me...but I don't love you quite enough to return the favors."
Everybody loves benefiting from free software. Who wouldn't? But if you aren't willing to contribute, then it probably isn't worth mentioning. All you're saying is "We love getting free stuff".
They don't seem to be unwilling to contribute, they just can't take the risk with their sole core product. They did release Mapperly as Apache-2.0, but to you that means nothing unless they open everything?
The rest of the article explains why they won't release this product opensource even though they love it. It is not disingenuous.
They released Mapperly under Apache-2.0, but I don't know if you read that far.
If I tell you that "I love NodeJS but this specific project needs to run on embedded so I used C", it doesn't diminish my love of NodeJS or make it disingenuous. Love doesn't mean you'll always pick the thing no matter what, just a strong preference over the other possible options.
> The rest of the article explains why they won't release opensource even though they love it. It is not disingenuous.
No it doesn't. This is like someone saying, I love poor people and helping them but I love capitalism more because then I can charge those poor people in order for them to get help. Might as well just say what they really love which is money.
> Might as well just say what they really love which is money.
Thanks for understanding my point. They are just saying they “love open source” to ingratiate themselves to the reader but it’s a meaningless statement because who wouldn’t love free work? The entire article that follows comes off like a long-winded rationalization. They would be better off saying “we don’t open source our product because we don’t want to” I would respect that more and it would save me time.
To you, the bar to be able to claim "we love open-source" is to have every single thing you make be open-source? Just like loving the color pink means every single thing you own should be pink? Does loving chocolate mean every single meal you prepare should have chocolate?
I mean, it's valid, if you're consistent. I don't think it's the way anyone else uses the word, but that is one way to define it.
That's not a point, that's a claim. They say they do, and they did release one piece of software open source. For the one they didn't release, they provided a rationale as to why not. Why do you claim that it's a "meaningless statement"?
> Why do you claim that it's a "meaningless statement"?
Because whether or not they “love open source” has no bearing on rationally deciding whether or not they should release one of their products as open source.
The only function of that statement as far as I can tell is to ingratiate themselves to the reader, i.e. “we’re on your team!” That type of desperate signaling communicates a lack of confidence in their rationalization, which in turn makes it seem disingenuous.
No one is disputing their involvement with open source. The point has been made and it should be evident to anyone who understands how rational decisions are made.
> First off, we are huge fans of open source projects. For example, Kreya uses the open source scripting language Scriban.
I really don't know how you overcome to cognitive dissonance to continue after this. Call me naive, but it's pretty scummy to take someone else's open source work, add some extra code, and slap a pricetag on it.
It's not "technically" legal, it's fully legal in every sense. And using someone's code for a purpose they explicitly allowed is about as far from morally reprehensible as it gets.
If you don't want people to base closed source software on your work, then you shouldn't be granting them a license that explicitly permits them to do exactly that. AGPL is an option if that is what you want.
If the scriban people didn't want that to happen, they could have used a license (e.g., GPL) that prohibits it.
Some of us use BSD or MIT licenses precisely for that reason. I'm happy if someone uses my MIT-licensed code in a commercial product. That's why I chose that license.
If that’s the context, then what point is the statement trying to make?
The addition of the code and the slapping of the price tag has no bearing whatsoever on copyleft compliance, and that you have to redistribute the source of the combined work along with the binary under a compatible license is just calling water wet.
Everyone who goes "just release it under XYZ license" misses this one key part. There are next to zero examples of small companies successfully enforcing their software copyright. It is expensive and takes a team of lawyers to do so.