Using Gecko in an embedded device?

[Bo Yang]

I want to know is there any precedent that using Gecko
in a embedded device?
Gecko's footprint is about 20M, Is there any way to reduce
this to adapt it to a resource limited embedded device?

Thanks in advance!

[Zac Bowling]

There are projects that reduce that can bring down the size (see
Minimo). You can get it down to 4 to 5 mb if you trim out a good
majority. There are issues though mostly dependent on the requirements
of embedded devices and the platform you are using. Linux based devices
with 8-16mb of memory allocatable to gecko when running (minimum) and
8mb of space to store mozilla is about what you need from what I tested.

We evaluated using Gecko on a recent project at Texas Instruments, but
decided against it in favor of Opera and NetFront from Access (the
company that bought the PalmOS).

Part of it was licensing, since LPGL, GPL, and MLP code is hard to use
with embeddable projects when there is no way to dynamically link in
many embedded OSs' (everything is compiled together including OS and
applications) and then our customers would not really have a way to load
their customized versions of the code on to the device as required under
the LGPL.

The other issue is that Gecko (and most of the Mozilla code base) is
written in C++. I don't have a problem with C++ but using it in an
embedded project is an expensive use of resources. (We use C and ARM
assembly on most of our projects since we have to milk the embedded
controls for all they got, since resources are heavily restricted)

Hope that helps...

Zac

> _______________________________________________
> dev-embedding mailing list
> dev-em...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-embedding
>
>

[Eli Friedman]

Zac Bowling wrote:
> Part of it was licensing, since LPGL, GPL, and MLP code is hard to use
> with embeddable projects when there is no way to dynamically link in
> many embedded OSs' (everything is compiled together including OS and
> applications) and then our customers would not really have a way to load
> their customized versions of the code on to the device as required under
> the LGPL.

I think you misunderstood the license of the Mozilla source code. The
whole MPL/LGPL/GPL tri-licensing thing makes it so that you can use any
one of the licenses of your choice to redistribute. The terms of the
MPL seem unlikely to be an issue for embedding a browser.

-Eli

[Gervase Markham]

Zac Bowling wrote:
> Part of it was licensing, since LPGL, GPL, and MLP code is hard to use
> with embeddable projects when there is no way to dynamically link in
> many embedded OSs' (everything is compiled together including OS and
> applications) and then our customers would not really have a way to load
> their customized versions of the code on to the device as required under
> the LGPL.

I think you misunderstand the MPL terms. The MPL is laxer in this regard
than the LGPL. Firstly, it is quite happy about MPL code being linked
statically with proprietary code. Secondly, it requires that the source
accompany the binaries, but it does not require that you be able to
replace parts of the binaries with new versions compiled with the
source. So the MPL would be fine for the scenario you speak of.

The tri-license allows you to choose which of the three licences you are
going to follow. So you can choose the MPL, and ignore the LGPL and GPL
parts for your purposes.

If you have questions about the Mozilla licensing policy, the newsgroup
mozilla.legal is the place to ask.

Gerv