objectbox-java

objectbox-java copied to clipboard

Hello ObjectBox team!

In the instructions on the README of the project, we have these instructions:

buildscript {
    ext.objectboxVersion = "3.3.1"
    repositories {        
        mavenCentral()    
    }
    dependencies {
        classpath("io.objectbox:objectbox-gradle-plugin:$objectboxVersion")
    }
}

The plugin added to the classpath is in MavenCentral, this is the latest published version.

As an educated developer, I downloaded the sources jar, so that I could validate the source code that my app is using.

Inside that file, however, there's only a README file:

Not available yet

And naturally, by downloading the Jar file, only .class files are available.

---

For this reason, the gradle plugin is considered proprietary code. And this has lead F-Droid - the main FLOSS Android distributor - has blocked many apps, such as

• https://github.com/LeoColman/Petals/issues/98
• https://github.com/owntracks/android/issues/1298
• https://github.com/Nonononoki/Hendroid/issues/70
• https://github.com/kiwix/kiwix-android/issues/3091

And probably more to come.

---

This is a very serious bug. I imagine it's somewhere where the code is published to MavenCentral that is not including the source codes.

This issue is a blocker for anyone that wants to integrate ObjectBox to an 100% FLOSS app, such as ones deployed to F-Droid

First, this is not an bug, and being a "blocker" is completely wrong relating to "Open Source" in general. On the upside, it's not as offensive as your first attempt at an ticket, so I won't close the ticket right away.

Then, I am confused. If you have an app, there's no need to ship the plugin. The plugin is only used at build time. Can you please clarify this part?

First, this is not an bug, and being a "blocker" is completely wrong relating to "Open Source" in general

I've rephrased that to reflect better what it's blocking

On the upside, it's not as offensive as your first attempt at an ticket, so I won't close the ticket right away.

The intention was never to be offensive. Maybe aggressive, but not offensive. I'm sorry for offending you and your project. It's a masterpiece of code that you've developed, and that's why I'm trying to solve this specific issue

Thanks for your input! Note that this was/is discussed in #560 already.

Is there any news? Some F-Droid app are still not available :-(

@marek22k If you are interested in this, please thumbs up the first post instead. This helps us track interest.

Hi @LeoColman and @papjul thanks for your pushing for FOSSing ObjectBox!

Given that gradle plugin seems to finally have been opensourced in https://github.com/objectbox/objectbox-java/issues/560#issuecomment-1980184740, can you explain what more more blockers remain here, before ObjectBox can be used in fully-FOSS projects (i.e. to make them eligible for publishing on F-droid)?

@mnalis The native binary is closed source and F-droid doesn't like that as far as I understood from the conversation.

I only requested for GPLv3 components to be open sourced to respect the license. This means only the build-time part was open sourced. The most important part of ObjectBox is still proprietary (objectbox-sync). That's the runtime JNI library (.so) that allows to read in the database.

F-Droid requirements put aside, IMO it's a risk for any project to rely on only one company for such an important component (the database). Having a proprietary database doesn't allow for interoperability. Basically, if they stop maintaining it and it no longer works or something, you can't just use another library and you're stuck with a brick in the worst case scenario. (To be perfectly fair, European laws allow you to reverse-engineer a proprietary component for (and only for) interoperability purposes but good luck with that)

Their previous project greendao is barely maintained and no one else can continue improving/maintaining it if they wish to, because there are still proprietary parts.

The irony? Their database is built upon LMDB which is an open source database. This means that ObjectBox would not have been possible if LMDB wasn't open source (at least, in the state it currently exists).

I wish someone at ObjectBox would understand that. Just like they rely on a wonderful product and improved it, some others may want to do the same.

Given how many open source databases exist out there, it's not hard to replace ObjectBox with something else. I just wish I had known this first so as to not lose time implementing it. They say "you should check the licences of your dependencies on Maven" but objectbox-gradle-plugin doesn't mention that, it's one of many other pulled dependencies that mentions "ObjectBox binary license" and even that one is mixed with 2 other licenses, so the confusion is there…

Thanks for answers, everyone!

For devs: are there any plans to opensource the remainder so it could be used in copylefted projects (like GPLv3 licensed projects, publishing on f-droid etc) but it is just taking some time (as the situation was in #560), or is the plan for proprietary parts to remain proprietary?

@mnalis I guess I can quote from https://objectbox.io/faq/#license-pricing to answer this:

Generally, we want to open source more components at some point, but first we need to figure out some things. We shared a review of the open source landscape in the infrastructure space here. If you need access to the core, please reach out to us individually. We’re currently putting all our efforts in advancing the product. Please contact us if you have questions about this (contact [at] objectbox.io). Thank you.

So TL;DR: yes, but there are things to take care of first.

And for those worrying about maintenance, you already can get source code access for your (commercial) project if you ask. Though I do think the risk is the same with an open source project (think cost and skills required to take over maintenance or just switch to a different product).

So TL;DR: yes, but there are things to take care of first.

Thanks for the answer @greenrobot-team, but both that FAQ you quoted and linked documents seems to be in contradiction of that unequivocal "TL;DR: yes"?

I've wanted to know if you plan to opensource all of the components, but this quote ("we want to open source more components at some point") and linked docs ("In this article, we mean the latter and it inherently entails contributing a useful part of a solution to open source") seems to imply that you intend to open-source only some of the components, and not ALL of them.

So, to clarify, does this "yes, but there are things to take care of first" in comment above means that:

• you've decided to change the strategy and now intend to open source all of the components, but you just didn't have time to update the FAQ and online documentation yet, or
• that FAQ and docs are still correct and you still mean "we only intend to open source some more parts of the code in the future, but not the whole of it" ?

(Note: I'm not here to bash anyone's business decisions or whatever, I'm just interested in clear and unambiguous truthful answer, so everybody can be on the same page and make informed decisions, instead of being potentially misled)

And for those worrying about maintenance, you already can get source code access for your (commercial) project if you ask

If one does ask, under what exact license would they get that fully "corresponding source" (as defined by GPLv3)? One might be interested in paying if such license is to their liking (e.g. if it is GPLv3 compatible).

For the record, I'm not particularly interested about just the maintenance effort needed here, I'm more interested in avoiding vendor lock-in and having fully corresponding source guaranteeing me 4 essential freedoms (as defined by FSF), allowing me to publish the app (using this library) under GPLv3 license. Is there a way I can accomplish those objectives with objectbox (and if so, how)? And if I cannot at the moment, are there plans in motion so I could do that in the (foreseeable) future?

As far as I understand (I'm just a developer) it's complicated (many options, many business-y things to consider) and we don't know, yet. So sorry, I don't have a concrete answer at this point.

Thanks for that answer too @greenrobot-team - even if it is not the one that I would've preferred, I understand that you personally do not have control over it.

We'll have to assume then that the likely outcome is status quo, i.e. that objectbox will remain partly-proprietary software, which cannot legally be used in copylefted FOSS apps (i.e ones published under GPL family of licenses, or ones that want to be published on f-droid.org free software app store etc.)

So, it's refactoring time, in order to replace objectbox with other solution which is compatible with FOSS...

---

Please do let us know in this issue if situation ever changes, though. While it will be too late for some projects (i.e. there is no way people are going to do another refactor just to go back :cry:), it would still help others.

Regarding the "likely outcome"... At this time, the topic is very actively discussed and we'll really try share the outcome soon-ish - e.g. in the next couple of months.

Regarding the "likely outcome"... At this time, the topic is very actively discussed and we'll really try share the outcome soon-ish - e.g. in the next couple of months.

I am glad to hear that, and I really hope ObjectBox will decide to come fully to the "light side"! Please, do keep us posted how that discussion progresses (for better or for worse).

To clarify, the reason for my "likely outcome" guesstimate was that this issue was opened back in 2022 (with few other related issues preceding it, like https://github.com/objectbox/objectbox-java/issues/560 going back to at least 2018), and still not even a decision was made by 2024 to fully opensource it (much less start and finish the actual work of doing it). That being said, I'd really love to be proven wrong about that guess in next few months!