[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Directions and Copyright [was Ozone Doc Project]
Falko Braeutigam wrote:
>
> On Tue, 05 Jun 2001, Per Nyfelt wrote:
> >
> > Lets sync our different suggestions. I just put what i did in
> > CVS src/howto/ozone-documentation-howto.xml and also a licence text as
> > src/howto/ozone-documentation-licence.xml. I saw some problems that i tried
> > to solve in this suggestion. As far as i can tell there is no legal body
> > that holds Ozone copyright other than SMB so I put SMB as the copyright
> > holder for the document and propose we do the same for everything else
> > coming, that is if SMB agrees ;)
>
> SMB just holds the copyright for 'the initial code and portions created by
> SMB'. So everybody is free to add his/her copyright to modified files and/or
> put his/her copyright on top of newly created files. At least this was/is my
> understanding from how (L)GPLed code should be handled.
>
> Another, maybe better, possibilitity to handle the copyright problem ist to
> finally switch to a BSD-style license and make 'The Ozone Project' the
> copyright holder. The problem here might be that 'The Ozone Project' ist no
> legal entity. And, it's not sure if ozone is big enough to benefit from a BSD
> (maybe Apache) license and what's the benefit of the different licenses anyway.
>
> That said, personally currently I would prefer a BSD-style license but, in
> contrast to Apache, oblique people/projects/products that use ozone to give
> prominent notice that they do. So we would no longer focus on protecting the
> code (GPL) but from now on focus on popularising our name 'ozone' and benefit
> only from that.
>
> Ideas?
>
> Falko
>
> > Another possibility would be to use the GNU
> > documentation licence. As you'll see this is a very rough and thin draft but
> > i hope we can merge our versions and maybe spawn off some good discussion in
> > the process :)
This might be a good idea.
I'd first like to say that I think the fact that people are interested
in documenting and making tools to make development and maintenance of
Ozone easier and better is great and a compliment to the development
team to date. As such, I really think there needs to be a plan for the
future of the product. Even though the product is open source, it still
has the same basics of any product. It needs to fit a need, carve out a
market, and have enthusiasm for users and developers. It could have
corporate sponsorship, users, etc as well.
The reason I pointed out the Poet/FastObjects.com product as this was a
product that I considered using for the basis of Personal Java or other
embedded type Object storage based applications.
I personally like the GNU GPL license and I think in the Linux Kernel
Linus says that eventhough it is GPL, people can build on top of it. As
I'm not an expert, RMS says that GPL is preferred over LGPL. Anyway, GPL
might not be best for Ozone but it might be fine. Certainly using an API
to build a product on top of it is different to just taking the code and
doing whatever with it as in BSD license case. I can't say from my
limited knowledge which approach is best.
I do know that making Ozone world class is a good thing to do. How do we
do this?
Here are a few questions that if answered could form a statement of
direction, goals, and principles for Ozone that are probably critical
for the future of Ozone.
What are the target uses of Ozone?
What is the scalability?
How well are the code dependencies designed?
This is in reference to what Java platforms or profiles are targeted.
The first J2ME versions such as KVM didn't support Serialization and as
such would support standard RMI. They are also weak on the math front.
In this case I'm trying to get at the basic footprint of Ozone.
What is the client footprint of ozone, Local Objectbase server
footprint? Could it run on KVM on the Palm?
This says what size of RAM/ROM needed to support the libs.
The modules for Ozone is a great idea. The pluggable or semi-pluggable(I
don't have enough knowledge) storage engine is great as this can
increase the dynamic range or scalability of the product.
I went to a talk were they said how the fact that MySQL is designed so
the storage mechanism is independent of the API has allowed a commercial
storage engine to be plugged in.
I know this is just a bunch of partially formed ideas. I do think that
the better we can communicate and document what we are trying to do can
go a long way.
To wrap up, I had a couple of suggestions for a name. I have no idea how
these things would translate to German.
Ozone Persistent Object Storage System. aka Ozone POSS Slogan: Consider
the POSSibilities.
Ozone Persistent Object System Environment aka Ozone Pose.
Object could be Objectbase above. These are in contrast to Object
Database Management System(ODBMS). Of course we had the Objectbase,
Database discussions earlier so you know my opinion that we are not
storing data but we are storing objects.
Pose has two possible meanings in English that are both the first
definitions. (1)If the person has pose, then they have grace, style even
under pressure. (2)A person can pose for a picture. in (1) above the
dictionary says that the origin is French. The definition: pose \'poz\
with a - over the top of the 'o'. 1a. to put or set in place -- this
sounds alot like persistence. Also the word is usually used for
"artistic purposes".
I like the second one(pose), meaning (1) better. The design of storage
without intrusion, just as a normal Java object seems to be one of the
major design goals. The word environment means we can create
deployment, development, and management tools for the system.
Anyway, hope this is what was meant by 'Ideas?' above.
Regards,
Eric