Separation of backend library code from app code

[justvanrossum]

Some of Fontra's Python code for reading/writing font files is becoming useful on its own.

To make that part of the code more accessible, it should be available with a less restrictive license, such as Apache.

This applies mostly to:

• https://github.com/googlefonts/fontra/tree/main/src/fontra/backends

The same goes for the entirety of fontra-rcjk:

• https://github.com/googlefonts/fontra-rcjk

The fontra data structures should be part of this, too:

• https://github.com/googlefonts/fontra/blob/main/src/fontra/core/classes.py
• https://github.com/googlefonts/fontra/blob/main/src/fontra/core/packedpath.py

More internal dependencies:

• https://github.com/googlefonts/fontra/blob/main/src/fontra/core/changes.py

Perhaps we should make a new package called fontra-core, that contains all library code.

The Python code left in the main app would be:

• https://github.com/googlefonts/fontra/blob/main/src/fontra/core/fonthandler.py
• https://github.com/googlefonts/fontra/blob/main/src/fontra/core/remote.py
• https://github.com/googlefonts/fontra/blob/main/src/fontra/core/server.py

[davelab6]

Perhaps we should make a new package called fontra-core, that contains all library code.

I don't think that will work so well technically for people who want separate pieces; I would expect each logical unit of code to be its own pypi package. The "mono library" design of fonttools is not widely loved.

If this stuff doesn't make sense in smaller pieces, I am strongly against it, because the Black Foundry strategy for using GPL is to encourage collaboration on the project.

Using Fontra's Python code to read/write source data (designspace/ufo/rcjk) outside of Fontra itself in build workflows, doesn't seem to me that GPL gets in the way, since build workflows aren't distributed to end users. Using GPL code in private is fine.

[justvanrossum]

I don't think that will work so well technically for people who want separate pieces; I would expect each logical unit of code to be its own pypi package. The "mono library" design of fonttools is not widely loved.

FWIW, the intention is for the separate pieces to be logical units of code, and I agree that should be the driving force. But if indeed the license imposes no issues, then I will not rush into such a refactoring.

I do eventually want the Fontra filesystem backend modules (Python) to be installable without pulling in all Fontra's front end stuff (JS).

[davelab6]

Sounds good

I guess we can keep this issue open and revisit when there is a unit of code that would make sense as an isolated pypi package?

The other thing about the copyleft issue is, code under copyleft licenses can be mixed with code under non copyleft licenses that are also libre, and the non copyleft parts remain non copyleft, but the whole thing can't be made proprietary; for that, the copyleft pieces need to be replaced. So if the rest of the other project is mit/apache/etc, it can be fine to add fontra originated code.

[justvanrossum]

The question comes back with googlefonts/fontra-compile#1.

I think I should spec out fontra-core, and we should go for it.

[rsheeter]

The "mono library" design of fonttools is not widely loved

fwiw I have heard the exact opposite claimed as well. I don't claim to know the correct answer :)