-
Notifications
You must be signed in to change notification settings - Fork 302
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
ObjectBox is not entirely FOSS #1102
Comments
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? |
I've rephrased that to reflect better what it's blocking
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. |
This comment was marked as duplicate.
This comment was marked as duplicate.
@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 #560 (comment), 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 ( 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 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 |
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:
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). |
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:
(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)
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. |
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 😢), 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. |
I am glad to hear that, and I really hope ObjectBox will decide to come fully to the "light side"! 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 #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). |
Hello ObjectBox team!
In the instructions on the README of the project, we have these instructions:
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:
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
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
The text was updated successfully, but these errors were encountered: