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@gnumonks.org>:
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@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)