To all Omnibase and Monibase users. It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from https://github.com/ApptiveGrid/MoniBase <https://github.com/ApptiveGrid/MoniBase> and https://github.com/pharo-nosql/OmniBase <https://github.com/pharo-nosql/OmniBase> I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away. As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase. regards, Norbert
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ... Dale [1] https://github.com/GemTalk/RemoteServiceReplication On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name> wrote:
To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase
and
https://github.com/pharo-nosql/OmniBase
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Dale, Itâs not about inventing a âdatabaseâ, itâs a requirement to persist data beyond image start/stop, along with intangibles like having the full source code to tune for individual requirements. In my case the top (desired) requirements are single directory or file per user (scaling), and no additional server process(es) to be monitored for failure mode. Yanni On Mon, Aug 8, 2022 at 12:44 PM Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication
On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name> wrote:
To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase
and
https://github.com/pharo-nosql/OmniBase
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Sorry to have interrupted ... I just remember that folks have moved from OmniBase to GemStone in the past for "performance reasons" and understand that those aren't the only reasons for having an OmniBase replacement ... Dale On Mon, Aug 8, 2022 at 10:22 AM Yanni Chiu <yannix7db@gmail.com> wrote:
Dale,
Itâs not about inventing a âdatabaseâ, itâs a requirement to persist data beyond image start/stop, along with intangibles like having the full source code to tune for individual requirements. In my case the top (desired) requirements are single directory or file per user (scaling), and no additional server process(es) to be monitored for failure mode.
Yanni
On Mon, Aug 8, 2022 at 12:44 PM Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication
On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name> wrote:
To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase
and
https://github.com/pharo-nosql/OmniBase
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Dale, there is really no need for an excusion :) I found your pointer really informative and what you are saying is always interesting. But yeah, Yanni has a point here. I was pretty satisified with Omnibase because it is easy to handle being smalltalk and running in the same image. Supporting ACID transactions with MVCC is even a strong point. Performance is an important point. But performance is mostly defined by the use case and the architecture you choose for that. And our setup can scale out quite well I suppose. Norbert
Am 08.08.2022 um 22:34 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Sorry to have interrupted ... I just remember that folks have moved from OmniBase to GemStone in the past for "performance reasons" and understand that those aren't the only reasons for having an OmniBase replacement ...
Dale
On Mon, Aug 8, 2022 at 10:22 AM Yanni Chiu <yannix7db@gmail.com <mailto:yannix7db@gmail.com>> wrote: Dale,
Itâs not about inventing a âdatabaseâ, itâs a requirement to persist data beyond image start/stop, along with intangibles like having the full source code to tune for individual requirements. In my case the top (desired) requirements are single directory or file per user (scaling), and no additional server process(es) to be monitored for failure mode.
Yanni
On Mon, Aug 8, 2022 at 12:44 PM Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication <https://github.com/GemTalk/RemoteServiceReplication> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase <https://github.com/ApptiveGrid/MoniBase>
and
https://github.com/pharo-nosql/OmniBase <https://github.com/pharo-nosql/OmniBase>
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Hi Dale, thanks for the pointer. I always admired what the GemStone people did and do. But I'm looking for something more lightweight and more easy to handle approach this time. Well, from the github page I could not derive what it really does to be honest. Hope to see you at ESUG, Norbert
Am 08.08.2022 um 18:44 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication <https://github.com/GemTalk/RemoteServiceReplication> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase <https://github.com/ApptiveGrid/MoniBase>
and
https://github.com/pharo-nosql/OmniBase <https://github.com/pharo-nosql/OmniBase>
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Norbert, Ooops you are right! RSR is an object replication framework that replicates objects between Pharo, Dolphin, and GemStone images. Kurt Kilpela will be giving a talk at ESUG this year so if you are going to ESUG you can get more details right from the horseâs s mouth:) Dale [1] https://downloads.gemtalksystems.com/docs/GemStone64/3.6.x/GS64-GemBuilderfo... Sent from my iPhone
On Aug 9, 2022, at 3:21 AM, Norbert Hartl <norbert@hartl.name> wrote:
Hi Dale,
thanks for the pointer. I always admired what the GemStone people did and do. But I'm looking for something more lightweight and more easy to handle approach this time. Well, from the github page I could not derive what it really does to be honest.
Hope to see you at ESUG,
Norbert
Am 08.08.2022 um 18:44 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication
On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name> wrote:
To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase
and
https://github.com/pharo-nosql/OmniBase
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Norbert, I wonât be going to ESUG this year ⦠travel to Europe has always been tough for me and at my age ð¨âð¦³I want to limit my exposure to COVID⦠Perhaps next yearð¤. Dale Sent from my iPhone
On Aug 9, 2022, at 3:21 AM, Norbert Hartl <norbert@hartl.name> wrote:
Hi Dale,
thanks for the pointer. I always admired what the GemStone people did and do. But I'm looking for something more lightweight and more easy to handle approach this time. Well, from the github page I could not derive what it really does to be honest.
Hope to see you at ESUG,
Norbert
Am 08.08.2022 um 18:44 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication
On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name> wrote:
To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase
and
https://github.com/pharo-nosql/OmniBase
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Hereâs Kurtâs talk from Camp Smalltalk Supreme[1]. Dale [1] https://www.youtube.com/watch?v=uLF2S6fq5a4 Sent from my iPhone
On Aug 9, 2022, at 6:53 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Norbert,
I wonât be going to ESUG this year ⦠travel to Europe has always been tough for me and at my age ð¨âð¦³I want to limit my exposure to COVID⦠Perhaps next yearð¤.
Dale
Sent from my iPhone
On Aug 9, 2022, at 3:21 AM, Norbert Hartl <norbert@hartl.name> wrote:
Hi Dale,
thanks for the pointer. I always admired what the GemStone people did and do. But I'm looking for something more lightweight and more easy to handle approach this time. Well, from the github page I could not derive what it really does to be honest.
Hope to see you at ESUG,
Norbert
Am 08.08.2022 um 18:44 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication
On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name> wrote: To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase
and
https://github.com/pharo-nosql/OmniBase
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Hi all, We have been using ReStore[1] as a lightweight approach to data persistence and ODBC handing form Pharo/GT with pretty good results, as can be showcased in our #CandidatosEnDatos (candidates in data) project [1a]. [1] https://github.com/rko281/ReStoreForPharo [1a] https://mutabit.tiddlyhost.com/#CandidatosEnDatos The microwiki is in Spanish, but there are some data storytelling and visualization we did regarding the candidates for the past presidential elections in Colombia (screenshot below and you can zoom them and fine others in the site linked above). We used ReStore as the database backend to store and query around 10 thousand tweets for over a month from all the presidential candidates in Colombia a store them in a SQLite database. Then we made several visualizations and inject them using Norbert's excellent Mustache for Pharo into a LaTeX template to produce the data visualizations as high definition PNGs. ReStore worked more than well, helping us with all the object-relational mapping and migration, with just some desired features we would like to have but any deal breaker and we didn't find any problem with our SQLite backend regarding performance or size of the information we wanted to work with. I know that ReStore has support for other database engines. Unfortunately I had to cancel my participation to this year ESUG, so I wont be able to share more details about this and other projects I was showcasing there. And maybe a project about data storytelling and visualization for civic tech is pretty far away of most use cases where a Object-relational mapper is needed... or maybe not and this combination could work for other people too. I'll be happy to share more details if that the case. Enjoy ESUG and hopefully we will find soon in virtual events or next year in ESUG. Cheers, Offray On 9/08/22 5:20, Norbert Hartl wrote:
Hi Dale,
thanks for the pointer. Â I always admired what the GemStone people did and do. But I'm looking for something more lightweight and more easy to handle approach this time. Well, from the github page I could not derive what it really does to be honest.
Hope to see you at ESUG,
Norbert
Am 08.08.2022 um 18:44 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Norbert, Before you go off and invent a data base, you might take a look at GemStone and RemoteServiceReplication[1] ...
Dale
[1] https://github.com/GemTalk/RemoteServiceReplication
On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norbert@hartl.name> wrote:
To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase
and
https://github.com/pharo-nosql/OmniBase
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Hi Norbert,
This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase <https://github.com/ApptiveGrid/MoniBase>
and
https://github.com/pharo-nosql/OmniBase <https://github.com/pharo-nosql/OmniBase>
I hope you are aware that all of GitHub is archived by Software Heritage. MoniBase doesn't seem to be in there yet, but there are a few repositories called OmniBase, some of which belong to accounts associated with Pharo: https://archive.softwareheritage.org/browse/search/?q=OmniBase&with_visit=tr... Deleting a repository from GitHub doesn't delete its archival copy on Software Heritage. Removal there has to be requested explicitly: https://www.softwareheritage.org/legal/content-policy/ Cheers, Konrad
This is on the Cincom site regarding OmniBase: #### Licence Agreement The OmniBase object database is provided as it is and with all faults, known or unknown. The source code and other information contained in the source code package is COPYRIGHT (C) by David Gorisek (the author). Portions of the source code can not be used without prior authorâs written permission. OmniBase object database is licenced and sold under a âper developer sitâ licence model. You may install and use an unlimited number of copies of OmniBase object database on computers, including workstations, terminals  or other digital electronic devices to design, develop, and test your software application(s), however, you must acquire and  dedicate a license for each separate developer who is developing software using OmniBase. A license for the OmniBase object database may not be shared or used concurrently by different users. In no event shall the author be liable for any special, incidental, indirect, punitive or consequential damages whatsoever arising out of or in any way related to the use of or inability to use the OmniBase object database. By using the OmniBase object database you accept this licence agreement and the fact that you are using the database at your own risk. The author reserves all rights not expressly granted to you in this License agreement. The OmniBase object database is protected by copyright laws of the Republic of Slovenia and other intellectual property laws and treaties.
FYI As the license situation around Omnibase is unlikely to change and such a license is not an enabler for collaboration I came to the conclusion that there is no other way than to start a new OO database (what a surprise! :) ) If you are interested or want to see what will happen in the next months you can have a look at https://github.com/ApptiveGrid/Soil <https://github.com/ApptiveGrid/Soil> After half a day of work it can already serialize and partition a simple graph and store it to disk in a way it can be read back even when partitioned. Thanks to having Fuel we do not need to reinvent the wheel and have serialization/materialization done. Of course this is super simple and does not comes close to anything usable but a good start. I've also added a documentation in the github repo to describe the most important parts for me that I will target. Questions, critiques and laughs are appreciated, Norbert
Am 08.08.2022 um 15:18 schrieb Norbert Hartl <norbert@hartl.name>:
To all Omnibase and Monibase users.
It turned out that neither of those are open source. The author of the database contacted me clarifying the situation that he has the copyright and never released something open source. This means that I will remove the Omnibase repositories in few weeks from
https://github.com/ApptiveGrid/MoniBase <https://github.com/ApptiveGrid/MoniBase>
and
https://github.com/pharo-nosql/OmniBase <https://github.com/pharo-nosql/OmniBase>
I'm very sorry about that but someone just took the code 9 years before, copied it on github and put illegally an MIT license to the repository. We only want free software in our repositories and hence the above will go away.
As we see it essential to have a good OO database in pharo we will see how much effort it will be build a small and simple OO database that can replace Omnibase.
regards,
Norbert
Iâm not fully understanding the issue. Is it that: * The repos are violating the library license (other than the erroneous MIT license, which could easily be updated)? * The fact that OmniBase is not open source violates a principle you have in continuing to host it? If the latter, may I suggest you offer to transfer the repo(s) to a willing party?
There is no need to transfer any repo. Since itâs git-based, every forked repo is as good as the original. Iâve updated the license info on my fork. At some future point, I may delete my fork. IANAL. For a hobby project, the current non-open-source license would probably suffice. Not that long ago, a lot of effort was done to get Squeak (and therefore Pharo) properly Apache/MIT-licensed so as to make the licensing clear for commercial use. Recently I got a new Droplet on Digital Ocean, and a few weeks later I got a Copyright takedown notice. They were going to block my server because they got a report that Copyrighted material was hosted on that machine. The URL they supplied was not my DNS. Seems some automated scanner had flagged the content, but then took two weeks to send out the takedown request, which got sent to me (the new owner of the machine). Iâm not saying that a takedown for Omnibase is going to happen, but the fact that it *could* happen is a sufficient deterrent for commercial use, IMHO. On Tue, Aug 23, 2022 at 9:46 AM <sean@clipperadams.com> wrote:
Iâm not fully understanding the issue.
Is it that:
-
The repos are violating the library license (other than the erroneous MIT license, which could easily be updated)? -
The fact that OmniBase is not open source violates a principle you have in continuing to host it?
If the latter, may I suggest you offer to transfer the repo(s) to a willing party?
From my reading, it seems like whoever posted OmniBase to github 9 years ago added the MIT license without permission and the OmniBase library remains closed source.
On Aug 23, 2022, at 6:46 AM, sean@clipperadams.com wrote:
Iâm not fully understanding the issue.
Is it that:
⢠The repos are violating the library license (other than the erroneous MIT license, which could easily be updated)?
⢠The fact that OmniBase is not open source violates a principle you have in continuing to host it?
If the latter, may I suggest you offer to transfer the repo(s) to a willing party?
There is a comment in one of the commits from 2005 (OmniBase-jf.2) that suggests that OmniBase had a free with restrictions license: http://www.squeaksource.com/@dZ70JMB-R7RDi4-m/Ox-ysyAT Also, licensing was messier these days, some of that mess creeps up until today. Esteban A. Maringolo On Tue, Aug 23, 2022 at 2:30 PM PAUL DEBRUICKER <pdebruic@gmail.com> wrote:
From my reading, it seems like whoever posted OmniBase to github 9 years ago added the MIT license without permission and the OmniBase library remains closed source.
On Aug 23, 2022, at 6:46 AM, sean@clipperadams.com wrote:
Iâm not fully understanding the issue.
Is it that:
⢠The repos are violating the library license (other than the erroneous MIT license, which could easily be updated)?
⢠The fact that OmniBase is not open source violates a principle you have in continuing to host it?
If the latter, may I suggest you offer to transfer the repo(s) to a willing party?
Am 23.08.2022 um 19:30 schrieb PAUL DEBRUICKER <pdebruic@gmail.com>:
From my reading, it seems like whoever posted OmniBase to github 9 years ago added the MIT license without permission and the OmniBase library remains closed source.
exactly.
On Aug 23, 2022, at 6:46 AM, sean@clipperadams.com wrote:
Iâm not fully understanding the issue.
Is it that:
⢠The repos are violating the library license (other than the erroneous MIT license, which could easily be updated)?
⢠The fact that OmniBase is not open source violates a principle you have in continuing to host it?
If the latter, may I suggest you offer to transfer the repo(s) to a willing party?
Am 23.08.2022 um 15:46 schrieb sean@clipperadams.com:
Iâm not fully understanding the issue.
Is it that:
The repos are violating the library license (other than the erroneous MIT license, which could easily be updated)?
It does and I don't want to make that right.
The fact that OmniBase is not open source violates a principle you have in continuing to host it?
It has been put into pharo-nosql organization which we consider a pharo repository for nosql stuff. And with pharo we discourage the use of not open source libraries.
If the latter, may I suggest you offer to transfer the repo(s) to a willing party?
I wrote the message upfront so any party that wants to follow on that should fork. No need to transfer. When I'm removing the repo the forked repo gets detached automatically. So go and help yourself. Norbert
participants (9)
-
Dale Henrichs -
danhunfeldz＠mail.com -
Esteban Maringolo -
Konrad Hinsen -
Norbert Hartl -
Offray Vladimir Luna Cárdenas -
PAUL DEBRUICKER -
sean＠clipperadams.com -
Yanni Chiu