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.
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.
Made a draft PR to move this forward: Define PrivacyGuides's definition of the term "Open source". by blacklight447 · Pull Request #2732 · privacyguides/privacyguides.org · GitHub
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. 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
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.
There are two ways to protect developers work from being exploited by corporations:
I don’t agree that we should follow OSI definition.
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.
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.
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, FSF, GNU, and OSI (read a quick overview of them all on SPDX) .
Requiring the use of either OSI-approved or source first license would make the most sense.
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.
AGPL is literally a copyleft license.
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.
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.
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.
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.
This kind of commitment is admirable. Its why the PG team does so well.
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.
Do you have any links to examples where this explained more?
I could only find this: FUTO Keyboard - #25 by louis_rossmann
Same here, but is says its still a work in progress here. Maybe I ll reach out to him.
Look, open-source is pretty well defined. We shouldn’t “reinvent the wheel”.