Including non-free dependencies

[CodeDoctorDE]

Related to #321.
When adding google_sign_in and googleapis, we use platforms that aren't opensource and maybe proprietary.
F-Droid doesn't want apps using these apis.
How should we handle this?
I have some solution to this problem.

• Don't implement this feature
• Publish it as extra app in the playstore but don't upload it on fdroid
• Publish these extra features in the same app in the playstore but don't upload it on fdroid
• Other solution... What do other apps supporting cloud syncing?

What's your opinion?

[FineFindus]

I think removing the F-Droid build or not implementing the feature are both not valid solutions, as they hurt the users. As discussed on Mastodon, Flutter doesn't support flavor dependencies. Possible solutions to this issue could be:

• Use native flavors and call into native code to use the dependencies. This would require a lot of work
• Create a stub implementation and a separate branch/repo for the Google one

[FineFindus]

I think the non-free repo should only hold the code and link back for everything else.

I think the Google variant should simply have a suffix like -gplay, changing the icon and having a secondary app on the play store might lead to confusing among users. Also, it is possible, that Google might mark both apps as duplicated content.

[CodeDoctorDE]

Yeah...
What do you think about -nonfree. If we want to have support for other proprietary, we can also use this fork?
Or..., we do something like this:
Using the diff feature of git. Instead of forking, we use diff files in this repo and apply these if we build the nonfree version. This would add some complexity when contributing on the non-free system by changing the diff files but all files will be in the same repo

[FineFindus]

I think that is personal preference how to this. I would simply create a stub implementation, including a check like isImplemented(), fork/branch the repo for the non-free implementation. This could be rebased on to develop regular, e.g. via a GitHub action. As long if nothing is changed in the stub, the rebase will automatically succeed, otherwise you'll get a notification. I think this would be the solution with the least maintenance required.

[CodeDoctorDE]

That would solve the potential conflicts the diff option has.
After reading your idea, I have another good idea. You can use butterfly as dependency and we can have an optional parameter in the main method that supports implementing these nonfree implementations.
Thanks for your suggestions!

[FineFindus]

You're welcome. I'm always happy to help keep a project as FLOSS.

[Iey4iej3]

I would vote against such an implementation. There is no a priori reason to favor Google Drive (over other cloud services, such as owncloud), especially for a free software.

A solution is to keep a local copy of notes, and use Google Drive to sync that local copy.

[CodeDoctorDE]

The problem is: On mobile I see no option to sync a local folder with google drive and for normal users a google drive sync would help them using the app. I would make a second version of the app that users that wants to use the foss version can download them. But I'm not sure if google drive sync is worth the effort

[Iey4iej3]

I mean, if you plan to support Google Drive, then people will also ask for support for OneDrive, say, and more cloud platforms. Also, maybe some people might start to use Google Drive if it is the only visible option for sync without exploring alternative solutions (this happens when users want to sync but not necessarily a Google Drive user).

I find it not good that a (basically FOSS) app leads users to use such a proprietary cloud platform. Thus even if you plan to support Google Drive, I would suggest indicating that it is also possible to sync the local folder with anything else. For example, a page shows:

1. General sync, recommended (clicking this would lead to an instruction which tells users to set up the local folder and sync that folder);
2. Sync with Google Drive.

For sync of folders of Google Drive: https://android.stackexchange.com/a/231137

[CodeDoctorDE]

Hmm, yeah. Supporting every platform takes a lot of work. I don't know if autosync or other apps are very popular and I would show this as an option beside webdav. I see the problem here but I don't see a real solution. People are using google drive, youtube and more and you have two options: stay small as an app or supporting proprietary cloud platform.

[Iey4iej3]

I modified a comment above to suggest a way to support Google Drive which tries to minimize the possibility of (mis)leading users to use Google Drive.

[CodeDoctorDE]

That's a good idea.
WebDav is also supported if we want to add this page