D
danhunfeldz@mail.com
Tue, Aug 9, 2022 2:53 PM
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.
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.
NH
Norbert Hartl
Wed, Aug 10, 2022 11:08 AM
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
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
OV
Offray Vladimir Luna Cárdenas
Sun, Aug 14, 2022 9:01 PM
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 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
>>
>
S
sean@clipperadams.com
Tue, Aug 23, 2022 1:46 PM
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?
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?
YC
Yanni Chiu
Tue, Aug 23, 2022 3:16 PM
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?
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?
>
PD
PAUL DEBRUICKER
Tue, Aug 23, 2022 5:30 PM
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?
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?
>
EM
Esteban Maringolo
Tue, Aug 23, 2022 5:40 PM
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
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?
> >
>
NH
Norbert Hartl
Wed, Aug 24, 2022 9:28 AM
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
> 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
NH
Norbert Hartl
Wed, Aug 24, 2022 9:28 AM
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.
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?
>>
