(keitai-l) Re: open source keitai tools (was Re: Re: western phone, imode sit

From: Nick May <nick_at_kyushu.com>
Date: 02/24/02
Message-id: <fc.000f761000068b2c3b9aca00202e4d26.68b37@kyushunet.com>
My main concern with this lot is that I have something for my own site
available under a freeish license.


keitai-l@appelsiini.net writes:
>Actually, though it is easier for someone to commericalize with a
>BSD license, that's not my reason for suggesting it.


.... my main concern with a license is that people would feel happy to
contribute without feeling that their contributions were being "ripped
off". I would not want to preclude commercial use of such libraries, but
would want to discourage commercial re-sale.

js@nooper.com wrote
>These information are not very reliable and often
>people stop updating, because everybody just sucks the
>information without adding to it (I guess this will also
>be Nick's problem

So the license should be as "encouraging" as possible. For script
languages like php this is less of an issue I guess (the fact I "include"
Mika's LGPL'd php i-mode library does not require me to release my crappy
"open sore" php code as open source (Or does it. I don't THINK so - that
is the point of the LGPL.)).

js@nooper.com wrote
>1) Screen resolution (pixel size, text rows and cols,...)
>2) Screen behavior (color issues, rendering,...)
>3) Sound behavior (different soundchips,...)
>4) Handset specialties (special key combinations,
>   configurable cache, different fonts, new firmware
>   versions in newer handsets of same series, URL behavior,
>   different Java behaviour...)

1 and 2 are the important ones to me, 3 and 4 or optional extras. 5 would
be "html-variant" (i-mode html in its various form, jphone parsable
i-mode-html, microsoft pocket browser-html, etc etc - particularly as to
how they handle the tel: and accesskey tags and other platform specific
elements. I handle these in php by sending the parameters and platform
type to appropriate functions and just printing the return and I would
envisage something similar, for personal use at least....)


As a practical point, one issue with such a database would be speed. It
would be pleasantly anarchic to have a fairly promiscuous data set that
would mate with a range of languages. But the more one abstracts, the
slower things get.

Could someone remind me why the LGPL would be inappropriate? I am outside
a bottle of wine currently (just the wine I stress, not the bottle
itself....) and can't quite remember.

Nick
Received on Sun Feb 24 17:54:25 2002