-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F-Droid issue: The greendao gradle plugin is not FOSS #1399
Comments
breezy-weather/breezy-weather#677 mentions three alternatives. That's a lot of work i fear |
Is it possible to switch back to the generator? |
I do not think so. It says in the documentation, that this it's the legacy greenDAO generator. This does not sound future-proof. Or are there any other projects which made this change because it's easy? I do not know. |
The whole greendao is not maintained anymore so the gradle plugin is not future-proof, either. :) |
Yes, of course. But intentionally working on moving to sth. not maintained anymore makes no sense. |
Yes. Some other apps moved to SQLDelight. |
I haven't looked into different DB libraries yet, but as a temporary measure the 9 generated source files can be just copied into the main code base and the plugin removed. (The old non-plugin way to generate DAO-classes seems to be deprecated in greendao 3, so there's no official up-to-date guide to set it up.) If this is acceptable, I can create a PR. |
From the description of the original issue, i think this should be acceptable. |
The generated code is not regarded as source code and the license may be problemic since it's generated by a non-free plugin. |
@linsui this is generated source code (not blobs). Are you sure we're on the same page here? |
Yes, I discussed this with other F-Droid contributors. We thought that the generated code should be avoided, especially when it's generated by a non-free tool. |
It would be nice to have a proper position here (not just "should be avoided"), and something written on the Inclusion policy page about this. Do you know of previous discussions on the topic that are public somewhere? I think it would be odd to have such a policy that would reject such generated code. A lot of IDEs (including proprietary ones) have tools to generate code (for instance, generate all getters and setters in a class based on the properties), there's not much difference here. Unless you think there is a risk that GreenDAO comes and claims the generated code as their own, there's nothing that prevents us from claiming the generated source code as written by ourselves, and licence it as we wish. |
@tcitworld the question is where to edit the source code, as in:
|
The above linked PR is about making this generated source code a part of the repository just like regular source code, which would then be edited manually, as the GreenDAO plugin would be gone. |
This sounds good to us. :) Could you please remove those
comments? |
2.5.3 has been tagged with the greendao plugin removed. |
I'll update the metadata. :) Thanks! |
The source code of the plugin has been published. The workaround can be reverted. https://github.com/greenrobot/greenDAO-plugin |
Issue details
Since f8493cc the greendao generator is replaced with the gradle plugin. But the source code of the plugin is never released, see greenrobot/greenDAO#412. So F-Droid has to remove all affected versions of wallabag and can't build new versions. Is that possible to migrate to a different FOSS lib, since greendao is not maintained anymore? Please note that objectbox is not FOSS yet, see objectbox/objectbox-java#1102.
The text was updated successfully, but these errors were encountered: