Hi Harald,
I think there's one option that I would prefer:
Having a new library
Ok, one may be a separate library in separate repo, or may be included
into libosmocore as a sub-library, if re-licensing would be successful.
Let's go this way.
like libosmogsmphy (or libosmogsm-phy or
libosmogsm_phy?) which contains
the gsm0503 code and has dependencies to libosmocore and libosmocodec.
IMHO, 'phy' may sound a little bit confusing. I would prefer something
like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix,
because
there are GPRS and EDGE too. Also, this may be a potential place for
other transcoding things, unrelated to GSM at all. We are talking about
channel coging, right? :)
With best regards,
Vadim Yanitskiy.
2016-09-11 11:12 GMT+07:00 Harald Welte <laforge(a)gnumonks.org>rg>:
> Hi Vadim,
>
> On Sun, Sep 11, 2016 at 09:43:58AM +0600, Vadim Yanitskiy wrote:
>
> > There is a problem, related to GSM 05.03 code migration.
> > Please, have a look:
> >
> >
https://gerrit.osmocom.org/#/c/841/1/src/gsm/Makefile.am
> >
> > The problem is that the gsm0503_coding.c has some dependences
> > from libosmocodec, they are:
> >
> > - src/codec/gsm610.c
> > - src/codec/gsm620.c
> > - src/codec/gsm660.c
> >
> > And I have some doubts how to link them properly. As we already
> > discussed with Neels, there are the following possible ways [...]
>
> I think there's one option that I would prefer: Having a new library,
like libosmogsmphy (or libosmogsm-phy or
libosmogsm_phy?) which contains
the gsm0503 code and has dependencies to libosmocore and libosmocodec.
>
> This library could then either be inside libosmocore.git (if we can
> agree to re-license it as GPLv2), or we'd have to maintain it in a
> separate repository (if we have to keep it AGPL). This separation is
> not legally mandator and has no legal significance, it is juts merely
> not to confuse the user to obtain libosmocore.git which contained a mix
> of different licenses.
>
> Regards,
> Harald
> --
> - Harald Welte <laforge(a)gnumonks.org>
>
http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
> A6)
>