You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/05/24 20:07:24 UTC
Enough object store crap, let's get serious
http://www.sleepycat.com/products/je.shtml
Need I say more? ;-)
Now, the only problem is that this requires java 1.4.2 because of memory
mapped files.
If you ask me, this feature, alone, is enough for throwing 1.3 down the
drain. I mean, if you are running a serious web site and you need tons
of cache, and you are still using 1.3, well this is simply not our
problem and you should be investing to migrate because that's going to
save you tons of headackes anyway.
BerkeleyDB is an ACID database without the client/server overhead and
without fancy querying abilities. Everybody and their dog knows that
BerkeleyDB is the de-facto standard for storing tons of information in a
reliable and efficient way.
I think we should use BerkeleyDB for the cocoon object store and at this
point, even the transient/non-transient nature of things could not be
needed anymore because we can use memory-mapped files or hybrid-memory
cached file backends.
This means that you can forget about your cache. You can showdown your
cocoon and restart it and the entire thing would be there as it was before.
Who's with me?
--
Stefano.
Re: Enough object store crap, let's get serious
Posted by Martin Holz <ho...@fiz-chemie.de>.
Stefano Mazzocchi <st...@apache.org> writes:
> http://www.sleepycat.com/products/je.shtml
[...]
>
> I think we should use BerkeleyDB for the cocoon object store and at
> this point, even the transient/non-transient nature of things could
> not be needed anymore because we can use memory-mapped files or
> hybrid-memory cached file backends.
How do I have to read paragraph 3 of the license at
http://www.sleepycat.com/download/jelicense.html ?
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software.
Would accompanying software include Cocoon, if it uses
the DB?
--
Martin Holz Email: martin@martin-holz.net
F�rther Str .5 Tel.: +49 30 - 214 10 38
10777 Berlin (Wilmersdorf)
Re: Enough object store crap, let's get serious
Posted by Antonio Gallardo <ag...@agssa.net>.
Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>
>> Stefano Mazzocchi dijo:
>>
>>>http://www.sleepycat.com/products/je.shtml
>>>
>>>Need I say more? ;-)
>>
>>
>>>Who's with me?
>>
>>
>> I am with you if and only if, the license compatibility is solved. ;-)
>>
>> BTW, why you don't post this link some months before. It would save us a
>> lot of work!!!!!!! :-)
>
> I became aware of this two days ago at www2004.
Yep. I supposed the discovery is recent. I was just joking, you know.... ;-D
Best Regards,
Antonio Gallardo
Re: Enough object store crap, let's get serious
Posted by Stefano Mazzocchi <st...@apache.org>.
Antonio Gallardo wrote:
> Stefano Mazzocchi dijo:
>
>>http://www.sleepycat.com/products/je.shtml
>>
>>Need I say more? ;-)
>
>
>>Who's with me?
>
>
> I am with you if and only if, the license compatibility is solved. ;-)
>
> BTW, why you don't post this link some months before. It would save us a
> lot of work!!!!!!! :-)
I became aware of this two days ago at www2004.
--
Stefano.
Re: Enough object store crap, let's get serious
Posted by Antonio Gallardo <ag...@agssa.net>.
Stefano Mazzocchi dijo:
> http://www.sleepycat.com/products/je.shtml
>
> Need I say more? ;-)
> Who's with me?
I am with you if and only if, the license compatibility is solved. ;-)
BTW, why you don't post this link some months before. It would save us a
lot of work!!!!!!! :-)
Best Regards,
Antonio Gallardo.
Re: Enough object store crap, let's get serious
Posted by Antonio Gallardo <ag...@agssa.net>.
Steven Noels dijo:
> Which means, IIUC, we could distribute stuff legally, but nobody would
> be able to shrink-wrap and close-source Cocoon without paying Sleepycat
> a fee. That is not what our license has been indicating throughout the
> years, and I honestly don't understand how all the other Sleepycat
> users (like Subversion) cope with this.
+1 This seems to be not compatible with our license. :-(
Best Regards,
Antonio Gallardo
Re: Enough object store crap, let's get serious
Posted by Steven Noels <st...@outerthought.org>.
On 24 May 2004, at 22:44, Steven Noels wrote:
> I was suggesting what would happen if someone wraps Subversion into a
> closed-source product (for whatever stupid reason, like making a
> better M$ SourceSafe). The Subversion license allows this, but BDB,
> shipped with SVN, doesn't.
Eh - correcting myself: BDB isn't "shipped" nor "distributed" with SVN,
of course. But it must be there at compile- and run-time, and there's a
clear dependency as stipulated in clause 3) of Sleepycat's license.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Enough object store crap, let's get serious
Posted by Steven Noels <st...@outerthought.org>.
On 24 May 2004, at 23:05, Stefano Mazzocchi wrote:
> But if it's your product that fetches it from the internet upon
> installation you don't have to pay anything.
I'm not sure whether this kind of "use" would held up in court as not
being the behaviour described in the license, but IANAL, of course.
> That license is just stupid.
True, and I've become increasingly annoyed with this blatant abuse of
the "open source brand" by all producers of dual-licensed
free/commercial softwares.
It's one of the easier, yet decidedly less-free ways to monetize on
open source development, where I like to use "free" in the sense of "I
wrote something cool and want people to use it". They want to make
money on it, and use the open source logo to be cool marketing-wise. In
a wicked sense, this is very similar to the free dogma of the FSF IMHO:
freedom as a duty rather than a right.
<ot>I've been reviewing Debian's policy lately
(http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg), and
stumbled onto a debian-legal discussion between Hans Reiser of reiserfs
fame and the Debian peeps who decided reiserfs should go in the
non-free section. All this stuff hasn't anything to do with the way the
ASF thinks about open source licenses, but it is a fascinating read
nevertheless. If these "volunteer peeps" from Debian can withstand the
urge to shift their ethics around in order to accomodate outside
software developers with a less free attitude, I wouldn't like to see
the ASF become more lax towards the promise upheld to its licensees:
you can *anything* you want, as long as you don't sue us, and provide
proper credit. Mind you that I don't believe in proprietary-wrapping
open source software as well: people should make money on services
around software, rather than on the code itself.</ot>
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Enough object store crap, let's get serious
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> Stefano Mazzocchi wrote:
>
>> You are right: you can't ship your product with this without paying
>> Sleepycat a fee.
>>
>> But if it's your product that fetches it from the internet upon
>> installation you don't have to pay anything.
>
> So either their lawyers find a way to argument THEIR interpretation that
> does not allow this or the license will be changed in some near/far
> future.
This can be said for almost everything.
> back to the jira story.
I'm wide open to suggestions.
--
Stefano.
Re: Enough object store crap, let's get serious
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Stefano Mazzocchi wrote:
> You are right: you can't ship your product with this without paying
> Sleepycat a fee.
>
> But if it's your product that fetches it from the internet upon
> installation you don't have to pay anything.
So either their lawyers find a way to argument THEIR interpretation that
does not allow this or the license will be changed in some near/far
future. Back to the jisp story.
Leszek Gawron
Re: Enough object store crap, let's get serious
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> On 24 May 2004, at 22:36, Leszek Gawron wrote:
>
>>> Which means, IIUC, we could distribute stuff legally, but nobody
>>> would be able to shrink-wrap and close-source Cocoon without paying
>>> Sleepycat a fee. That is not what our license has been indicating
>>> throughout the years, and I honestly don't understand how all the
>>> other Sleepycat users (like Subversion) cope with this.
>>
>> Subversion is open source tool. You never distribute it with your
>> system. So you are free to use it. Managing own commercial projects
>> does not involve redistributing so license also is not violated.
>
>
> I was suggesting what would happen if someone wraps Subversion into a
> closed-source product (for whatever stupid reason, like making a better
> M$ SourceSafe). The Subversion license allows this, but BDB, shipped
> with SVN, doesn't.
You are right: you can't ship your product with this without paying
Sleepycat a fee.
But if it's your product that fetches it from the internet upon
installation you don't have to pay anything.
That license is just stupid.
--
Stefano.
Re: Enough object store crap, let's get serious
Posted by Steven Noels <st...@outerthought.org>.
On 24 May 2004, at 22:36, Leszek Gawron wrote:
>> Which means, IIUC, we could distribute stuff legally, but nobody
>> would be able to shrink-wrap and close-source Cocoon without paying
>> Sleepycat a fee. That is not what our license has been indicating
>> throughout the years, and I honestly don't understand how all the
>> other Sleepycat users (like Subversion) cope with this.
> Subversion is open source tool. You never distribute it with your
> system. So you are free to use it. Managing own commercial projects
> does not involve redistributing so license also is not violated.
I was suggesting what would happen if someone wraps Subversion into a
closed-source product (for whatever stupid reason, like making a better
M$ SourceSafe). The Subversion license allows this, but BDB, shipped
with SVN, doesn't.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Enough object store crap, let's get serious
Posted by Leszek Gawron <lg...@mobilebox.pl>.
> Which means, IIUC, we could distribute stuff legally, but nobody would
> be able to shrink-wrap and close-source Cocoon without paying Sleepycat
> a fee. That is not what our license has been indicating throughout the
> years, and I honestly don't understand how all the other Sleepycat users
> (like Subversion) cope with this.
Subversion is open source tool. You never distribute it with your
system. So you are free to use it. Managing own commercial projects does
not involve redistributing so license also is not violated.
Leszek Gawron
Re: Enough object store crap, let's get serious
Posted by Steven Noels <st...@outerthought.org>.
On 24 May 2004, at 20:07, Stefano Mazzocchi wrote:
> Who's with me?
The Sleepycat license contains:
The following is the license that applies to this copy of the Berkeley
DB Java Edition software. For a license to use the Berkeley DB Java
Edition software under conditions other than those described here, or
to purchase support for this software, please contact Sleepycat Software
by email at info@sleepycat.com, or on the Web at
http://www.sleepycat.com.
and
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software. The source code
* must either be included in the distribution or be available for no
* more than the cost of distribution plus a nominal fee, and must be
* freely redistributable under reasonable conditions. For an
* executable file, complete source code means the source code for
all
* modules it contains. It does not include source code for modules
or
* files that typically accompany the major components of the
operating
* system on which the executable file runs.
... which is the same kind of commercial runtime penalty MySQL carries.
Which means, IIUC, we could distribute stuff legally, but nobody would
be able to shrink-wrap and close-source Cocoon without paying Sleepycat
a fee. That is not what our license has been indicating throughout the
years, and I honestly don't understand how all the other Sleepycat
users (like Subversion) cope with this.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Enough object store crap, let's get serious
Posted by Geoff Howard <co...@leverageweb.com>.
http://www.sleepycat.com/download/licensinginfo.shtml
Stefano Mazzocchi wrote:
> http://www.sleepycat.com/products/je.shtml
>
> Need I say more? ;-)
>
> Now, the only problem is that this requires java 1.4.2 because of memory
> mapped files.
>
> If you ask me, this feature, alone, is enough for throwing 1.3 down the
> drain. I mean, if you are running a serious web site and you need tons
> of cache, and you are still using 1.3, well this is simply not our
> problem and you should be investing to migrate because that's going to
> save you tons of headackes anyway.
>
> BerkeleyDB is an ACID database without the client/server overhead and
> without fancy querying abilities. Everybody and their dog knows that
> BerkeleyDB is the de-facto standard for storing tons of information in a
> reliable and efficient way.
>
> I think we should use BerkeleyDB for the cocoon object store and at this
> point, even the transient/non-transient nature of things could not be
> needed anymore because we can use memory-mapped files or hybrid-memory
> cached file backends.
>
> This means that you can forget about your cache. You can showdown your
> cocoon and restart it and the entire thing would be there as it was before.
>
> Who's with me?
>
Re: Enough object store crap, let's get serious
Posted by Antonio Gallardo <ag...@agssa.net>.
Torsten Curdt dijo:
>> Right. It's viral. The build process will have to fetch it from the
>> outside... but since this is where we are heading anyway.
>
> Maybe we should also switch to maven...
I am +1 to switching to maven!
I will make a vote on the list now....
Best Regards,
Antonio Gallardo.
> --
> Torsten
>
Re: Enough object store crap, let's get serious
Posted by Torsten Curdt <tc...@vafer.org>.
> Right. It's viral. The build process will have to fetch it from the
> outside... but since this is where we are heading anyway.
Maybe we should also switch to maven...
--
Torsten
Re: Enough object store crap, let's get serious
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Stefano Mazzocchi wrote:
> Leszek Gawron wrote:
> Right. It's viral. The build process will have to fetch it from the
> outside... but since this is where we are heading anyway.
Yes but as this would be the core dependency every company that creates
closed source products on cocoon would have to make the source available
or drop the product.
Leszek Gawron
Re: Enough object store crap, let's get serious
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> Stefano Mazzocchi wrote:
>
>> http://www.sleepycat.com/products/je.shtml
>> Who's with me?
>
> * 3. Redistributions in any form must be accompanied by information on
> * how to obtain complete source code for the DB software and any
> * accompanying software that uses the DB software. The source code
> * must either be included in the distribution or be available for no
> * more than the cost of distribution plus a nominal fee, and must be
> * freely redistributable under reasonable conditions. For an
> * executable file, complete source code means the source code for all
> * modules it contains. It does not include source code for modules or
> * files that typically accompany the major components of the operating
> * system on which the executable file runs.
>
>
> <quote>
> complete source code for the DB software and any accompanying software
> that uses the DB software.
> </quote>
>
> does not look like apache-style license, does it ?
Right. It's viral. The build process will have to fetch it from the
outside... but since this is where we are heading anyway.
--
Stefano.
Re: Enough object store crap, let's get serious
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Stefano Mazzocchi wrote:
> http://www.sleepycat.com/products/je.shtml
> Who's with me?
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software. The source code
* must either be included in the distribution or be available for no
* more than the cost of distribution plus a nominal fee, and must be
* freely redistributable under reasonable conditions. For an
* executable file, complete source code means the source code for all
* modules it contains. It does not include source code for modules or
* files that typically accompany the major components of the operating
* system on which the executable file runs.
<quote>
complete source code for the DB software and any accompanying software
that uses the DB software.
</quote>
does not look like apache-style license, does it ?
LG
Re: Enough object store crap, let's get serious
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Stefano Mazzocchi wrote:
> Who's with me?
I thought that their license is not ALv2 compatible, that they require
commercial license for using BerkleyDB in commercial projects. Am I
wrong? If it is, I'd be +1 to see it as an alternative to JCS.
.... reading this:
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software.
leads me to believe that I'm right, and we can't include it into
Cocoon.... :-/
Vadim
Re: Enough object store crap, let's get serious
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 24/mag/04, alle 20:07, Stefano Mazzocchi ha scritto:
> http://www.sleepycat.com/products/je.shtml
>
> Need I say more? ;-)
>
> Now, the only problem is that this requires java 1.4.2 because of
> memory mapped files.
We already decided that 1.4 should be required for Cocoon 2.2, so I
don't think there's a problem here, we can label 2.2 the first version
that comes with BerkeleyDB.
Have you read the license? Do you think it is compatible?
> Who's with me?
Me.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: Enough object store crap, let's get serious
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 24 mai 04, à 20:07, Stefano Mazzocchi a écrit :
> http://www.sleepycat.com/products/je.shtml
> ...Who's with me?
I am, assuming the license is ok.
It would be good to make this a block, so that JDK 1.3 users can still
compile Cocoon by excluding the block.
-Bertrand