> All content that resides under the "ee/" directory of this repository, if that directory exists, is licensed under the license defined in "ee/LICENSE"
Doesn't that make it "open-core"?
Doesn't that make it "open-core"?
My philosophy for both creating & consuming OSS: the core needs to (a) have an OSI-approved license (read: no BSL, SSPL), (b) needs to be useful without the closed source component, and (c) needs to be easy to run without the closed source component. Otherwise, see [1]. I also avoid AGPL, even though it is OSI-approved.
TC has a good take on the economics of fully open source companies [2].
[2] https://techcrunch.com/2014/02/13/please-dont-tell-me-you-wa...
I could use a script to git clone without a directory so I can view these offline. :)
Some have empty ee directories set up in anticipation of doing this in the future.
I don't know if it's to trick people into becoming tainted by it or to increase acceptance, but it no doubt tricks people into downloading and viewing source-available proprietary code. It's one feature of a monorepo that I see as a disadvantage that has further had me be more of a microrepo guy. :)
If it's source available for a security reason I prefer it to be in its own repo like Tarsnap. https://www.tarsnap.com/open-source.html Here's the source available one: https://github.com/Tarsnap/tarsnap Here's the list of repos with some various open source ones to show it's open core: https://github.com/Tarsnap That's a proper Open Core repo.
GitLab FWIW follows, maybe pioneered, this ee directory model, so though there's a lot I like about GitLab they get this thing about Open Core wrong IMO.
* You can see the source, but it's still closed in terms of what you can do with it, so I am comfortable using "closed source" and "proprietary" interchangeably when talking about source available code.
I don't have a problem with open-core software, but please, be open about it and show a feature matrix of how the different versions compare.