Publish on F-Droid

[alexanderadam]

Would you consider adding the extRact to the official F-Droid repository?
This way people would see it and can get updates easily.

Thank you for your fork, this already looks impressive.

EDIT: This was being worked on but builds are not reproducible yet and fixing this relies on an issue at Google.

See

• Upstream Google Bug 287967713 (you might want to click the +1 if you have a Google account)
• F-Droid data MR 12430
• F-Droid wiki

[newhinton]

Generally yes, however i would like to clear up the licensing issue. rclone-explorer, and the successor rcx aswell as my fork use a dual license, (App releases are GPLv3, and contributions are MIT) which creates uncertainty for me which i want to get rid of beforehand.

[alexanderadam]

Can you please elaborate what this means?
How can you get rid of it?
Are you planning license changes?
Who could help you in which way with that?

And how is the license hindering F-Droid publishing? GPL and MIT should both be compatible with F-Droid, right?

[newhinton]

Can you please elaborate what this means?

Sure!

How can you get rid of it?

That's the question ;)

Are you planning license changes?

Yes and no. Currently rcx is published with a GPLv3. However, contributions are done with the MIT license. (Here the original text.

This is an issue to me. I dont actually know how to navigate license-issues, and usually projects only have one license. If i stick to that license, i should be fine. In this case: i want to keep the GPLv3, and "remove" the MIT-one.

I don't know if i am allowed to do that. I don't even know why exactly it was done this way, and the CLA containing an explanation is not helpful (at least to me)

Who could help you in which way with that?

A lawyer? Jokes aside, anyone who knows why this is necessary or why it was done that way could help.

And how is the license hindering F-Droid publishing? GPL and MIT should both be compatible with F-Droid, right?

There is multiple things that i need to at least understand before making any changes:

• Why is there a split of licenses in the first place, community contributions could be done with the GPLv3 in the first place, alleviating the need for two different licenses
• As a fork, do i have to follow any rules outside the GPLv3? Is the MIT-license even relevant to me as a fork?

I dont want to break any licensing-laws, and since i have no clue how to navigate this (and no money to pay someone to navigate this for me) i am a bit stuck.

And that completely ignores the fact that i actually never published any app on either fdroid or gplay, but i consider that problem solvable by myself ^^

[alexanderadam]

There is multiple things that i need to at least understand before making any changes:

* Why is there a split of licenses in the first place, community contributions could be done with the GPLv3 in the first place, alleviating the need for two different licenses

* As a fork, do i have to follow any rules outside the GPLv3? Is the MIT-license even relevant to me as a fork?

I hope you that you don't hate me for mentioning you @x0b but you are probably the one who can answer at least the first question best?

[xz-dev]

Would you consider adding the extRact to the official F-Droid repository? This way people would see it and can get updates easily.

Thank you for your fork, this already looks impressive.

Until then, you can try using UpgradeAll to get update. :)

[opk12]

This is the typical approach when a proprietary version is planned. Everything is copyright by one person (authorship, contributions under CLA copyright assignment) or under a weak copyleft license (MIT or others). So one person does not have to follow the GPL, everyone else does. The could in could [not] be merged back into the original app likely means without losing my status.

[alexanderadam]

So what does this mean exactly?
That the license of forks is not open enough for F-Droid but the original app is allowed to do so?

[newhinton]

@opk12 Thanks for this comment, this explains roughly why it was done this way.

As far as i understand it now, i can safely remove the MIT license and only keep the GPLv3, giving each contributor full ownership of their code.

As long as i also release the source code, nothing should prevent me from releasing it on fdroid regardless of the original tree.

@alexanderadam I think it is open enough. Though i may be wrong.

[opk12]

As far as i understand it now, i can safely remove the MIT license and only keep the GPLv3, giving each contributor full ownership of their code.

If that means I do not ask contributors for MIT or CLA, I understand.

But if that means I remove the MIT license from the source tree, then no, the MIT says The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Removing the MIT code is necessary to be able to remove the MIT license.

Forcing GPL-only contributions would be unnecessary; the authors of the GPL have a list of GPL-compatible licenses which is the go-to if you want to merge a third-party library, for example.

As long as i also release the source code, nothing should prevent me from releasing it on fdroid regardless of the original tree.

F-droid wants the source code and any free software license. The next step is to check the inclusion how-to and the inclusion policy.

[opk12]

Since the rcx tree is already in f-droid and the kaczmarkiewiczp tree is under a different license: If a short summary of the project history, licensing and technical improvements wrt upstream is put somewhere (readme?), it might help convince f-droid about why the project is worth including and how serious it is (not just a rebrand).

[newhinton]

If that means I do not ask contributors for MIT or CLA, I understand.

Yep, that's it.

I dont want to remove any code or licenses, i just want to release the app as a whole as GPLv3, nothing more.

[x0b]

Hi everyone,

first off: sorry, I guess this license chaos is my fault. In short: RCX was released as GPLv3, and thus can be continued under those terms (or compatible terms). Of course, RCX was built upon the work of other people, and their license terms must be respected as well - usually, that means keeping the copyright notices of the dependencies and attribution.

Now, why was RCX even set up in this weird way? The idea way was to keep RCX completely compatible with original project, and that included the ability to merge changes back into rcloneExplorer. And since rcloneExplorer was licensed as MIT, that meant that RCX would require the capability of being releasable under MIT. An alternative would have been copyright assignment, but no one wants to read non-standard legal texts (the CLA is bad enough). So, that's why RCX had an asymmetric license configuration.

@newhinton I could probably re-lease the RCX code under MIT, if you think that improves your forks future development/community compared to GPLv3.

Disclaimer: This is only my reading of the situation, not a definitive legal answer. If anyone needs that, please consult a lawyer.

[newhinton]

Hi @x0b!

I am fine with either GPLv3 or MIT. My goal was to "properly" do a release without breaking any license, and to make it more easy for others to chime in.

I dont think it is nessessary to rerelease rcx, but it would be a good idea to discuss if you want to maintain rcx in the future, or if you park it in "maintenance-mode". If you want to return, we should probably discuss if we want to maintain two forks of basically the same app. I am open to merge my progress upstream, albeit there is no way of doing so in different pr's. Besides undoing the name&icon changes, this fork is now "as is", and changes would have to be made on top.

If you dont want to maintain rcx, you could add and release a notice for that and link to this repo, or i take over rcx and merge everything upstream and continue working on rcx, keeping the name&package-id.

I will not make any changes to the licensing for now (that means removing the cla-requirement), so that we have all options.

I am open to discuss this open or via email, you should find my mail in my profile.

[newhinton]

https://gitlab.com/fdroid/rfp/-/issues/2296

I have now created an inclusion-ticket for f-droid.

Edit:
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12430

[newhinton]

@x0b Do you think you can find some time to discuss this and your fork? It would be nice to continue as one project!

[nvllz]

So...? Will the app make the fdroid repository? I saw some posts about this in the link above, but why is it taking so long?

[newhinton]

@x0b It would be nice if we could clarify the license issue.

I assume that the original app, rclone explorer was released under MIT.
You wanted to release it under the GPLv3, so you changed the license. However, to keep the option open to merge rcx back to rclone explorer, you introduced the CLA for contributors, so that those contributions are MIT and therefore compatible with rclone explorer (and your own code).

Since you can change the license for your own code any time you want, you could switch from GPL to MIT, and then merge your code back.

However, your current master-branch is fully GPLv3, and i only have to adhere to that, right?

[newhinton]

Just a heads up:

I am working on reproducible builds. If someone wants to help out with this, chime in over at #68!

[newhinton]

Builds are now reproducible!

So, what is missing for an f-droid release?

• Check fastlane-metadata for store-page
• Rename app
• Change Appicon (Depends on appname)
• Create Keys
• Merge F-Droid recipe!

So you can see, we are getting close!

[pezz]

Love your work, looking forward to this.

[newhinton]

I'd like you to join me in the discussion of the new app-name and icon:
#24 (comment)

[valtoree]

What amazing work you have done newhinton. Wish I could help you but have no clue. Keep up the great work.

[alensiljak]

Thanks for the efforts on bringing this app back to life, in a sense. I don't think the licensing is strictly related to F-Droid and the two issues can be separated.
The existing code, made under certain license (say MIT), needs to stay under that license, most-likely. You can still say that any new contributions are released under GPL-3.

That said, I'd wholeheartedly recommend going through some of the articles on fossa:
https://fossa.com/blog/open-source-software-licenses-101-gpl-v3/

I had an app published on F-Droid and Izzy's repo and it was fairly straightforward. But I see you're already in the queue so that should be no problem, either.

[newhinton]

That said, I'd wholeheartedly recommend going through some of the articles on fossa:
https://fossa.com/blog/open-source-software-licenses-101-gpl-v3/

Good read!

But I see you're already in the queue so that should be no problem, either.

Yes, but sadly i hit a roadblock. I was ready to actually release the 2.1.3 by merging the build-recipe for fdroid in their main repo just yesterday, but the app decided that it actually did not want to be reproducible. Some files are not created properly on the local builds, so i need to find a solution for that. I seriously hope to get that done soon.

[newhinton]

Just a quick update:

The fdroid-release is delayed because of what seems to be a bug in android's toolchain, We cant build the apk reproducible, therefore we cant release. I hope that this can be resolved rather quickly, but i cant give any estimate when i can move forward.

[alexanderadam]

This means that the toolchain changed from RCX to Round Sync?
Is it more modern build tools or something like that?

[newhinton]

No, not really. I mean i did upgrade gradle, but rcx was never reproducible. Reproducibility has more rigid requirements to the toolchain, and it seems that this app uncovered a bug in googles buildtools.

The fdroid-people had this on a different app too, without a resolution. We filed a bug to google, and we have to wait for that.

[alexanderadam]

Ah, I see. Thank you for this clarification!

[jxmesth]

@newhinton, hi, and thanks for the amazing amount of work you've put into this. Really helpful. Just wondering, is there any update on this issue?

[essys]

It's live!
https://f-droid.org/packages/de.felixnuesse.extract/

Thanks @newhinton

[jxmesth]

@essys, says 404 page not found but I'll give it a bit before I check again.

Thanks a lot for your work.

[essys]

If you have F-Droid installed it should open the package link directly to install the app.
But you are right, it's not yet on the main F-Droid web page.
Most probably will be very soon.

[alensiljak]

It takes about a day to build after merging, and then a day to appear on the Web. Approximately.

[alexanderadam]

How can it be published if the merge request is still open? 🤔

[newhinton]

The app you are referring to was added in izzy's repository, not the main one. You still can use that app (it basically links to the github releases) but it does not guarantee reproducibility.

[jxmesth]

@newhinton, thanks for your reply.

So technically what's safer? The official F-Droid repo or the third party one? Or are they basically the same?

I always assumed the official was the safest and most secure.

[alensiljak]

Izzy normally publishes items that are on the way to the official F-Droid or do not meet the inclusion criteria. So, basically, there is no overlap. Izzy is a member of F-Droid, anyway, so I would not consider his repo just a "third-party one".
Once the app is in the official repo, he'll probably remove it from his.

[jxmesth]

@alensiljak, thanks. That makes sense.

[essys]

Once the app is in the official repo, he'll probably remove it from his.

Exactly this, Izzy does a pretty good job here.

[newhinton]

Once the app is in the official repo, he'll probably remove it from his.

Yes, that is extremely likely. With reproducible builds, fdroid doesnt actually publish their own artifacts, but the maintainer-ones. Since izzy "just" "republishes" my apk, they would then have the same application id and would therefore conflict.

From the safety side: I did not check his repositories version of roundsync, so all the warnings regarding sources of software do apply. But as @alensiljak said, izzy is a high-profile well-known contributor to fdroid, so if you trust their repository, its probably fine. If you want to verify if the version is good, you can always compare checksums of the artifacts.

[opk12]

Details about the security measures in Izzy's repo are here from the yellow disclaimer at the top and from the section What about security?.

If malware is in Izzy's apk's, then any of GitHub or Izzy are compromised. Note that if Izzy =/= GitHub, then Android will block the upgrade to the GitHub / F-droid reproducible build, due to developer signature mismatch.

If malware is in F-droid, then all three, GitHub + F-droid build server + F-droid reproducibility verification server, have been compromised. (I think the F-droid servers are run by different people?) Therefore the F-droid verification server is also providing a service for non-F-droid users who download straight from GitHub.

[jxmesth]

@newhinton, @opk12, those are good explanations. Thanks a lot.

[alensiljak]

Interestingly enough, we just had a very similar conversation in another project so you can read it directly from the source: orgzly-revived/orgzly-android-revived#7 (comment)

[jxmesth]

@newhinton, what's pending for this to be added to the F-Droid repo?

[alexanderadam]

@newhinton, what's pending for this to be added to the F-Droid repo?

This Google issue

[mnisius]

Hello just a tip for everyone that wants to easily update RoundSync without manually checking the GitHub page.

There is an app called Obtainium. With this app you can add just the GitHub Link to the RoundSync Repo and the app will inform you about updates and also update RoundSync for you. And of course it works for every other app on GitHub oder gitlab.

[jxmesth]

Is this in progress?

[navidada]

@newhinton, what's pending for this to be added to the F-Droid repo?

This Google issue

The last post in this link mentions another app called Myne that had the same problem.
It seems that they solved it here.
Could this help in publishing Round Sync to F-Droid?

[obfusk]

@newhinton there has finally been a reply in the Google issue. Looks like they need more info from you.

Also: you might be interested to know IzzyOnDroid now supports Reproducible Builds :)

[newhinton]

Also: you might be interested to know IzzyOnDroid now supports Reproducible Builds :)

@obfusk Yes! I have been following that on mastodon :D Though i have not looked into it in detail, and my other apps are already in the fdroid repo itself. Reproducible, of course :D

[IzzySoft]

But I somehow didn't manage to get Round-Sync RB. From my notes:

• as of v2.5.6, gradle.properties specifies Go 1.23, but we cannot construct the URL from that so we use 1.23.0. NDK is specified as 25.2.9519653, JDK as 17
• not RB, but also not flaky (or we cannot really test that as when using ./gradlew clean build crashes)
• going by the dex diff, our build has versionCode 416 while upstream has 410, but their build.gradle still has 410 even at HEAD

• Round-Sync/app/build.gradle

  Line 87 in 9dafb7d

  'armeabi-v7a': 6,

  adds "6" for armeabi, not sure why only for us?
• replacing that fixes the classes.dex but breaks manifest and .so; keeping universalApk true fixes classes.dex but breaks .so (same when building all ABIs incl universal)

My last build recipe:

- GO_VERSION=$(grep -E "^de\.felixnuesse\.extract\.goVersion=" gradle.properties | cut -d'=' -f2)
- VERCODE==$(($(sed -rn 's/\s*versionCode ([0-9]+).*/\1/p' app/build.gradle) -6))
- sed -r 's/versionCode [0-9]+/versionCode '$VERCODE'/' -i app/build.gradle
- wget -q -O /tmp/go.tar.gz https://dl.google.com/go/go1.23.0.linux-amd64.tar.gz
- sha256sum -c <<< "905a297f19ead44780548933e0ff1a1b86e8327bb459e92f9c0012569f76f5e3 /tmp/go.tar.gz"
- tar -C /build -xzf /tmp/go.tar.gz && rm -f /tmp/go.tar.gz
- export PATH="$PATH:/build/go/bin" GOBIN=/build/go/bin
- go install golang.org/x/mobile/cmd/gomobile@c6794c95c70b02ddb1a79d92fec29f8b8ddd8836
- go install golang.org/x/mobile/cmd/gobind@c6794c95c70b02ddb1a79d92fec29f8b8ddd8836
- sed -r '/signingConfigs.release/d' -i app/build.gradle
- sed -r "s/universalApk true/universalApk false/ ; s/include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a'/include 'armeabi-v7a'/" -i app/build.gradle
- sed -r 's/dependsOn buildArm, buildArm64, buildx86, buildx64/dependsOn buildArm/' -i rclone/build.gradle
- chmod +x gradlew
- PROF_FILE=app/build/intermediates/binary_art_profile/ossRelease/baseline.prof
- PROF_SHA1=6377763592ca2a06ddce05743474903ac345915d
- for _ in {1..10}; do
- ./gradlew assembleOssRelease --no-build-cache --no-configuration-cache --no-daemon
- find . -name '*.prof'
- test -f "$PROF_FILE"
- if [ "$( sha1sum "$PROF_FILE" | cut -d' ' -f1 )" = "$PROF_SHA1" ]; then
- break
- fi
- done

(that "for" loop is for checking if it's "flaky", i.e. a non-deterministic build which produces a matching APK at least in 1 out of 10 cases).

Any idea what I might miss here? (And yes, I've see that the Google issue is still open – but with my builds it was the manifest, classes.dex and the .so file which were affected 🤷‍♂️)

[IzzySoft]

Ah, Fay just spotted a typo (VERSION==). So I've fixed that and tried again:

> Could not resolve all files for configuration ':app:ossReleaseCompileClasspath'.
   > Could not resolve com.github.Sharkaboi:AppUpdateChecker:v1.0.5.
     Required by:
         project :app
      > Skipped due to earlier error

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 3m 56s

Funny, had no issue with that on November 18th, also building v2.5.6 …

[newhinton]

It broke again? Hm. I'll have to look into that when i find a bit time.

I hope this becomes less of a problem once i get around to do the rewrite

[IzzySoft]

I don't remember what you've needed AppUpdateChecker for – but if it's just as self-updater, maybe simply leave it out of the oss flavor? 😜