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.
8 Likes
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.
1 Like
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:
- Copyleft (GPL etc.) software meeting FSF free software definition
- Software meeting OSI open source definition
- FUTO/“Source First”-type software
- Proprietary, source available software
- 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.
15 Likes
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.
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.
3 Likes
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).
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
1 Like
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.
1 Like
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)
2 Likes
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.
2 Likes
He mentions it here:
I also think they’ve mentioned it on the youtube channel at some point but i can’t remember where or when.
1 Like
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
3 Likes
They’re working on that. It’s a matter of deciding the metrics to meet and how to translate that to a legal document.
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.
2 Likes
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.
2 Likes
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.
2 Likes
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.
2 Likes
Are there many situations where that comes up?
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, 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.
2 Likes
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.
7 Likes