Live data from Hacker News

GrapheneOS Overhauled Default Apps and Secure Clipboard

grapheneos.social

141–150 of 284 posts

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#141

Earlier quoted context omitted.

The preinstalled apps are part of the OS.

That cannot be true, when I install e.g., Ubuntu system, there are plenty of applications installed for me, with incompatible licenses.

It is true, and if Ubuntu is shipping apps as a part of the OS with incompatible licenses, that is a crime.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#142
post #35

Earlier quoted context omitted.

Their license is invalid due to being GPLv3. GPLv3 cannot be included in GrapheneOS as that would necessitate GrapheneOS give up their permissive licensing. Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.

Can the Linux kernel be included in the OS?

Yes, the GPLv2 license does not have the same restrictions GPLv3 does, it does not necessitate making the code it is bundled with GPLv2.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#143

Earlier quoted context omitted.

The point is to access an e2ee protocol bundled by default on many devices, and is cross-platform. GrapheneOS does recommend using superior platforms like Signal, but that is 3rd party, and thus has adoptability issues in convincing people to use it. Just because better platforms exist does not mean RCS should be ignored.

Thanks for clarification. Anything first party from Big Tech is a lost cause privacy wise. At the same time, nobody uses it (maybe that is different in the USA, don't know). So for me this would be ultra-low prio as I (and I expect almost every other GOS user) will never use it. But I believe GOS knows what it is doing.

I assume many people would use it due to SMS concerns and difficulty having people move to other platforms. I would personally use it as a fallback to Signal since my current fallback is SMS, which I dont like.

If the protocol is properly e2ee, it does not matter who backs it or hosts it. GrapheneOS would be in control of the client which is what matters in an e2ee system.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#145
post #125

Earlier quoted context omitted.

The intended purpose of RCS was to be federated between carriers, just like SMS. If you centralise it then it's just a worse version of any of Google's abandoned chat apps. But there's a realpolitik reason to insist on centralised RCS: because it's already got the reputation of decentralisation, it makes it look like Google is better than it actually is.

> The intended purpose of RCS was to be federated between carriers, just like SMS. Oof, so it was essentially destined to fail when the spec was being written.

Did SMS fail? Sort of, as it's rarely used, but also not, because it continues to work and it's still the only federated messaging system you can rely on being available on your phone (besides phone calls).

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#146
post #69

[flagged]

We've done months of work on overhauling the Messaging app. It has been done in incremental portions with code review for each. It often goes back and forth several times before it gets merged. Why not look at the quite open development and code review process on GitHub?

https://github.com/GrapheneOS/Messaging/pulls?q=is%3Apr+is%3...

Every release of GrapheneOS and GrapheneOS apps goes through internal testing followed by public Alpha channel testing and then public Beta channel testing before reaching the Stable channel. No update goes to Stable without internal, Alpha and Beta channel testing phases.

We've been heavily testing our Messaging overhaul as we've been doing it and we've been making a lot more tests than we used to. It's already in quite good shape and is ready for Alpha channel testing. That's what we're referring to.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#148
post #13

There are excellent FOSS gallery apps already, like the Fossify suite. Why not use them I wonder?

We're going to be forking one of them (ReFra). We want to make extensive changes and have a different vision for it than the upstream project. For example, we don't want it to have integration into services. There's plenty of room for both an increasingly different fork of it in GrapheneOS and the original project which our users will continue to use who want features we don't consider inside the scope of what we want from a local gallery app.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#149
post #35

Earlier quoted context omitted.

Their license is invalid due to being GPLv3. GPLv3 cannot be included in GrapheneOS as that would necessitate GrapheneOS give up their permissive licensing. Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.

Can the Linux kernel be included in the OS?

Yes, AOSP includes a lot of GPLv2 code and we use GPLv2 licensing ourselves including for our Vanadium browser project. We don't want GrapheneOS to be more restrictively licensed than the Linux kernel and AOSP so we avoid GPLv3 code bundled with the OS. GPLv3 is perfectly acceptable for apps in our App Store but we don't want it for the ones in the OS.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#150

Earlier quoted context omitted.

The preinstalled apps are part of the OS.

That cannot be true, when I install e.g., Ubuntu system, there are plenty of applications installed for me, with incompatible licenses.

OS components don't need to have compatible licenses if they're separate from each other. The Linux kernel is GPLv2-only which forbids GPLv3 licensing. That doesn't mean GPLv3 code can't be used in a Linux-based OS.

We use GPLv2 and permissive licensing for GrapheneOS to avoid more restrictive licensing than the AOSP. We'll happily use GPLv3 and AGPLv3 for components outside of GrapheneOS if we think it's the best fit for specific projects. We aren't currently licensing anything as GPLv3/AGPLv3 but we aren't strictly opposed to it outside of the OS.

We'll use what we think are the best open source licenses for what we want to achieve. What we want to achieve is usually broad adoption of our code with painless usage of it. That means we usually choose permissive licenses. We use GPLv2 in certain cases such as Vanadium where we decided we wanted extensions to our code to be under a compatible open source license instead of a source available license or GPLv3.

Post reply on HN