Create a policy to migrate from an app that is using non-foss code to an app that is compliant
In this discussion in FDroidServer we concluded that sometimes it's impossible to make an app compliant to new F-Droid rules without a Migration period.
1. Introduction of new rules
In Merge Requests such as the aforementioned, new rules and scans can be introduced, which leads to many apps being tainted or non-compliant as they're not using pure FOSS code
2. Adaptation to new rules
Most of the times, adapting to new rules is as easy as replacing a library, or removing parts that are non-compliant.
Sometimes, however, new rules break apps in ways that can't be adapted quickly, such as the database backend.
2.1 Adapting databases to new rules
To adapt an app to a new database it's necessary to have access to the old database, so that you can migrate data to the new, compliant database. This diagram shows what would be necessary for data migration to a compliant format
3. Build Grace Period or Migration Builds
To move from the recently non-compliant app to the compliant version, the intermediary build is necessary, and must be published to F-Droid, even if with deprecations.
