# What does Privacy Guides see as OpenSource? **URL:** https://discuss.privacyguides.net/t/what-does-privacy-guides-see-as-opensource/20230 **Category:** Site Development **Created:** 2024-08-21T14:24:09Z **Posts:** 102 ## Post 1 by @Niek-de-Wilde — 2024-08-21T14:24:09Z Continuing from this discussion: > [@Grayjay (Frontend)](https://discuss.privacyguides.net/t/grayjay-frontend/14616): > > [https://grayjay.app](https://grayjay.app)[https://www.youtube.com/watch?v=5DePDzfyWkw](https://www.youtube.com/watch?v=5DePDzfyWkw)[https://www.youtube.com/watch?v=nMSO1TiTW4E](https://www.youtube.com/watch?v=nMSO1TiTW4E) Open source is a complex term with lots of different takes that depends on what kind of perspective one looks from. For some open source simply means that you can check the source code. For the other the exact license about what one can do with that code matters (FOSS vs open source). Another thing to keep in mind is whether we care about reproduceable builds, so a user can make sure that the source code that is published is the exact same as the one that’s used in the published application. Seeing as we have multiple categories where open source is a requirement, we would do good with an exact definition about what Privacy Guides see as “open source”. I would like both the communities and the [@team](/groups/team) 's opinion on this. --- ## Post 2 by @asanyan — 2024-08-21T14:32:45Z > This video has been removed for violating YouTube’s Community Guidelines Anyway, OSI definition which is mostly equivalent to the definition of free software. Grayjay is source available and therefore shares the potential privacy/transparency benefits of FOSS but not the maintainability benefits because forks cannot be monetized due to the noncommercial license EDIT: to be clear, my opinion is that Grayjay ~~is fine, but~~ (edit2: nvm, I dont like it anymore) it’s neither free, nor open source. --- ## Post 3 by @dngray — 2024-08-21T14:39:04Z I think licensing doesn’t really matter a whole lot in terms of why we care, ie _verification_ a product _is what it says_. That means even something under a less-free license but is open source is technically open source but not what we want to see. What I think matters to us is transparency, so code being in a living source repository is better as it’s unlikely to differ to much from a tagged release. --- ## Post 4 by @Niek-de-Wilde — 2024-08-21T14:43:46Z Well this was one of my first stances as well, But then something else hit me. In general, we try our best tor recommend products for a long term. Readers shouldn’t have to worry whether todays recommendation is gone the next day, to a certain degree at least. Having a license that allows a project to be forked, whether commercially or not, does allow projects to continue it the case of a sellout or a company going bankrupt, see Simple Mobile Tools/Fossify as an example. I haven’t made up my mind about this yet, but it does make me wonder if just being able to read the code is all that should matter to us, or if we should think about more. --- ## Post 5 by @Niek-de-Wilde — 2024-08-21T14:46:30Z --- ## Post 6 by @dngray — 2024-08-21T15:00:18Z > [@Niek-de-Wilde](#): > > In general, we try our best tor recommend products for a long term. Readers shouldn’t have to worry whether todays recommendation is gone the next day, to a certain degree at least. I also agree with that, which is why I am unlikely to support adding products which don’t have a living source repository, aka Skiff. > [@Niek-de-Wilde](#): > > Having a license that allows a project to be forked, whether commercially or not, does allow projects to continue it the case of a sellout or a company going bankrupt, see Simple Mobile Tools/Fossify as an example. It’s a nice idea, but it depends on what it is entirely whether or not a fork will materialize, not just the licensing. --- ## Post 7 by @HushedWave — 2024-08-21T15:16:42Z I don’t see PG as having a different definition of OpenSource than accepted standards - or at least - I don’t think them adopting one would benefit anyone. I think instead the question should be: when PG requires Open Source on a product, what is the benefit they’re seeking and can it be achieved by other licensing options? As I understand it, the benefits that PG seeks are: 1. Code auditability. a. The ability for anyone to go in and verify that nothing fishy is being done privacy-wise, and security measures are properly implemented. b. Not to be confused with getting professional audits, which should still be desired in many cases. 2. Reproducability. a. The ability to build the code yourself, to ensure nothing has been injected into the publically released binaries. 3. Longevity. b. As Niek just pointed out, the ability to fork the project if the original developer goes rogue or abandons the project. I think for anything to meet points 1. and 2., it would be acceptable to get away with only requiring Source Availability. But indeed, to meet point 3., a true Open Source license OR a special Source Available license with a killswitch that accounts for abandonment or rogue behavior is necessary. But one could argue that most things only need to meet point 1., with more sensitive things (Or situations where you may not trust that additional code isn’t being injected during the private build process ) also needing to meet point 2. Meanwhile point 3. probably only needs to be met when it comes to offerings where long-term use is expected and/or use wouldn’t be able to continue without the original developers - and largely that means cloud offerings. Though it’s worth noting that projects tend to die when the original contributors disapear anyway, so even though the ability fork may be there, it may not actually extend the life of a product. Tools like Youtube frontends, Android Keyboards, Markdown-compatible note taking apps, basically any offline tool, etc… can either be easily replaced - or just continued to be used without updates. --- ## Post 8 by @sgp — 2024-08-21T15:25:55Z Personally, I see three broad tiers: 1. **Code-available**. You can see the code, but it’s difficult to do anything with it due to license restrictions, missing components, or near-impossibility of trying to host/use it from source. This isn’t “open-source” but it might be better than completely non-public code. 2. **Open-source without reproducible builds**. The code is available with an appropriate license. Due to political disagreements, this includes both permissive licenses (like MIT) and restrictive, copyleft licenses (like GPLv3). It doesn’t include other licenses that aren’t deemed open-source by a leading organization. In practice, it probably should be [this specific list](https://opensource.org/licenses). Open-source is better than code-available for verifiability, since a user is at least allowed to build things themselves, even if most users rely on a binary. 3. **Open-source with reproducible builds**. The same as #2, except the builds are reproducible for a high degree of verifiability. For a points evaluation system, 3 \> 2 \> 1. If open-source is a requirement, then the software should at least qualify for #2. For very competitive ecosystems (such as VPN clients), it’s probably best to push for #3 in the medium-term. --- ## Post 9 by @gregandcin — 2024-08-21T15:30:38Z > [@dngray](#): > > It’s a nice idea, but it depends on what it is entirely whether or not a fork will materialize, not just the licensing. Its not just being able to fork, its for other projects to be able to make something new without having to reinvent the wheel. While I think that apps from FUTO are great alternatives to Big Tech services, they are not open source and FUTO does not call them open source currently. Their business model is great for auditing code, contributing upstream, and trying to keep the business alive since they want people to pay for software. Source available without a killswitch means the software is basically dead in the water if we believe that the company will eventually go under (as many do) or get bought out (unlikely in the case of FUTO as they are funded by a sole multi-millionaire and paying users). --- ## Post 10 by @exaCORE — 2024-08-21T15:35:25Z Whatever decision is made, I don’t think PG should try to redefine Open Source which already has an accepted definition. > [@HushedWave](#): > > Available license with a killswitch that accounts for abandonment or rogue behavior is necessary. A service or software can become crappy without ‘going rogue’ or triggering a killswitch, thus necessitating a fork --- ## Post 11 by @overdrawn98901 — 2024-08-21T15:59:05Z I think the term “open source” muddies, confuses, and brings a a false sense of 100% confidence to users. There are simply different licenses which do or do not provide source code. They will mean entirely different things depending on where the application is ran and how you interact with it. I find these things important. Different licenses dictate how I use and run the software, and contribute to threat models. These discussions come alive with how we interact with the software. Linux can run proprietary blobs of software because of GPLv2. I get to access the source code of a website that is running AGPL for audit. I get to compile and run MIT software on my machine knowing I can use it however I want, and Microsoft gets to pack telemetry in the binary they provide for the same MIT software where they wrap extra code around it. These are all quite different scenarios which require a basic understanding of what to expect with the licenses. --- ## Post 12 by @asanyan — 2024-08-21T16:04:47Z Never thought I’d say this but at this point, free software is probably the less confusing term. --- ## Post 13 by @Niek-de-Wilde — 2024-08-21T16:16:04Z I don’t know if you have ever joined a few linux based subreddits, but there several people/organizations claiming it means something different, which is the entire issue here, we want to specifically define what privacyguides means when we say “opensource”. This way we can move more easily forward when we are reviewing new software or services to add. Edit: once this discussion is said and done, a knowledge base article on the topic with an explanation of our stance might be a good idea. --- ## Post 14 by @gregandcin — 2024-08-21T16:21:37Z I know people like Libre Software, but its not the most popular term --- ## Post 15 by @ph00lt0 — 2024-08-21T16:33:49Z > [@Niek-de-Wilde](#): > > Having a license that allows a project to be forked This is mostly important when there is no company behind the service imho. For products where a paid service is provided this seems less relevant to me. --- ## Post 16 by @ph00lt0 — 2024-08-21T16:35:45Z Isnt there also **source available with reproducible builds**? --- ## Post 17 by @anon80779245 — 2024-08-21T16:40:23Z Here is an interesting [article](https://jrtechs.net/open-source/foss-vs-floss) about the difference between FOSS and FLOSS On an aside note, if we decide to follow the [OSI](https://opensource.org/osd) definition of open source, we should clarify whether we also incorporate the non-discrimination principle. This principle basically says that you cannot state who and who cannot use your software. So you cannot say that companies shouldn’t use your software or that your software shouldn’t be used by the governments, by the army or for things you don’t like, like warfare, human rights violations, etc. --- ## Post 18 by @anon55464882 — 2024-08-21T18:07:00Z In my opinion, it is not within the purview of Privacy Guides to redefine the term Open Source, particularly given the existence of a widely accepted definition established by the OSI. Such redefinition could lead to confusion and misinterpretation. I think the open source ecosystem would be better served by adhering to a unified definition, rather than allowing for individual interpretations. In the case we choose to establish distinct criteria for our conceptualization of Open Source, it would be reasonable for us to adopt a different term. Conversely, if we decide to align with the OSI’s definition, we should communicate this alignment. --- ## Post 19 by @Niek-de-Wilde — 2024-08-21T18:16:21Z Well its not that we are trying to redine it, its that its currently not clear what is what, do we follow the OSI, the FSF, make our own definition? The problem as with most software is that there are multiple people and organizations who claim the they are the defacto standard. What we try to do is to define what we will adhere too. --- ## Post 20 by @anon80779245 — 2024-08-21T18:24:30Z I am not sure the OSI definition is reasonable to follow in our context. Technically, any license that states that no entities on the US embargo/blacklist can use/obtain the software, is against OSI principle of no discrimination. In all practical manners though, we shouldn’t except companies to not follow US law (or appear not to). I am not sure it’s a requiremen to bar US-blacklisted entities to use the software, but that’s why big companies like NVIDA have a special custom license. --- ## Post 21 by @anon63378630 — 2024-08-21T18:36:12Z If it ain’t an OSI approved license it isn’t “open source”. Otherwise it is “source available”. No license or “AS IS” is proprietary and [the source] shouldn’t even be looked at. --- ## Post 22 by @anon55464882 — 2024-08-21T18:37:45Z I didn’t mean to suggest that the OSI definition is the preferred approach for Privacy Guides. I was merely trying to convey that if we choose to use the term Open Source for our needs, we ought to adhere to it. --- ## Post 23 by @jonah — 2024-08-21T18:52:26Z For the purposes of our criteria, when we use the term “open source” on the website it should be referring to the OSI definition. Keeps it dead simple. For the purposes of _evaluating_ tools, as a community & team we can use more nuance and we should evaluate software like this from best to worst: 1. Copyleft (GPL etc.) software meeting FSF free software definition 2. Software meeting OSI _open source_ definition 3. FUTO/“Source First”-type software 4. Proprietary, source available software 5. All other proprietary software _ **However,** _ as we have always maintained, **all five of these software types are acceptable on Privacy Guides.** This is simply the order of preference for the _specific_ factor of “licensing” which we _do_ indeed consider. **All other things equal** , open source software will **always** be better than proprietary software. However, there are also many cases where proprietary software is better than open source software for other reasons, and that will tip the scales. That’s unrelated to this conversation though. * * * PS: The reason I think we should prefer copyleft over open source **when evaluating two otherwise identical tools** is that I think the FSF is correct that they protect user rights and developer rights better, and therefore should be more stable from a long-term perspective. --- ## Post 24 by @overdrawn98901 — 2024-08-21T21:03:19Z I overall agree with this approach and mentality. However, we should explain why this flow down is preferred, as well as common false assumptions about privacy as it pertains to interacting with the running program built with the code. --- ## Post 25 by @jonah — 2024-08-21T21:46:30Z I’m not totally convinced that the license is something people really need to think about when they’re deciding what software to use, so no explanation or article about this topic seems necessary. As _reviewers_ it is useful _for us_ to consider these things because it gives us an indicator of the quality and long-term availability of the software. It is also of relevance to software developers, which most readers are not. I think that people reading Privacy Guides should concern themselves with other factors of more importance, and generally want us to have considered all the minutiae of non-privacy-related things like software licensing before we list a tool on the site in the first place. --- ## Post 26 by @Niek-de-Wilde — 2024-08-21T22:08:54Z One issue with this is while those are indeed acceptable as a whole, some specific criteria mandate open source so no propreitary software. Here comes in one of the sparks of this thread: Grayjay. If you follow the “we can read the source” mantra, it qualifies as open source and can be added to the frontend page. If we follow the mantra that it also needs one of the few licenses under the OSI, then its not open source and cannot be added. This is why, for pages with an open source criteria, we need to define what mantra of open source we follow, from which of the above described levels do we consider it “open source”. If we are indeed dead simple going to follow the OSI definition, that would be fine by me, but it shoulf be documented and known for future refrence when we look at new software. Because with the OSI definition, Grayjay cannot be added to the frontend page (unless we change the criteria). --- ## Post 27 by @overdrawn98901 — 2024-08-21T22:30:22Z This is a thoughtful take. I agree for Privacy Guides individual license details are not as important. At some point this becomes the responsibility of the user to learn. Maybe this will further discussion: The proposed flow down I think is a good point of reference. I’ll provide my personal flow down as a privacy user as follows: - AGPL, and other like licenses, regardless of usage restrictions (SSPL), if and only if it is a network hosted service (otherwise go to the next flowdown for programs running on my machine) - Any other copy-left license with no usage restriction (GPL) - Any other source available license with no usage restriction (OSI inclusive) - Any other source available license with usage restriction (FUTO, or other license that limits FSF freedoms) - I evaluate this at the same flow down as above realistically - Any other source available license, proprietary restrictions, or just not well defined (WTFPL, BSL, etc) - Any other proprietary license The proposed flow down is how I evaluate usage in the context of a privacy user. To be clear, this is not how I evaluate licenses as a product owner or other use cases of creating new software, and I respect product owners using any license as it makes sense to their bs --- ## Post 28 by @jonah — 2024-08-21T22:45:07Z > [@Niek-de-Wilde](#): > > Because with the OSI definition, Grayjay cannot be added to the frontend page (unless we change the criteria). I think this is absolutely true, yes, and the criteria should be changed if you/we think that Grayjay is a better option than what we currently have listed. --- ## Post 29 by @xe3 — 2024-08-21T23:22:01Z afaik, the open source ‘community’ broadly, the OSI definition specifically, the FSF definition, and even Futo themselves do not consider _source available_ licenses to be _open source_. I think trying to redefine open source to accommodate a single company that chooses not to use an open source license (or for any other reason really) would most likely alienate many Privacy Guides readers as well as regulars/contributors, and has the potential to create an avoidable controversy/harm PGs reputation. I think I agree with @jonah on this, I feel the best approach is to stick with an existing externally defined and broadly known definition of open source. But I also agree (with you) that the definition used by PG should be stated/documented somewhere. I was rightly corrected when I mistakenly referred to Meta’s Llama 2 license as open source, and that license type is more permissive, and more clearly defined than futo’s. I’m kind of agnostic about Grayjay or Futo, but I feel fairly strongly that defining open source is out of scope for PG’s mission, and doing so to accommodate Futo’s source available license type would be a bad look with some reputational risk for PG. > **I think there is also an argument to be made for the modest security benefits of actual open source software over source available.** > > The people with the strongest incentive to read the source code are those who are invested in its quality. That group does include _users_ to a degree, but realistically the vast majority won’t and can’t read the source code and lack motivation, its contributors, downstream projects, and especially those with a strong incentive (such as a financial incentive), that actually make up most of the serious ‘eyes on’ the source code. (Chromium and its downstreams would be one example of this) --- ## Post 30 by @jonah — 2024-08-21T23:28:43Z Semi-relatedly, I’ll also add that if/when FUTO adds text to their license saying unlimited commercial use is allowed _if_ FUTO goes away or whatever (like I believe Rossmann has previously mentioned might be possible?) then I’d personally consider their _source first_ license to be just as good as open source. That is really my only fear with FUTO compared to OSI-compliant software. --- ## Post 31 by @Rasta — 2024-08-21T23:35:47Z He mentions it here: > [@FUTO Keyboard](https://discuss.privacyguides.net/t/futo-keyboard/18896/24): > > FUTO is working on a type of license so that if the software we create is abandoned/goes rogue/we go bankrupt that you can all do whatever the hell you w ant with it. That type of stuff is fairly in the weeds. I also think they’ve mentioned it on the youtube channel at some point but i can’t remember where or when. --- ## Post 32 by @exaCORE — 2024-08-21T23:52:14Z > [@jonah](#): > > Semi-relatedly, I’ll also add that if/when FUTO adds text to their license saying unlimited commercial use is allowed _if_ FUTO goes away or whatever (like I believe Rossmann has previously mentioned might be possible?) then I’d personally consider their _source first_ license to be just as good as open source. I mentioned this earlier, but it seems relevent: A service or software can become crappy without ‘going rogue’ or triggering a killswitch, thus necessitating a fork. Plus, just because a group of developers created the software doesn’t mean they are the best group of people to continue developing it --- ## Post 33 by @Rasta — 2024-08-21T23:59:07Z They’re working on that. It’s a matter of deciding the metrics to meet and how to translate that to a legal document. > [@FUTO Keyboard](https://discuss.privacyguides.net/t/futo-keyboard/18896/25): > > It is on the roadmap to come up with something like a rugpull clause, where if certain metrics are met, you can just do whatever you want to it. It’s more difficult to put this in legalese. Especially when you’re in a building of people who just want to program all day. --- ## Post 34 by @overdrawn98901 — 2024-08-22T03:24:33Z As of now, if FUTO ghosts us, the license doesn’t transfer to anyone, and the software essentially can’t be reclaimed by another group unless the license expires (thanks to Disney, 100+ years lol). Doesn’t matter much for users as the software can still be ran for non commercial usage. However, as a developer, I wouldn’t touch FUTO code with a 10 foot pole. My modifications and distribution now have legal implications that FUTO can enact on me. Perhaps FUTO is trustworthy now, but given that if the copyright fell into a trolls hands, it would not be fun for anyone involved. I don’t want to be near that at all. I’ll let FUTO and FUTO alone build their product. I would only consider running said software with functionality stripping modifications only (removing telemetry). With this, non-FUTO devs cannot contribute back to core unless I’m missing something. When FUTO decides it’s not worth it anymore, then the software likely retires with the license (unless their rug-poll clause makes sense, which is going to be tricky). If they relicense only as it expires or via some rug pole clause, then I can only imagine it continuing on if the product is great quality and has a strong community of devs ready to support. None of these things matter as an end user as of today, but the life of the software can definitely change with this. I’ll be greatly interested to see if this project continues to grow and be prosperous, or if it trails off. I’ll wish FUTO the best at succeeding in their goal. --- ## Post 35 by @Niek-de-Wilde — 2024-08-22T12:31:48Z Okay so basically we decide now that we will follow the OSI definition. So it doesn’t have to be a license under the OSI, but a license does have to be compliant with the OSI definition? That would seem sensible to me. --- ## Post 36 by @HushedWave — 2024-08-22T14:07:41Z > [@jonah](#): > > For the purposes of _evaluating_ tools, as a community & team we can use more nuance and we should evaluate software like this from best to worst: > > 1. Copyleft (GPL etc.) software meeting FSF free software definition > 2. Software meeting OSI _open source_ definition > 3. FUTO/“Source First”-type software > 4. Proprietary, source available software > 5. All other proprietary software I think this is the key, PG doesn’t need to use it’s own definition of Open Source, but it’s probably worthwhile to change some of their “must be open source” requirements to “must be Source Available or better…”. Though some types of software/service may still warrant requiring strict Open Source. --- ## Post 37 by @starkle — 2024-08-22T17:10:20Z I think it is a myth that open source software has more longevity, just like it’s a myth that open source software is more secure. Sure, you can point to cases like Simple Mobile Tools where the libre license allowed it to live on as Fossify. But you can point to _countless_ other cases of abandonware sitting next to a OSI-approved LICENSE.txt. When it comes to longevity what matters is **developers** having means and incentive to build the software over extended periods of time. “Open source” can be great for that. Look at Linux. There’s massive commercial and volunteer interest in contributing to an open kernel over time. But the key is exactly the developer interest, not the open development model per se. All in all here’s my thoughts on Open Source at the moment: - Security: Not important but can be helpful when auditing, submitting patches, etc. - Privacy: Not important. - Longevity: Not important. - Freedom: Important but that’s not what PG is about. If vendor lock-in is a concern then open source is a small piece of the puzzle. Developer interest, use of open standards, ease of migrating to a new service, etc matter far more. For example a proprietary email client isn’t a big deal, because it’s all just IMAP and stuff. If longevity was the motivation behind an open-source criteria, I think that should be seriously reconsidered. --- ## Post 38 by @exaCORE — 2024-08-22T17:12:34Z > [@Niek-de-Wilde](#): > > So it doesn’t have to be a license under the OSI, but a license does have to be compliant with the OSI definition? Are there many situations where that comes up? --- ## Post 39 by @starkle — 2024-08-22T17:22:56Z Aside: In defense of Source First “Source first” is a novel approach to the longevity problem. FUTO has incentive to build quality apps knowing they can charge for the software, since the license doesn’t let users get around it. By paying for the software, users get almost all the benefits of Free Software. - Can _use_ the software for _any_ purpose. - Can _copy and modify_ the software for _non-commercial_ purposes. - One restriction: Can’t tamper with functionality related to paying for the software. (My paraphrasing of [FUTO Source First License 1.0](https://gitlab.futo.org/keyboard/latinime/-/blob/master/LICENSE.md), I am not a lawyer) It seems people have an emotional reaction to a company benefiting from open development model without extending the same freedom to contributors, but I don’t think Source First is supposed to be an open development model. All development is done by FUTO (just look at commit history). The source code is published and licensed quite generously as a selling point for end users, not as a way to trick volunteers into providing free labor. Sure it’s an unproven licensing model but a promising one if you ask me. --- ## Post 40 by @anon63378630 — 2024-08-22T17:54:04Z > [@starkle](#): > > I think it is a myth that open source software has more longevity I recently had a hardware-based personal side project I made, and to make it easier I searched around for some code to get a better grasp on the necessary ioctls and upload handling to the device. I found an excellent program that was long dead but still was extremely helpful. It is/was twenty-three years old, but it still worked and I could use it since it was GPL-2.0 licensed. Just a small anecdote. --- ## Post 41 by @starkle — 2024-08-22T18:18:06Z Fair anecdote. I guess my point was more about the ongoing development of software. Specific open source releases live forever, so to speak, and that’s worth something. But ongoing development of software is what I think Privacy Guides is concerned about when making recommendations. --- ## Post 42 by @overdrawn98901 — 2024-08-22T20:31:07Z I’d agree with you that the software license does not actually guarantee anything for privacy. However, the code allows us to have confidence in evaluating specific privacy related aspects of the software which we have to trust otherwise. For example: telemetry. Privacy policies may be hand-wavy in terms of what data is sent. If we have the source code, we can exactly determine what that data is. Trust is regarded as something to avoid in threat models, so the more we can remove trusted entities or gain more confidence, the better. PG is good at balancing this. Source code is just one metric in the analysis. --- ## Post 43 by @Niek-de-Wilde — 2024-08-23T11:11:04Z Made a draft PR to move this forward: [docs: Define the term "open source" by blacklight447 · Pull Request #2732 · privacyguides/privacyguides.org · GitHub](https://github.com/privacyguides/privacyguides.org/pull/2732) I added the following: - **Source Availability** : Open-source projects are generally preferred over equivalent proprietary alternatives. Our definition of Open-source follows the [OSI definition](https://opensource.org/osd). Licenses not under the OSI are allowed as long as they are compatible with the OSI definition. Open-source part is only mandatory for pages with “Open-source” as a minimum requirement. If we move forward with this, we should overlook all pages with opensource requirements and check the currently listed software --- ## Post 45 by @overdrawn98901 — 2024-11-23T14:26:14Z Personally, I think the outcome will be a less strict version of the OSI definition, so in its current form it’s likely more strict. For this reason it’s fine to leave as is. --- ## Post 46 by @anon48875053 — 2024-11-23T14:28:22Z There are two ways to protect developers work from being exploited by corporations: 1. Copyleft. 2. [sourcefirst.com](http://sourcefirst.com) I don’t agree that we should follow OSI definition. --- ## Post 47 by @Niek-de-Wilde — 2024-11-23T14:29:53Z The issue mostly comes down that it will impact in what kind of software can recommend. The OSI is a popular interpretation. However take a look at Grayjay. Its looks like a neat and private app, I can check the source code to see anything fishy is going on. However, under the OSI definition, we could not recommend it as it does not follow the OSI definition of open source. We would prevent a good app to be recommended with this, which would be a reason against this. On the other hand, we have the recent RaivoOTP situation, which was sold , and shortly after turned to shit and broke peoples OTP codes unless you had a premium subscription. Having the app be opensource under the OSI definition, folks could have forked it and moved their backups to the new fork without having to change their workflow/get used to a new app(espeically important for old folks). Its a delicate balance, but an important one. --- ## Post 49 by @Niek-de-Wilde — 2024-11-23T15:44:56Z While I can see where you are coming from and agree with your sentiment, one issue that comes with this approach is complexity. A lot of people are not even in the know about what open source software even means. Also it leaves a lot of room for potential flamewars about what kind of open source matters for which category, and why. This is why I would personally lean more towards a singular definition to follow, be it the OSI or something else, and follow that. While it is problematic that we have not defined this yet, I do not think that its so important that we have to immideatly freeze this requirement everywhere on the site, as it does not have that much of an privacy impact to the currently recommend software. All software thats recommend is open and can be read to a large decree to check for nasty stuff, this is most a discussion about licensing. --- ## Post 50 by @anon48875053 — 2024-11-23T16:02:05Z I mean, even F-Droid doesn’t just stick with one definition: > To determine which licenses are FLOSS, We defer to widely trusted organizations that have a proven track record. Specifically, we acknowledge these standards: [DFSG](https://wiki.debian.org/DFSGLicenses), [FSF](https://www.fsf.org/licensing), [GNU](https://www.gnu.org/licenses/license-list.html), and [OSI](https://opensource.org/licenses) _(read a quick overview of them all on [SPDX](https://spdx.org/licenses/))_ . Requiring the use of either OSI-approved or source first license would make the most sense. --- ## Post 51 by @anon80779245 — 2024-11-23T16:12:05Z > [@anon48875053](#): > > There are two ways to protect developers work from being exploited by corporations: > > 1. Copyleft. > 2. [sourcefirst.com](http://sourcefirst.com) > > I don’t agree that we should follo This is wild. Licenses like AGPL v3 prevent any companies to use their code without republishing it, even if it’s a cloud or web based service. --- ## Post 52 by @anon48875053 — 2024-11-23T16:13:30Z AGPL is literally a copyleft license. > **[What is Copyleft? - GNU Project - Free Software Foundation](http://www.gnu.org/licenses/copyleft.en.html)** --- ## Post 53 by @anon80779245 — 2024-11-23T16:16:01Z Okay, so why do you mislead people into believing OSI OSS definition isn’t covering copyleft licences? You previously said that “source first” is better than open-source, contardicting your current statement. --- ## Post 54 by @Niek-de-Wilde — 2024-11-23T16:18:54Z Hmm, this is another model we could follow indeed " licenses that follow the OSI and these other license:" where we could include futo’ s license. Only issue i could see with it is that folks can start flamefests to get other licenses added. --- ## Post 55 by @anon29374801 — 2024-11-23T16:46:58Z I like this. It would create a massive change to the work flow though. 1 - any tool that uses open source would need to show which definition is used as the criteria. 2 - Any suggestion of a new tool would need which definition should be used clearly stated and agreed upon as well. 3 - there would need to be a review of tools that have an open source criteria, decide on which definition that category should use, and evaluate if each tool still meets it. --- ## Post 56 by @Niek-de-Wilde — 2024-11-23T16:51:09Z Changes to our workflow and some extra work is alright with me. Its just that what needs to be done is clear as day so everyone can be on the same page as how we move forward. --- ## Post 57 by @anon29374801 — 2024-11-23T16:51:58Z This kind of commitment is admirable. Its why the PG team does so well. --- ## Post 58 by @Rasta — 2024-11-23T18:17:03Z What about requiring Source First recommendations to have rugpull clauses? Futo stated that they were working on implementing them so that if they ever went bad or sold out their software would default to OSI. --- ## Post 59 by @Niek-de-Wilde — 2024-11-23T18:37:50Z Do you have any links to examples where this explained more? --- ## Post 60 by @anon48875053 — 2024-11-23T18:39:42Z I could only find this: [FUTO Keyboard - #25 by louis\_rossmann](https://discuss.privacyguides.net/t/futo-keyboard/18896/25) --- ## Post 61 by @Niek-de-Wilde — 2024-11-23T18:43:07Z Same here, but is says its still a work in progress here. Maybe I ll reach out to him. --- ## Post 62 by @anon80779245 — 2024-11-23T19:14:26Z Look, open-source is pretty well defined. We shouldn’t “reinvent the wheel”. --- ## Post 63 by @Niek-de-Wilde — 2024-11-23T19:16:51Z Thats the issue, some people think its defined, while some don’t. So see it simply as access to the source code so they can read it, some require it to be copy left. Both are valid in my opinion, but it is an important distinction that has to be made. --- ## Post 64 by @Rasta — 2024-11-23T19:18:51Z I think they mentioned it in the Livestream discussing Source First as well. --- ## Post 65 by @anon80779245 — 2024-11-23T19:19:07Z > [@Niek-de-Wilde](#): > > So see it simply as access to the source code so they can read it, some require it to be copy left. Sorry, but no one is considering sources available software as open-source. Even FUTO renamed their product to source-first (they previouslysaid it was open source) so they don’t claim themself as open source. --- ## Post 66 by @Rasta — 2024-11-23T19:22:28Z Source First, with protections, is objectively better than Open Source because it doesn’t allow for exploitation of developers and commuities. Requiring outside monetezation of the code to be paid for just makes sense. --- ## Post 67 by @Niek-de-Wilde — 2024-11-23T19:27:38Z I am not just talking about FUTO though, it is just an interesting example. The fact is that how much people like to claim that it is defined, it is not. There are several ways of interpreting it, and I would personally sad if we loss quality alternatives which are private and secure simple because they do not include an OSI license. --- ## Post 68 by @anon80779245 — 2024-11-23T19:27:38Z > [@Rasta](#): > > Source First, with protections, is objectively better than Open Source because it doesn’t allow for exploitation of developers and commuities. Requiring outside monetezation of the code to be paid for just makes sense. Even if True, this is beside the point. Open source has it’s pro and cons, and we aren’t here to judge them. Developers can choose. BTW it is totally fine to say we can accept source first, we just shouldn’t call it open source. --- ## Post 69 by @anon80779245 — 2024-11-23T19:29:11Z > [@Niek-de-Wilde](#): > > The fact is that how much people like to claim that it is defined, it is no The wiki is pretty clear. [Open source - Wikipedia](https://en.m.wikipedia.org/wiki/Open_source) --- ## Post 70 by @anon48875053 — 2024-11-23T19:32:36Z Open source is defined by OSI. Free software is defined by FSF. Source first software is defined by FUTO. We should require software to either be open source or source first. --- ## Post 71 by @phnx — 2024-11-23T19:37:08Z That is my feeling as well, I am confused at the claims otherwise. > [@Niek-de-Wilde](#): > > I am not just talking about FUTO though, it is just an interesting example Futo is far from the only example. Take Redis for example. It would have been better for their publicity to pretend they were still open-source under their new license structure, but they didn’t do that because no one sees source-available software as being open-source. [Source](https://redis.io/blog/redis-adopts-dual-source-available-licensing/). --- ## Post 72 by @anon48875053 — 2024-11-23T19:41:26Z In my opinion source-available isn’t anywhere close to being open source, but source first is. Honestly, source-available software shouldn’t be accepted on PG. --- ## Post 73 by @Niek-de-Wilde — 2024-11-23T19:42:21Z The OSI is the steward of the OSD, which the most common, but ultimate just 1 of the most common Open source definitions. See: [Open Source Initiative - Wikipedia](https://en.m.wikipedia.org/wiki/Open_Source_Initiative) --- ## Post 74 by @phnx — 2024-11-23T19:43:52Z What does Open-Source mean? ( **YOUR VOTE IS PUBLIC** ) _Poll: Poll (view on site)_ I couldn’t edit the original poll so I remade it here, I understand it is impossible to add all the options people would like to see but hopefully this is good enough. :smile: Definitions: [Open-Source OSI](https://opensource.org/osd) [Source-First](https://sourcefirst.com/) [Source-Available](https://en.wikipedia.org/wiki/Source-available_software) --- ## Post 76 by @win11.shading291 — 2024-11-23T20:05:04Z I think there’s already a recognized definition so why use another one. But I also think PG could recommend Open-Source and/or Source-First Software. There could be a little icon on each recommendation stating if said software is open-source or source-first with the definition included or a link to the definition included. --- ## Post 77 by @Niek-de-Wilde — 2024-11-23T20:40:30Z An icon would be to complex, people should not have to watchout for such minor details on the site. Its icon and description heavy as is. --- ## Post 78 by @ph00lt0 — 2024-11-23T21:19:59Z Hot take coming in. I think there is not such an importance of something being open source at all in privacy space. Dont get me wrong. Open source is a great good which I deeply support and many in privacy space do. I guess we are often the same kind of people caring for these things. Many offerings in the privacy world are also in some way open source which is the reason for these discussions and on my opinion confusion on the importance. The discussion here is mostly held by people who have some strong opinions about open source definitions, but I would argue thet the actual impact for a user and reader of our website is pretty much negligible. We should not be limiting ourselves to projects that are open source at all. In fact we already don’t in several of our recommendations. As I indicated before open source is a great thing, but this discussion is missing out how relevant this all actually is to what level of privacy you get. I see a lot of posts here but none seem to be experts on the legalities of the meaning, making the discussion about the definition to me a bit pointless and overrated. Open source may be a good way of gaining trust when big user groups are there and many contributors are involved. With smaller projects it simply can’t provide guarantees about privacy and future of existence (I observed that these are the factors of importance here). I would not recommend some flaky open source app from small project or business over a robust proprietary app that arguably adequately deals with our personal data. Thus it seems to me that the requirement for being open source should be lifted entirely. We should strive for the best recommendations in privacy and those can be assessed by various other factors. I frankly don’t believe open source to be one. I am confident that many of them will to some extend of definitions be open source too. We however remain a privacy advocacy club, not one for open source, regardless of how much we sympathize with them. --- ## Post 79 by @xe3 — 2024-11-23T21:37:18Z I’m strongly opposed to attempting to redefine and weaken a well established and meaningful term, especially opposed to redefining it to accommodate a single software company’s in-house term for their source-available license. If PG wants to recommend _source available_ (or a subset of source available licenses) software in addition to _open source_ that is fine, but it doesn’t require (or justify) attempting to redefine a useful and broadly agreed upon term. This would invite criticism, conflict, and harm PGs reputation as it harmed Futo’s when they attempted this redefinition. And it would very likely lead to some confusion among readers. (Source Available means something, Open Source means something, redefining Open Source to mean Source Available makes both terms less useful and less clear). I would be deeply disappointed if that comes to pass. Recommending source-available Futo software does not require muddying or weakening the meaning of open source. If that is your goal (and it seems to be) that seems like the wrong approach. It just requires that _in addition_ to recommending Open Source software, there is some flexibility for non-oss but source available software (or closed source software, which PG currently recommends). Maybe that means a simple minimum criteria of source availability, or maybe that means defining some higher bar of source-availability that falls short of open-source, but is more clearly defined and more permissive/transparent than simple source-availability (or maybe just sticking with the status quo of _preferring_ FOSS \> Source Available \> Closed Source, but not hard rule) Essentially that is what Futo is trying to do with their in-house term ‘source first’, it’s a way for them to try to differentiate themselves as _more than just mere source availability_ (while still falling short of open source). I don’t think it would be appropriate to use one company’s marketing term, but I do think that PG could adopt a specific source availability criteria somewhat similar (but hopefully less vaguely, and more objectively defined). In any case, I’d like to see these criteria determined in the abstract and in a consistent way, not with specific products, services, or companies in mind. --- ## Post 80 by @anon29374801 — 2024-11-23T21:44:26Z > [@xe3](#): > > In any case, I’d like to see these criteria determined in the abstract and in a consistent way, not with specific products, services, or companies in mind. This is tough as it seems, to me, that both this discussion and the discussion regarding password managers were solely revived to remove one product (1Password) and not in some good faith attempt at improving clarity or the password manager category. Luckily these discussions seemed to have morphed themselves into something better but, still leaves a bad taste in my mouth. --- ## Post 81 by @Niek-de-Wilde — 2024-11-23T22:00:46Z Well I personally started this thread is to grow PG’s consistancy. I want us to be well thought out and thought through. I personally do not have too much experience in dabbeling with licenses, expext for that I know that it tends to incite intense dicussion. This is why I opened this thread, to ask everyone in this community what they know and fell about open source licenses. There is no outcome for me that especially desired. Maybe we decide to follow the OSI model, maybe we decide to not include open source as a requirement at all, maybe we decide to not use the word open source but require source availability with one of a few licenses attached, who knows. I just want to gather all the information in one place, get a feeling of what the team and community thinks, and go forward with the way that makes to most sense. --- ## Post 82 by @anon29374801 — 2024-11-23T22:05:09Z > [@Niek-de-Wilde](#): > > Well I personally started this thread is to grow PG’s consistancy I understand that but you revived it because of this thread > [@Require Open Source for Password Managers](https://discuss.privacyguides.net/t/require-open-source-for-password-managers/12480/91): > > Why YubiKeys aren’t open-source: Why 1Password isn’t open-source: Which was revived by > [@Require Open Source for Password Managers](https://discuss.privacyguides.net/t/require-open-source-for-password-managers/12480/64): > > Need to revisit this. There are so many open source password managers available now there’s no reason not to make it a requirement. who revived this thread as well > [@Remove 1Password](https://discuss.privacyguides.net/t/remove-1password/13921/39): > > I think it’s time to reevaluate if this closed source password manager is needed anymore. Probably time to make open source a requirement for password managers. Especially since we’re spoiled for options now. at the same time. Hopefully I am wrong but to me it seems like all this happened because one team member decided they did not like 1Password. If this was reversed and a user was attempting to change a criteria to add a tool instead of remove it, it would have (and has) been called out. --- ## Post 83 by @fria — 2024-11-23T22:05:12Z > [@Niek-de-Wilde](#): > > There is no outcome for me that especially desired. Maybe we decide to follow the OSI model I think just keep it simple and use the OSI definition really. No reason to overcomplicate things. --- ## Post 84 by @Niek-de-Wilde — 2024-11-23T22:07:27Z It was revived in the sense that it came to my attention again yes, we have lots of stuff to do on PG and this is on of the many check boxes that still need to be checked, but it was buried for a bit indeed. --- ## Post 85 by @win11.shading291 — 2024-11-23T22:36:54Z The issue is complex because there isn’t always a lot of choices in softwares or platforms to be used. This topic comes to mind: > [@Missing privacy apps](https://discuss.privacyguides.net/t/missing-privacy-apps/20419): > > Are there any privacy apps that you think is missing and needs to be developed? Or a FOSS alternative for proprietary software etc? Please share it below, it might attract developers attention and develop it. I would love to have a straight criteria list for all tools, but it’s simply not possible. There are some category of products that are much more mature then others. I think the approach being used right now on PG, to have a per category criteria, makes the most sense. There could also be a logic applied across the site like when a category is mature enough, meaning it has many options, audits, FOSS options, etc., THEN the category criteria gets stricter. There could be a category maturity level, that isn’t necessarily apparent to the user, but managed by PG internally. Edit: to develop more on the maturity level: Level 1 Maturity - not a lot of options: - Source Available requirement - Criteria 2 - Criteria 3, etc. Level 2 Maturity - more options: - Source-first requirement - Criteria 2 - Criteria 3, etc. Level 3 Maturity - even more options: - FOSS requirement - Audited by whatever authority that makes sense - Criteria 3, etc. --- ## Post 86 by @ph00lt0 — 2024-11-23T22:37:30Z For the definition given this not our field I would agree here with using a defintion of an authority in the respective domain. --- ## Post 87 by @ph00lt0 — 2024-11-23T22:46:14Z But here you are tighing open source as if it has impact on the level of privacy one can assume. More open source (or how you want to call it) does not mean more privacy. This is the reason for my post above. The connection between these that is drawn here is inaccurate and a noncausual relationship. --- ## Post 88 by @phnx — 2024-11-23T23:45:06Z > [@ph00lt0](#): > > We however remain a privacy advocacy club, not one for open source, regardless of how much we sympathize with them. This is a concerning perspective and is the same perspective which has ruined other privacy communities. The notion that privacy or any concept for that matter can stand completely on its own is naive and incorrect. Privacy, security, and open-source are all inherently connected, and attempting to shut down any discourse which strays into these topics because “it’s not privacy” is deeply troubling. * * * Open-source (per the OSI definition) does : - Increase transparency - Increase trust - Increase user freedom - Allow for greater scrutiny of code - Enhance the ease and value of external audits - Enable community collaboration Open-source does not: - Inherently harm or improve security - Automatically result in better or worse software - Guarantee privacy - Eliminate the need for trust I struggle to see how transparency, trust, and freedom are not central to the cause of privacy. Take Linux for example; you cannot chalk the fact that Linux is a more private OS than Windows up to pure dumb luck; obviously, the open-source nature of Linux is responsible. Being open-source, or at least source-available, should not be an unreasonable ask of software which claims to defend the freedoms and rights of its users, nor should it be an unreasonable topic to discuss in this forum. --- ## Post 89 by @ph00lt0 — 2024-11-23T23:57:42Z > [@phnx](#): > > not be an unreasonable ask of software which claims to defend the freedoms and rights of its users, Well only here this part we agree. But the thing is, not all recommendations we have to make will always be of companies who claim this or are that engaged in privacy. More often recommendations can also be on way more generic products who are simply just the best out there for privacy but not much of an idialist firm. This could lead to recommending f.x. shitty linux phones that are not user friendly, not secure, but somehow regarded as privacy friendly and surely more open source. That is not what we want. --- ## Post 90 by @jonah — 2024-11-24T00:11:50Z > [@phnx](#): > > I struggle to see how transparency, trust, and freedom are not central to the cause of privacy. :100: There’s 0 doubt in my mind that open source has inherent privacy benefits. What I don’t understand is people hearing “open source is good for privacy” and taking that to mean that _all_ open source software is better than _all_ closed source software. That seems like a completely irrelevant strawman :confused: * * * I am surprised we are 89 posts deep into this topic and yet nobody seems to have posted any counter arguments to my answer in post [23](https://discuss.privacyguides.net/t/what-does-privacy-guides-see-as-opensource/20230/23), and clarifications in posts [25](https://discuss.privacyguides.net/t/what-does-privacy-guides-see-as-opensource/20230/25) and [28](https://discuss.privacyguides.net/t/what-does-privacy-guides-see-as-opensource/20230/28). I’m still happy with these posts as my answer to this question, and I am still getting the feeling that people largely agree. Can anyone share why they disagree with me, or can we consider this issue resolved? --- ## Post 91 by @jonah — 2024-11-24T00:26:00Z Let me be more clear about my answer here. The question in this thread is very simple: **what does the term “open source” literally mean?** I feel it is my duty to both the open source and Privacy Guides communities to plainly say that I will not accept a situation where we use the words “open source” on the website to mean anything other than the OSI definition. If we _do_ want to talk about source first products, we can use alternative phrases like _source first_, _source available_, etc. There is no issue with that, and never has been. --- ## Post 92 by @jonah — 2024-11-24T00:26:10Z The question posed by this thread is **not** : is open source good? The question is **not** : should we require open source tools exclusively? These questions are (perhaps) worthy of discussion, _separately_. Therefore, I am going to mark the post above as the solution to this topic so people see it. I am doing this because I think we are straying too far into irrelevant topics, when the answer to this is seemingly simple and grounded in apparent consensus. I am not doing this to quell dissent against my opinion, and if you disagree with my answer in this post, please reply. I am happy to un-mark this as the solution if there is more disagreement I’m not aware of. However, if you want to talk about anything related to open source _other than the literal meaning of the words_, please open a new thread instead. --- ## Post 93 by @anon48875053 — 2024-11-24T06:39:53Z Calling FUTO’s software source available is crazy. Source available software is far more restricting than source first and open source. Just because FUTO isn’t going to give a free ride for corporations, their license turns closer to source available than open source? Really? --- ## Post 94 by @anon48875053 — 2024-11-24T06:46:48Z > [@jonah](#): > > I feel it is my duty to both the open source and Privacy Guides communities to plainly say that I will not accept a situation where we use the words “open source” on the website to mean anything other than the OSI definition. > > If we _do_ want to talk about source first products, we can use alternative phrases like _source first_, _source available_, etc. There is no issue with that, and never has been. I completely agree with that, this seems like the best solution. --- ## Post 95 by @xe3 — 2024-11-24T07:02:47Z > [@anon48875053](#): > > turns from open source to source available It can’t turn from open source to anything, it was never considered open source in the first place > Calling Futo’s software source available is crazy. I’m surprised you find my characterization objectionable, let alone crazy, I don’t believe Futo would disagree that their license falls under the umbrella of Source Available. They prefer to use their own term “Source-first” to signify that their license is more than _just mere_ source availability (and I agree with them. As far as source available licenses go, Futo’s seems better than most, which is what they hope to communicate with the new term as far as I understand). I [understand](https://en.wikipedia.org/wiki/Source-available_software) Source Available as a broad category/umbrella term of licenses falling short of of Open Source, but sharing _at minimum_ the characteristic of source availability: > **Source-available software** is software released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified, but without necessarily meeting the criteria to be called open source. > > The licenses associated with the offerings range from allowing code to be viewed for reference to allowing code to be modified and redistributed for both commercial and non-commercial purposes --- ## Post 96 by @exaCORE — 2024-11-24T07:15:46Z IMHO, the ethos of Open Source is that the code in in the commons, available freely for use by all with minimal restrictions on use. The Source First license doesn’t truly place the software in the commons and hence doesn’t truly share even the same philosophy as open source. To be clear, I agree with @xe3 that the source first license is better than most other source available licenses but that doesnt make it open source. --- ## Post 97 by @anon48875053 — 2024-11-24T07:20:06Z I don’t believe that FUTO’s license should be called source available just because they don’t allow distribution for commercial purposes. It’s a lot closer to open source than to source available, but in the end it’s source first. Just like everyone didn’t want FUTO’s software to be called open source, I don’t think we should call it source available because both are incorrect, FUTO’s software is source first, and they even trademarked that definition. --- ## Post 98 by @anon80779245 — 2024-11-24T09:21:31Z > [@phnx](#): > > What does Open-Source mean? ( **YOUR VOTE IS PUBLIC** ) > > - Votes > > - 79% The result of the poll are pretty clear, people think we should stick with OSI definition. This should be reflected in our general criteria. --- ## Post 99 by @overdrawn98901 — 2024-11-24T14:58:51Z While I agree, I think most of this confusion is greatly resolved by posting the definitions of each. - [Source First](https://sourcefirst.com/) - [Source Available](https://en.m.wikipedia.org/wiki/Source-available_software) In terms of pure software freedom, both have restrictions on usage by specific entities, so that is where they both fall short of OSI. However, source available is often used by mega corps as switch and bait after initially being OSI, which is usually a shit practice. Source First is with made with the intention of smaller developers not getting screwed over by mega corps making money off of the product and not contributing back (like Elastic Search encountered with Amazon) as well as maintaining basic user privacy rights (not required by OSI). TLDR; OSI preserves all freedoms of usage for everyone. Source Available has restrictions on usage, often in interest of protecting enterprise software. Source First has restrictions on usage, often in the interest of protecting software from enterprise usage without contribution, and rejects users privacy as a business. Personally I think Source First would be the best for end users, but it does not contribute to the “commons” of available software for general usage as much. This mainly applies to other developers wanting to work on or use said software. Source First used in applications make sense, but for shared libraries and such, it would be an exceedingly strange choice imo. The other equally best is AGPL for web applications, and GPLv2+ for non web applications running locally. --- ## Post 100 by @anon29374801 — 2024-11-24T16:55:08Z Was there enough confusion around the issue where there should be a little blurb, maybe in the knowledge base, just saying something like “when we refer to open source we are referring to the OSI definition”? Maybe this would be a bit more then needed. --- ## Post 101 by @jonah — 2024-11-24T20:58:56Z I don’t think there is confusion about the term and we use it completely consistently across the website right now. There _would have been_ confusion **if** we listed Grayjay and called it “open source,” which is why this discussion was necessary. But we don’t list Grayjay, and **if** we do in the future we’ve decided to call it something other than “open source,” so I don’t think any clarification is needed. --- ## Post 102 by @ignoramous — 2024-11-25T03:08:44Z > [@xe3](#): > > Futo’s seems better than most, which is what they hope to communicate with the new term as far as I understand. Desperation. Marketing. > [@overdrawn98901](#): > > mega corps making money off of the product and not contributing back like Elastic Search encountered with Amazon First, _Elastic_ are themselves a bigco. Second, the dispute was mostly around trademark use. Third, Elastic and AWS have since reconciled after their very public spat (unsure about AWS’ _Open Search_ fork). Fourth, _Elastic_ had partnerships in place with other bigcos like Google & Microsoft, and those worked just fine. This claim (that megacorps benefit off of FOSS) is actually making a case for FOSS, which isn’t about a more capable group of developers screwing over another, but about the impact of the said FOSS software itself. For instance, if _Elastic_ hadn’t open sourced its flagship _Search_ product, would the rest of the ecosystem (Kibana, LogStash, Fluent as some examples) even exist to the extent it did, for bigcos to even take notice or fork? Mind you, the scale at which AWS, Oracle, Google, Microsoft, Apple et al operate is such that they design their own CPUs. You’re positing that they do _not_ posses the necessary eng chops to take on FOSS projects without _forking_ them? They absolutely can and do (see Chrome v Firefox; v8 v JavaScriptCore). In fact, to me, it seems like _Elastic_’s real competition is from the Prometheus + Grafana ecosystem, which is another FOSS success story. > [@anon48875053](#): > > both are incorrect, FUTO’s software is source first, and they even trademarked that definition PG isn’t necessarily the platform to further FUTO’s marketing goals? Especially, not while there isn’t any industry wide consensus on this new term. Well, at least not until they decide to fund PG, and then things might get interesting.