objectbox-java
objectbox-java copied to clipboard
objectbox
You can provide objectbox plugin source code?
I don't know if there are plans to make the plugin code public, right now it is not available.
cc @greenrobot
It's being discussed internally. @sjdlfajdlfe What would be your use case?
I believe it could helps apps being fully open source, which is not the case yet (for F-droid for eg)
@HugoGresse The ObjectBox plugin is only used at build time so using it shouldn't cause any issues regarding licensing of your code (but again, depends on your policy of course).
Indeed, at build time, which F-Droid does. Every app on the F-Droid FOSS store is built by F-Droid server which prevent the final build to include non-opensource code (or code which was not on the repo itself).
Hey guys! Any way I can help on this? My app got blocked in FDroid due to this issue, and my current plan is to move away from object box But I really like it, so maybe there's something we can do 😁
It feels a tiny bit disingenous to have a GH repo where the LICENSE.txt file says "Apache-2.0 license" but the README.txt next to it says "Hey, just add this closed-source plugin to your gradle file"...
Indeed, at build time, which F-Droid does. Every app on the F-Droid FOSS store is built by F-Droid server
OK, that's actually a good reason to prioritize open sourcing the plugin a bit higher...
Does anybody know if F-droid has any checks in place for native binaries?
PS.: For fdroid, it may be enough to put the sources inside the sources jar? This could speed up the first step... cc @greenrobot-team
@greenrobot Yes, binaries are scanned. ref: https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1150
@greenrobot This problem has been raised by F-Droid team and the impact is really high: for good or bad reasons all recent version of Kiwix has been removed from F-Droid because of this problem. It's important for me to:
- understand the rational behind the decision behind making this compilation tool non-free
- get a kind of timeline for the release on open-source.
This is important to me to assess the situation and decide if it makes sense to replace objectbox (we are super happy with btw) or keep it and wait the fix.
Related: what's the license status of libobjectbox-jni.so? Maven (https://mvnrepository.com/artifact/io.objectbox/objectbox-android/3.3.1) refers to the "ObjectBox Binary Licence", but I can't find any reference to what that means.
This is important to me to assess the situation and decide if it makes sense to replace objectbox (we are super happy with btw) or keep it and wait the fix.
I imagine quite a few people are in the same boat. With new releases blocked on F-Droid, projects are likely finding themselves trying to decide whether to start working on a migration immediately, or wait for developments.
With new releases blocked on F-Droid
It's far worse. All releases relying on this for building have been removed.
F-Droid's policies on free software come from Free Software Foundation, Open Source Initiative, Debian, etc. They have clearly defined what free software is, so we don't need to. GNU/Linux distros like RedHat, Fedora, Debian, Ubuntu, etc. all build all packages from source, no outside binaries are allowed in the official release process. The Debian builders don't allow network access even.
An easy way to think about what free software is: can the user customize it using only free software? If the user needs to use non-free software to build the source code, then the user does not have the freedom to modify the software in any way they want to. They cannot change the proprietary build tool or plugin.
@eighthave Your comment is misleading, unfortunately. AFAIK none of the OSI recognized open source licenses, and FSF one included, put any constraint on the build dependences (dependences needed to build but not included in the software). If we follow your logic, and this is only a counter-example, Thunderbird won't be a FOSS because it requires Visual Studio (propriatery software) to compile on Windows, this is non-sense.
F-Droid or Debian, as software distributors and software builders, have their own rules, which are perfectly legit. But their rules apply only to their own garden: they don't define what is FOSS or not. To the contrary to the FSF for example, which is a FOSS license publisher (and enforcer).
F-Droid rules are legit for F-Droid and that is good enough. My advice would be that, instead of challenging FOSS developers with this kind of wrong - and slightly insulting - assertion, you better focus about how to communicate around your own rules, think about how to enforce them without putting users and publishers in difficulty within 24 hours...
To conclude, asserting that softwares relying on this - meanwhile - infamous non-free Objectbox plugin, are non-free themselves is false and confusioning. You are the second contributor of F-Droid I read making this mistake and this is not desserving the FOSS movement IMO.
(dependences needed to build but not included in the software
The plugin is not just a build dependency. It pulls in https://search.maven.org/artifact/io.objectbox/objectbox-android/3.3.1/aar into the implementation dependencies, which itself then pulls in a closed-source native binary, which is then bundled with the released software.
Thunderbird does not require Windows nor Visual Studio, it does support them as an option. It is free software because you can build it and run it on Debian. Indeed it is included in Debian. Free software is about user freedom, so users should be free to use proprietary tools if they want. The key point is that users are not required to use Windows or Visual Studio. objectbox will not be free software as long as it requires users to use proprietary software to build or run it.
If you're talking "open source", that' looser definition. Some people even call proprietary software open source if they can read the source code.
@eighthave @kelson42 That's beyond the point. It's not a build-only dependency, it ships a non-foss binary https://github.com/objectbox/objectbox-java/blob/556d9652babda6a7aeca64396dc827bea8f35e82/objectbox-java/src/main/java/io/objectbox/internal/NativeLibraryLoader.java
Specifically this line: https://github.com/objectbox/objectbox-java/blob/556d9652babda6a7aeca64396dc827bea8f35e82/objectbox-java/src/main/java/io/objectbox/internal/NativeLibraryLoader.java#L103
that needs to be loaded in order to function.
To go with your example, Thunderbird doesn't run Windows in your computer
Thunderbird does not require Windows nor Visual Studio, it does support them as an option. It is free software because you can build it and run it on Debian.
Wow, so basically this is because Thunderbird is multi-platform that it is FOSS. This is getting better and better over time! So lets take a Windows only free software: Notepad++ is not FOSS?
@eighthave @kelson42
That's beyond the point. It's not a build-only dependency, it ships a non-foss binary
https://github.com/objectbox/objectbox-java/blob/556d9652babda6a7aeca64396dc827bea8f35e82/objectbox-java/src/main/java/io/objectbox/internal/NativeLibraryLoader.java
Specifically this line: https://github.com/objectbox/objectbox-java/blob/556d9652babda6a7aeca64396dc827bea8f35e82/objectbox-java/src/main/java/io/objectbox/internal/NativeLibraryLoader.java#L103
that needs to be loaded in order to function.
@LeoColman Thx, this is the key point really missing. It's not a build dependence to a proprietary software which is a problem, actually this is a runtime dependence to propriatery software. This is obviously the real problem. It seems this is not clearly stated in this repository readme (or I missed so ething) and the Apache license of this java binding is misleading. We should really have been more careful at the time it has been introduced in Kiwix. The price for this error is high.
Thanks for your input!
Here is an overview of the current licenses for a typical Java/Android project that is hopefully helpful:
| Package | License | Source code | Usage |
|---|---|---|---|
| Java libraries | Apache License, Version 2.0 | available | run time |
| Gradle plugin | GNU General Public License, Version 3 | not available (yet) | build time |
| Native libraries | ObjectBox Binary Licence | not available | run time |
Note that the Gradle plugin adds Java and native libraries to your project dependencies as needed.
Maven Central search is a way to see all dependencies and their licenses.
Note that for other languages (e.g. Dart/Flutter) the situation is similar, e.g. the language binding is Apache 2.0 and the native library uses the ObjectBox Binary License.
Edit: let me know if this can be improved. Maybe it makes sense to also add this to the GitHub README, or a special info page on our website/docs that we can link to.
@greenrobot-team I've created pull request #1104 to add the license information to the readme. I think this table you provided should be placed everywhere license related
I would like to add, making the plugin open source (not necessarily the proprietary native code) would allow making contributions to it. Tickets such as #1075 and #948 have been open for a long time, and the community could definitely help, and have already offered to help, in solving them.
Any update here regard the source code of these binaries? I'm debugging some critical memory leaks in my application, and the dumps are pointing to some internal C++ objbox native library calls, that I unfortunately cannot debug by myself, since the code is not available. BTW we use objbox for many years now, and just today I realized that it is not entirely open source.
@niltonvasques Feel free to open an issue about this here. We also offer professional (commercial) support at support[@]objectbox.io if you need it.
@marek22k If there is an update, we will share it. Please only comment if you have something to contribute (e.g. an implementation suggestion, a use case that wasn't mentioned or where the suggested workaround does not work). Otherwise this produces needless work for us (e.g. me checking all new comments for something relevant).
I will hide such comments so it is easier for us and other users to see relevant comments.
If you are interested in this, please thumbs up the first post instead. This helps us track interest.
Any reason why PR #1104 (which clarified quite confusing licensing situation) was closed without comments @LeoColman? Was it mistake (head was deleted?) ?
It was mostly based on @greenrobot-team comment at https://github.com/objectbox/objectbox-java/issues/560#issuecomment-1266858993. Can it be reopened? If there are specific improvements to be made, could it be commented what those are, so it can be amended?
In current form, licensing is misleading at the least. It would benefit everyone if legal uncertainty were clarified instead.
They've purposefully ignored this topic for a long time. I gave up on having anything to do with it
@mnalis The PR was closed because we made updates to the README ourselves. It now links to a license info entry on our website that mirrors my comment above. This way we can re-use it in all of our projects.
@greenrobot few comments:
- I'd suggest to keep such information directly in the README itself. Relying on website resourse has many disadvantages (URL changes and other bitrot happens, licensing information that is valid today might not be valid in 5 years, there is no log/history, offline copies of the code lack the information for verification etc). Keeping it in the git repository
READMEwith rest of the code whose situation it describes solves all those problems. You can link from website to that README, if such avoiding duplication of information is preferred by you. - web version seems to miss most important column from your comment, i.e.
Source code: open/closed. That significantly reduces its usefulness for interested parties. - I would like clarification in particular about
Package: Gradle plugin/License: GNU General Public License, Version 3/Source code: closed/Usage: Build time. Can you explain how that works exactly (GPLv3 + closed source)?