(Replying to PARENT post)
The shareware model of the 1980's stopped being a viable business plan a long time ago. Also, most recent Desktop Application utilities have been replaced by mobile app users (IRC became twitter, BBS became facebook, usenet forsale became ebay, email became webmail or telegram... and so on... and so on..)
The only time we tend to close software is for business reasons where IP release would cause market fragmentation and or sales degradation. i.e. a lesson the 187+ fart app publishers would never understand.
(Replying to PARENT post)
I keep them general, because those are my interpretations. But you'll probably recognize similar things in many other projects.
One compelling example, comes from a maintainer and author of several popular repositories that are quite powerful and would be hairy and time consuming to re-implement. Typical high-impact, foundational library code. Some of his arguments for making them open source seems to be primarily two fold, one is not as directly business related:
He just wants to provide things for others to use and sees benefit in that, so it's both altruistic and fun, but also due to getting more use, his libraries are more exposed and hardened.
The other one is simply not wanting to repeat the same work over and over when switching projects or employees. This is a really important one IMO. Foundational libraries are ridiculously expensive to re-implement in every project for every employee. It's just inefficient. But by open sourcing them everyone who uses them gets to benefit from everyone else. Everyone gets to be more efficient and potentially have higher quality code that is maintained over a much longer time.
(Replying to PARENT post)
(Replying to PARENT post)
(Replying to PARENT post)
MongoDB promoted itself as OS, but does not even look at pull requests.
Bloomberg's "BDE" project, likewise until recently. Ordered by upper mgmt to respond to PRs, they had a meeting where the topic was where to find time to write rejections. (They need not have bothered; no one would use BDE where not required.)
(Replying to PARENT post)
Here, see for yourself some of the tactics they use:
https://www.qt.io/download-open-source
> This dual-licensing model is based on the principal of quid pro quo – roughly meaning “something for something.”
> Simply put, this is how it works: In return for the value you receive from using Qt to create your application, you are expected to give back by contributing to Qt or buying Qt.
No you're not. You're expected to follow the license agreement, which requires neither of those things. You can't even argue an interpretation where GPL requires you to contribute back to Qt, and most of Qt is LGPL, which requires even less. The closest it gets is that if you patch Qt, you have to publish the changes. That's a pretty stark contrast there...
This entire page is full of fearmongering crap designed to scare people out of trying to use the open source version. It, of course, has some other very curious issues, like that giant blurry link which is actually an image with text, but what is perhaps most interesting to me personally is their other page about open source:
https://www.qt.io/licensing/open-source-lgpl-obligations
> The primary open-source license is the GNU Lesser General Public License v. 3 (“LGPL”). With the LGPL license option, you can use the essential libraries and some add-on libraries of Qt. This allows for keeping your application source code closed as long as all the requirements of LGPLv3 are met. More details are available below.
They go on to describe the restrictions. Some of them are fair, as they point out legitimate places where businesses may not like the terms, such as GPL 3's anti-TiVoization rules or their DRM agreement. However, some of the obligations are basically pre-fulfilled when you use the official SDK, which is what the previous download page was for. For example, if you use the official SDK, you will get dynamically-linked Qt. This is good enough to satisfy the relinking rules of LGPL. However, they never actually say this anywhere, since it would probably scare less people into a commercial license. Even with that grievance, this page is significantly more reasonable than the page that most people see, right before attempting to download the SDK (which, BTW, requires that you log in, even for the open source version. So build it yourself. It's easy.)
Due to their recent shenanigans with the KDE Free Qt agreement, I'm inclined to not believe a charitable interpretation of what's going on here. I want Qt to be successful and sustainable of course, but not like this.
(Replying to PARENT post)
Thanks for pointing this out -- at the end it's about interpretation but we made changes to the readme to be more clear around distribution: https://github.com/calcom/cal.com#setup
TLDR: of course you can clone the repo into a personal folder. When I had the conversation with you I was mostly thinking you are referring to distributing, which is only possible in a public repository.
You can use the code for yourself on your private machine.
This license is specifically targeted against BigTech who have a track record of taking MIT / Apache code, making it proprietary without giving anything back.
See the ongoing Amazon Elasticsearch conflict.
Plausible wrote a great article about this and we decided to go to AGPLv3 after talking to the founders: https://plausible.io/blog/open-source-licenses
(Replying to PARENT post)
Bad actors have free reign to threaten and intimidate fair use development. While FOSS developers are having to defend themselves from these spurious claims, they have little recourse to pursue real infringement of their work.