Particularly with the last anecdote, it seems that the evergreen problem with open-source licenses is not the choice of license or the particulars of the terms, but enforcing the terms at all.
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.
> Bad actors have free reign to threaten and intimidate fair use development.
IANAL; I want to avoid calling the last example "fair use development", as "fair use" — which is a copyright concept — is not being relied upon here: there was a license (the MIT license) issued with the code, with which the "{Developer}" was, AFAICT from the OP, obeying. I do agree that the development/use by "{Developer}" appears "fair" (in the more colloquial/common sense of the word), given the information presented.
Like to publish under the Apache 2.0 license when I can, because no one can predict the public or commercial use-cases 5 years from now. Also, I tend to look at software as being transitory in nature, and only the underlying algorithm reincarnates if proven useful (the GNU is likely immortal).
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.
There are "business benefit" use-cases that don't fall into either of those categories. Note that the article doesn't claim that this is an exhaustive list, nor that there aren't positive cases. I just want to mention and discuss some of them.
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.
To confirm, my article focuses on benefits to business based upon their (In my opinion/understanding) misrepresentations/misunderstandings of their licenses, not business benefits of Open Source in general. I am a big fan of Open Source and realise that there are indeed many benefits.
Champagne and Parmigiano-Reggiano both have their definitions codified in the law, and it's illegal to use those names on your wine or cheese if you don't meet them. Maybe we should do the same for Free Software and Open Source.
FYI: Trademarks are a thing - international registration is really expensive, though, and then you've also got to be ready and have the resources required to defend it legally.
I think the strategy would be to try to get it done within the EU. If people had to change their marketing materials to sell to Europe, they'd probably take out any spurious or misleading references to FOSS from the beginning. The EU has very much shown that it is concerned and willing to act over descriptions/names when it comes to trade.
Words in English often have multiple meanings. Nobody is confused that you can use a string in a computer program, or use string to annoy your cat or tie up a package. "Organic" is the same way; when it's on food, it's not referring to the branch of chemistry. No computer scientist is confused about string being a physical thing. No organic chemist is confused by the "organic" label on their food.
My takeaway is that we should start asking mechanical engineers to "reverse a string" in their interviews, though.
How is that relevant here, given that I said I preferred one definition over another?
Did I say I was confused? Did I even imply that others might be confused?
Did you somehow think I was unaware that some words have multiple meanings, or did you just ignore that which didn't fit how you chose to read my comment?
Does it matter that you prefer one definition over another? If you want to talk to other people, you have to use their definition.
Every time organic food is mentioned on HN, someone is quick to point out "haha does that mean food that contains carbon haha", and the word simply doesn't mean that in this context. It's tiring.
>Does it matter that you prefer one definition over another?
Well, (obviously, since I bothered to post about it) yes it does -- to me.
Are you somehow claiming that I must prefer something just because it's in the vernacular?
>Every time organic food is mentioned on HN, someone is quick to point out "haha does that mean food that contains carbon haha", and the word simply doesn't mean that in this context. It's tiring.
Well, "organic" does (you know, ISTR someone saying that words sometimes have multiple meanings. I wonder who that could have been?) mean "contains carbon."
Perhaps you should have a nap now, as you seem to be a little cranky.
I think people are desperately trying to figure out what your point is. Are you trying to demonstrate that you know what the word "organic" means? Or are you just talking about things you like? Do you like ice cream?
>I think people are desperately trying to figure out what your point is.
In case causality is an unfamiliar concept, my point was to reply to another comment[0] (which made a value judgement vis-a-vis the "legal" definition of the word) with my thoughts.
Desperately? Really? That assertion is right up there with "Bad grammar is the leading cause of death in the Western Hemisphere." In case my point isn't clear here, I'll clarify by saying that both are ridiculous assertions.
>Are you trying to demonstrate that you know what the word "organic" means?
Nope. Just expressing myself.
I'm really not clear why some folks are so put off by dictionary definitions, especially something so uncontroversial. Perhaps some folks (like myself) have way too much time on their hands.
>Or are you just talking about things you like? Do you like ice cream?
Actually, I said prefer, not "like." While there is some confluence in meaning there, those are not synonyms.
And yes. I am fond of ice cream. Thanks for asking!
As a general rule, any project that mixes proprietary software in an "open source" repo (like the cal.com example) is a potential landmine. You have to be extra careful if you try to re-implement a proprietary feature since cloning the repo necessarily pulls in the proprietary bits. It's better to treat the projects as if they are proprietary,
As an open source project maintainer [1] with a set of proprietary add-ons, I totally understand the project maintainer desire to have a single repository with a single version, single build system, and a single place for issues.
I've considered doing the same thing, but it's all the legal complexity that stops me, doesn't seem worth it.
For sure, In my opinion I think this is totally fine as long as it's clearly specified in the likely first point of contact (Generally the readme on GitHub) & license file and as long as the other licenses aren't breached upon clone/download of the source alone, potentially acting as a license trap.
Absolutely. With that cal.com example it took me quite a while to check that (by my own interpretation) a fork/clone won't instantly be against their license terms since the legal-writing can be hard to fully interpret. In addition, this is not mentioned in the `License` section of the readme, you're required to dig down a layer.
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.)
> MongoDB promoted itself as OS, but does not even look at pull requests.
I wouldn't fault MongoDB for that. Open Source doesn't mean open collaboration. Situations like this could be avoided if GitHub provided an option to disable PR's.
I'd like that for some cases. Why should the socialising happen in my repo, couldn't it happen in the repo of other people who are developing on top of my work? (ie the forks)
I dunno if the author is here, but regardless, I have one additional project to name and shame: Qt. Honestly, Qt's misrepresentation of open source is so bad that it truly ought to be against the law.
Here, see for yourself some of the tactics they use:
> 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:
> 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.
Agreed, I love Qt and use it a lot. But they triple license it (GPL, LGPL, Commercial) and then strongly imply that you need a Commercial license to develop any commercial software with it.
That's just not the case. You are perfectly free to choose the GPL or LGPL license for commercial development, as long as you understand and fully comply with the selected license.
I don't blame them for trying to limit their binary installers to paid customers or registered users, but building from source is always an option, and gives you more control over dependencies and library versions anyway.
You don’t have to use the sdk install and probably don’t want to if You’re developing Qt OSS software. Target the distribution or build it Yourself. https://wiki.qt.io/Get_the_Source
I’ve been doing that, too. Hell, I’ve got SDK builds so small that they work great on Github Actions. And obviously, on Linux, you can just grab dev files and Qt Creator right out of your repos, making it even simpler.
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.
Hi Peer, to confirm again, anything below is my own non-legal-expert understanding/interpretation.
So the new wording is as follows:
>> 1. Clone the repo into a public GitHub repository (or fork https://github.com/calcom/cal.com/fork). If you plan to distribute the code, keep the source code public to comply with AGPLv3. To clone in a private repository, acquire a commercial license)
This does not clarify anything and still (IMO) misrepresents the AGPLv3 on a couple of accounts:
1. I don't see how the AGPLv3 requires me to keep the source code public upon distribution, instead I would need to provide the source code (and adhere to the other terms of the license) to those I distribute to (Including via network use). Sure, if I was to distribute to the public I'd have to then provide sources in some form publicly, but otherwise not. Of course, in a more private scenario, the code could then be made public and shared by one of the users I distribute to.
2. This line still insists I have to acquire a commercial license to clone to a private repository. This was my original query as I don't understand why the license would require this, or how the license may differentiate between a private clone to my PC vs a private repo on GitHub as you suggested by your own interpretation.
I have no issues with the AGPLv3 itself, it's a great license but I have an issue with licenses being misrepresented.
>> 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.
Then why have this line, containing a link to your sales page, in the development instructions of your repo? That line won't stop Amazon but the license terms are already set in the project license. The line, in my opinion, only serves as misrepresented license scare mongering.
The Amazon scenario is more nuanced than that, they have forked to their own offering which currently remains open source (OpenSearch). They could effectively do the same with an AGPLv3 project such as yours, albeit with slightly different requirements, primarily ensuring the continued freedom of the code itself to users. The AGPLv3 does not specifically protect your SAAS business, it's designed to protect the freedom of the code itself. That's why elastic has since moved to non "Open Source" licenses which specifically prevent SAAS use, and why other projects use the commons clause.
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.