googlefonts / fontra

A browser-based font editor
https://fontra.xyz
GNU General Public License v3.0
502 stars 21 forks source link

Separation of backend library code from app code #548

Open justvanrossum opened 1 year ago

justvanrossum commented 1 year ago

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:

The same goes for the entirety of fontra-rcjk:

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

More internal dependencies:

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:

davelab6 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

The question comes back with https://github.com/BlackFoundryCom/fontra-compile/issues/1.

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

rsheeter commented 8 months ago

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 :)