You can provide objectbox plugin source code?

[sjdlfajdlfe]

No description provided.

[greenrobot-team]

I don't know if there are plans to make the plugin code public, right now it is not available.

cc @greenrobot

[greenrobot]

It's being discussed internally. @sjdlfajdlfe What would be your use case?

[HugoGresse]

I believe it could helps apps being fully open source, which is not the case yet (for F-droid for eg)

[greenrobot-team]

@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).

[HugoGresse]

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).

[LeoColman]

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 😁

[growse]

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"...

[greenrobot]

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

[LeoColman]

@greenrobot
Yes, binaries are scanned.
ref: https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1150

[kelson42]

@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.

[growse]

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.

[kelson42]

With new releases blocked on F-Droid

It's far worse. All releases relying on this for building have been removed.

[eighthave]

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.

[kelson42]

@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.

[growse]

(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.

[eighthave]

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.

[LeoColman]

@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:

objectbox-java/objectbox-java/src/main/java/io/objectbox/internal/NativeLibraryLoader.java

Line 103 in 556d965

System.loadLibrary(OBJECTBOX_JNI);

that needs to be loaded in order to function.

To go with your example, Thunderbird doesn't run Windows in your computer

[kelson42]

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?

[kelson42]

@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:

objectbox-java/objectbox-java/src/main/java/io/objectbox/internal/NativeLibraryLoader.java

Line 103 in 556d965

System.loadLibrary(OBJECTBOX_JNI);

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.

[greenrobot-team]

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.

[LeoColman]

@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

[natanfudge]

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.

[niltonvasques]

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.

[greenrobot-team]

@niltonvasques Feel free to open an issue about this here. We also offer professional (commercial) support at support[@]objectbox.io if you need it.

[mnalis]

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 #560 (comment). 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.

[LeoColman]

They've purposefully ignored this topic for a long time. I gave up on having anything to do with it

[greenrobot-team]

@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.

[mnalis]

@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 README with 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)?

[greenrobot-team]

Thanks for the thoughts regarding inlining vs. linking. We decided to add a link to the website for the reasons stated.

Regarding publishing of the plugin source code: licensing under GPL does not require to also publish the code. Only if GPL code of another author is modified and used, the changes need to be made publicly available. Anyhow, we plan to publish the plugin code at some point, but as the repo currently has some internal stuff and due to lack of time this has still not happened.

[papjul]

licensing under GPL does not require to also publish the code. Only if GPL code of another author is modified and used, the changes need to be made publicly available

I don't know where you got that idea. All users of a program under GPL license are granted the freedom to access the source code, no exception.

Quoting preamble of the license:

Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

As you can see, when you distribute a program under GPL license, you have responsibilities. One of them is to ensure all users of your programs can get access to the source code.

Additionally, section 12 says:

If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all.

Basically, this means you can't apply the GPL license partially. You must either follow all your obligations (one of them being to let users access the source code) for all your GPL programs, OR cease the distribution of these programs under GPL license (unless your programs contain GPL parts of other authors, in which case, that option is not possible).

[LeoColman]

@papjul it's on purpose. Your argument is wrong because the other side doesn't care
#1100 #783 #1102

[papjul]

None of the issues you linked ever mention "GPL" or "violation".

If you're not part of the ObjectBox team (or so I guess from your previous comments in this issue), it would be wise to not speak in their name about a legal issue.

Contrary to the other cases you mention, they have to provide a clarification. Either it's closed source, or it's GPLv3 AND open source. There is no " it's GPL and source code will be posted later" answer possibility.

[LeoColman]

I agree with you.

What I'm trying to point out is that ObjectBox has been purposefully shushing this discussion and any other discussions related to this. They won't open the code and don't care about the license.

You won't have your clarification on licensing, as they know the problem. Even @obx-vivien positioned in one of the threads, not in favor of the GPL.

I'm trying to post this comment just as a warning to not lose energy over it. Not trying to impersonate the team or talk on their behalf

[greenrobot-team]

The Gradle plugin including the generator source code is now available at https://github.com/objectbox/objectbox-java-generator. Sorry that it took us this long, but as mentioned before please be aware some work had to be done to prepare the sources (like make it independent from our internal infrastructure etc.).

[papjul]

Thank you very much, I appreciate!

The licensing issue of the Gradle plugin seems fixed to me.

Should this issue be kept open for the runtime binaries part? There is no licensing issue on that one, as they have always been distributed under a proprietary licence AFAIK, but I know that at least in #1102 people hope you will change your mind as, unfortunately, ObjectBox remains ineligible for inclusion in apps of the default F-Droid repository.

In any case, thank you again for the source code of the plugin part!