Importing from other keyboards

Switching keyboards usually means leaving your layouts, themes and dictionaries behind. WM Keyboard reads FlorisBoard, HeliBoard, LeanType and FUTO files directly and converts them into its own, so the grid you built, the theme you picked and the word list you collected come with you.

Conversion is honest about being lossy. A layout import always ends on a confirm dialog that lists what changed and what could not be carried, and nothing is written until you accept it. A .flex theme opened from a file manager gets the same treatment. The FlorisBoard button inside Settings is the one route without a confirm step: it saves the theme straight away and then tells you what it saved. Saved is not switched on, so you still get to look first.

What can be imported

File	From	Opens as
.json layout	FlorisBoard, HeliBoard	A custom layout
.txt layout	HeliBoard	A custom layout
.yaml layout	FUTO Keyboard	A custom layout
.flex theme	FlorisBoard 0.4 and later	One theme, one look per theme in the file
.flex language pack	FlorisBoard	A Cangjie or stroke table for Chinese
Colour theme text	HeliBoard, LeanType	One theme, from a file or from the clipboard
.zip theme	Gboard, the Rboard community	One theme, with a look each for key borders on and off
.zip or .pack theme pack	Rboard	Any or all of the themes inside, each its own theme
.keyman-touch-layout	Keyman	A custom layout, without the keyboard’s rules
.kmp package	Keyman	A custom layout and its typing rules
.combined word list	HeliBoard, LeanType, FUTO, any AOSP keyboard	A custom dictionary
.dict dictionary	HeliBoard, LeanType, FUTO, OpenBoard, GApps	A custom dictionary

HeliBoard’s JSON layouts use FlorisBoard’s format, so one reader handles both. LeanType is a HeliBoard fork, so its layouts and themes are HeliBoard’s.

Keyman is a different story. 862 Keyman key grids are already built into the app, so for most of them there’s nothing to import. You can still open a .keyman-touch-layout file or a full .kmp package yourself, which is how you’d add a keyboard that isn’t bundled or one you’re writing. A .kmp brings its typing rules with it; a touch layout file does not. See Keyman layouts.

Layouts

WM Keyboard›Layout & size›Key layouts›Import from another keyboard

Pick the file. The app reads it, then puts one dialog in front of you before it saves anything. Only one thing on that dialog needs an answer: the language. Everything else tells you what the conversion did, and the Import button is your confirmation.

It asks for the language

The FlorisBoard and HeliBoard formats do not record one. There a layout is a grid and the language comes from the keyboard’s own settings, so the file itself cannot say whether a Cyrillic grid is Russian or Ukrainian. A FUTO layout does state its languages, and the picker starts from that instead of from a guess.

That matters more here than it sounds. The language picks the dictionary, the autocorrect, the script rules, dictation, and how the shift key behaves. The app guesses from the letters on the keys and shows you the guess, and you can change it before you import. There is no silent default.

It adds the bottom row

A foreign layout file carries one grid, and the keyboard that reads it draws the symbols and number layers itself. So the app supplies those, and the imported layout uses WM Keyboard’s built-in symbols and number grids.

The bottom row gets the same treatment, one key at a time. A delete, space or enter key the file did spell out converts like any other key. Any of the three the file left out is added back, and the dialog names the ones it added. HeliBoard’s text format has no way to write any of them, so a .txt layout always gets all three.

Keys that cannot come across

Some keys in those formats do things WM Keyboard reaches another way: voice input, the clipboard panel, the settings screen, the suggestion-bar toggles. Those are tools here rather than keys, so they are removed and the dialog names the codes it removed. A key that looked right and quietly did nothing would be worse.

A handful of keys convert to the closest match rather than an exact one, and the dialog counts those too. Delete-word becomes a plain delete; the second symbols page folds onto the symbols key.

Keys named by a word

HeliBoard’s text format has one field per key, so it spells everything in the label. A key that says delete is the delete key, $$$ is the local currency, aa|bb shows aa and types bb, and abc|!code/-7 names a code outright. The app reads all of it:

In the file	Becomes
delete, shift, space, action, zwnj	That key
alpha, symbol, numpad, emoji, language_switch	The matching layer or switch key
period, comma	The punctuation slots, with this keyboard’s own popups and its email and URI behaviour
ctrl, alt, meta, fn	The modifier keys
com	A .com key. The other keyboard localises this one, so it is counted as approximated
$$$, $$$1 to $$$5	Currency signs. Also localised there, also counted
aa|bb	A key drawn aa that types bb
x|!code/-7	Whatever that code means, here delete
\space	A key that draws the word “space”. A backslash escapes the whole label

A name this keyboard has nothing for, such as dpad, is removed and named on the dialog. An icon name (!icon/previous_key) refers to the other keyboard’s own drawable, so the key keeps whatever its action draws here and the dialog counts the loss.

Keys that change with the shift key or the field

A JSON layout can make one key conditional: case_selector for the shift state, variation_selector for the field, keyboard_state_selector, layout_direction_selector. HeliBoard’s own Dvorak layout is written this way.

One slot here holds one key, so the app keeps the resting branch: unshifted, an ordinary text field, left to right. The dialog counts the keys that lost a branch.

case_selector is the exception and loses nothing. Its two branches are exactly this keyboard’s key and shift-label pair, so both cases come across, and a shifted letter that is only the plain uppercase is left for the keyboard to produce on its own.

Press-and-hold options

The other keyboard writes a popup’s options inside the popup list, wrapped in exclamation marks. !fixedColumnOrder!4 and !autoColumnOrder!4 become that key’s Alternate columns, which you can change afterwards in the layout editor. !hasLabels!, !needsDividers! and !noPanelAutoPopupKey! ask for drawings this keyboard decides for itself and are dropped. None of them is a letter, so none ends up as a key you can type.

Label flags become label sizes

HeliBoard keys can carry a labelFlags number, which is how a layout says that one key’s label is a word rather than a letter and should be drawn at a different size. Layouts with unusual key captions need it to look right.

The app reads it. Four of those flags set a size, and each one becomes that key’s Label size in the layout editor, so you can see it and change it afterwards:

Flag in the file	Label size here
followKeyLargeLetterRatio	×1.15
followKeyLetterRatio	×1
followKeyLabelRatio	×0.68
followKeyHintLabelRatio	×0.44

Two more need no size at all. disableKeyHintLabel turns on Hide the corner hint for that key, which means the same thing. autoScale and autoXScale ask for a label that shrinks to fit its key, and WM Keyboard already does that to every label on every layout.

Write the number in decimal or in hex ("labelFlags": 320 and "labelFlags": "0x140" are the same key). An exported file uses decimal.

The rest of the flags ask for a text style this keyboard has no form of, such as a monospaced or an off-centre label. Those keys keep their size and lose the style, and the dialog counts them.

FUTO layouts

FUTO Keyboard writes its layouts in YAML, and publishes its own as a repository of them. Pick one with the same Import from another keyboard button; the app tells a YAML layout from a JSON one by the document itself, not by the file name. Tapping one in a file manager works too — .yaml is not claimed by name, because that would offer WM Keyboard for every YAML file on your phone, but the YAML content types are, and the same name:-and-rows: test recognizes the file. Either way the language is confirmed before the layout is saved.

Most of that format reads straight across, because FUTO’s keyboard descends from AOSP’s and so its key specs are the ones already read here: a|b, !code/, !icon/ and the same !autoColumnOrder!4 popup markers. A row written as q w e r t, as [[a, ą], b], or as a list of {type: base, spec: …} objects all work, and so does type: case, which keeps both cases the way a FlorisBoard case selector does.

Four things are worth knowing:

• It is the one format that states its language. languages: [lt] seeds the language picker with a fact rather than a guess from the letters. A language this app does not have falls back to the guess.
• The number row is dropped, because this app adds one from a setting and keeping the file’s would give the layout two. A layout that sets numberRowMode: AlwaysEnabled, which is how the PC-style arrangements carry their backtick and bracket keys, keeps its own.
• $space takes what is left of its row, measured against the widest row of ordinary keys in the same layout, so a ten-key grid and a twelve-key one both end up with a spacebar spanning the middle.
• The alternate pages are dropped and named. $alt0 and its siblings switch to a whole second grid, which has no slot here, and a key that switched to nothing would strand you on it. The symbols and number layers are this app’s own for the same reason, and layoutSetOverrides names layouts by ids that mean nothing here.

$contextual becomes the comma slot, which does the same job from the same signal: / in a web address, @ in an email field.

Letters are rewritten to one spelling

Some letters can be written two ways in Unicode: a base letter plus a mark, or a single character that means the same thing. Bengali, Devanagari, Gurmukhi and Oriya all have letters like this. WM Keyboard’s cluster shaping and its backspace rules use the single-character spelling, so the app rewrites the other one on the way in. Without it a key looks correct and then deletes half a letter at a time.

Dictionaries

WM Keyboard›Typing›Suggestions›Custom dictionaries›Import word list

Every AOSP-derived keyboard shares one dictionary ecosystem, and for most languages a compiled .dict is the only form the word list exists in. All of it imports here as it is: the .combined source lists a dictionary repository publishes, the compiled .dict files HeliBoard, LeanType and FUTO download (including the ones pulled out of a GApps package), and the version 4 dictionaries those keyboards write on the device.

What each part becomes

An AOSP dictionary holds three things, and each goes where this app keeps that kind of thing:

In the dictionary	Here
Words and their frequencies	An ordinary text word list
Word pairs (bigrams), and word triples in a version 4 file	Next-word predictions, like a downloaded Word pairs pack
Shortcuts, such as omw for “on my way”	The first suggestion when you type the short form in full, and a trigger for glide typing

When the file has more than words, a dialog asks which of the three to import. The pairs and shortcuts are stored beside the word list and follow it: switch the list off and they stop, delete it and they go. A list imported for its pairs alone still shows on the Custom dictionaries screen, with no words in it, so there is something to switch and delete.

A .dict is unpacked into an ordinary text list at import, so everything the Custom dictionaries screen does to a list you wrote yourself works on it too: the word count, the switch, the trash icon, and taking a single word out from the suggestion strip.

Frequencies are 0 to 255 over there and 0 to 10000 here, so they are scaled rather than copied. Copying them would drop every imported word below every bundled one. A pair’s strength is scaled onto the counts of a downloaded pack, where the strongest pairs weigh about as much as a pair you typed a few dozen times yourself.

A shortcut the source keyboard applied on its own (a “whitelist” shortcut) is offered here, never applied. A file built with a codePointTable, which spells the most common letters of a language in one byte each, is read through that table.

Your learned words from HeliBoard or LeanType

Those keyboards keep what they learned from your typing in a user history dictionary, in the version 4 format. That format is a folder of two files, NAME.header and NAME.body, so there are two ways in:

• Make a backup in HeliBoard or LeanType and import the .zip. The app takes out every dictionary in it, one list each, and ignores the layouts, blacklists and images a backup also holds. Each dictionary shows the language code it was written for, so you can leave out the ones for another language.
• Or select the .header and the .body together in the file picker.

A user history keeps counts rather than frequencies, so a word you typed often there arrives ranked higher, and a pair you typed twelve times weighs twelve times the pair typed once. Words that keyboard had blacklisted do not come across.

Only one shape is refused: revision 402 of version 4, which no current keyboard writes.

See Dictionaries & words for the screen itself.

Chinese code tables

WM Keyboard›Languages›Chinese›Chinese options›Import from FlorisBoard

FlorisBoard’s other kind of .flex is a language pack: an SQLite database of the shape-based Chinese tables, where a code spells a character by how it looks rather than how it sounds. Those are the same tables this app’s own Cangjie and Stroke packs hold, so a pack you already have fills one without a download.

The rows are written exactly where a download would have put them, so everything else on that screen keeps working on it: the row says Downloaded, the keyboard picks the table up at the next field you tap, and the trash icon removes it.

Two things are worth knowing:

• Only Cangjie and stroke land. A pack often holds Wubi, Zhengma, Boshiamy and others as well, and this keyboard has no way to type those, so a table for one would be a large file that changed nothing. The app names the tables it found back to you instead. Cangjie Quick needs no table of its own: it is the same codes queried differently.
• How common each character is survives the import. The pack FlorisBoard ships stores that as a fraction between 0 and 1, in a column its own converter labels as a whole number, so it is read by what the file actually holds rather than by what the column claims. Without that every character imported as equally common, and which one a code offers first is decided by exactly this number.
• A stroke table is rewritten as it is read. Those tables spell the five strokes as the letters h s p n z; a stored code here is always 1 to 5. Without that translation every row would be dropped for having a code no key can produce.

Pick the wrong .flex and the app says so rather than failing: a theme file is named as a theme, with Themes as the place to take it.

Themes

WM Keyboard›Appearance›Keyboard themes›FlorisBoard

A .flex file is FlorisBoard’s theme package. Pick one and the app converts every theme inside it. You can also open a .flex straight from a file manager.

A FlorisBoard extension that holds both a day and a night version becomes one theme with two looks, not two separate entries, and an extension with more themes than that becomes one theme with that many looks. The first look heads the family and the rest become variants of it. The family takes the title the extension declares for itself, or the first look’s own name when it declares none. Auto theme addresses the looks individually, so you can still put the day one in one slot and the night one in the other under WM Keyboard›Appearance›Keyboard themes›Auto theme. The result message says so too: “The app saved name with 2 looks.”

Converted themes are saved but not turned on. They go into your themes list for you to look at first, and the theme editor is where you finish the parts that did not carry over.

How much comes across

Open the .flex from a file manager and the dialog puts a number on it: “The app can use 34 of the 52 style rules in this file.” That number counts the rules that changed something the app draws, not the rules it merely recognised. A rule that only sets text wrapping names a part this app has and still changes nothing, so it does not count. That dialog is also where the list below shows up, one line per thing that had nowhere to go.

Colours mostly land. These all have somewhere to go:

• The board, the keys, the pressed key, the enter key, the function keys, borders and per-key colours.
• The key popup and its border, and the corner hint. A theme that styles only the emoji popup gets that bubble for both.
• The toolbar: the tool icons, the circle behind them, the active toggle and the glyph on it.
• The suggestion strip: the suggestion text, the quieter second line, the dividers, the clip chip, and a chip’s selected colours.
• The panel cards, the bottom sheets, the navigation bar band and the glide trail.
• Key and hint text sizes, bold labels, and the corner shape of keys, popups, chips, cards and menus.
• The shape of a single key. A theme that makes only the enter key round keeps it round here.
• Shadows. The lift under the keys, the popup, the panel cards and the toolbar tools. Nearly every bordered theme raises its keys 2 dp, and without this they came across flat.
• The selected highlight in a popup: the colour behind the letter your finger is on when you hold a key, and behind the selected row of the language list.
• The one-handed rail beside the keyboard, which had no way to differ from the board before.
• The floating keyboard’s handle, which takes the toolbar’s own colours here.
• The panels. A clipboard notice’s heading and body, the buttons inside a panel, the icon buttons on a panel’s header, the rows of the language list, the emoji keys, and the clipboard’s dialogs. None of these is a separate colour here, so each lands on the one the keyboard already draws it with.
• A board background image and a key texture.
• A font the theme ships with itself. A .flex can carry its own typeface, declared as @font \ndot`and pointed at withfont-family`. Two of the six themes on the FlorisBoard addon store do exactly that, and for one of them the dot-matrix face is the theme. The file is installed as a font add-on of its own, under the name the stylesheet gave it, and the converted theme is set to use it. It then appears in WM Keyboard›Appearance›Keyboard font like any other installed font, and other themes can use it too.

Colours that follow the wallpaper are read too. A FlorisBoard theme may name a Material You role, such as dynamic-dark-color(surfaceContainerLow), instead of a fixed colour. On Android 12 and later the app resolves those against the same system palette FlorisBoard reads, so a theme written that way arrives with its colours rather than empty. Two of the most-used theme packs are written entirely this way.

On a phone below Android 12 there is no such palette, so those colours resolve against stock Material instead and the dialog says that rather than claiming your wallpaper was read.

And they keep following it. The converted theme remembers which Material You colour each part came from, so when you change your wallpaper the keyboard moves those parts onto the new colours, the same as FlorisBoard does. The theme’s Follow wallpaper colors switch in the theme editor is on after the import; turn it off to keep the colours you have today. A colour you change in the editor stays as you set it. A theme imported before version 0.5.13 has no such record: import it again to get this.

Themes from other keyboards, and FlorisBoard themes written in fixed colours, can follow the wallpaper as well. They start with the switch off, and when you turn it on each colour keeps its lightness and takes your wallpaper’s hue.

FlorisBoard styles a much larger set of keyboard parts than this app draws, so the rest is reported rather than approximated:

• Per-corner radii. Keys here have a single corner size.
• Spacing on single elements. The key gap is set for the whole keyboard.
• A font the theme only names. Some themes name a font family without shipping it. There is nothing to install in that case, so install the font yourself and pick it in the theme editor. A theme that sets font-family: inherit, which is what both of the big theme packs do on every rule, is asking for no font change at all, so nothing is reported for it.
• Shadow colours. The lift carries, the colour it is drawn in does not, and Android ignores one below version 9 anyway.
• Text wrapping and alignment. How many lines a label may take, where it is cut and how it is aligned are set by this app, not by the theme.
• The landscape text editor. When a field fills the screen in landscape, Android draws that editor, not this app, so a theme cannot colour it here. The dialog names the parts it could not use rather than saying only that there were some, and for the usual theme packs this editor is most of that list.

If a key’s text colour would be genuinely unreadable on what sits behind it, the app drops the imported colour and picks a readable one, and says so. The test is made against what you actually see: a borderless theme’s keys are transparent, so its labels are judged against the board showing through rather than against the empty key.

HeliBoard and LeanType themes

WM Keyboard›Appearance›Keyboard themes›HeliBoard

Those keyboards have no theme file. A theme is a line of JSON that you copy out of the menu at the top of their colour screen, which is why their theme collections and their whole sharing culture live in forum posts rather than in downloads. So the HeliBoard button asks where the theme is: Paste takes it off the clipboard, Open a file takes a .json somebody saved it into. LeanType is a HeliBoard fork whose colour screen is unchanged, so its themes are the same thing.

Both of that keyboard’s export shapes are read:

• The ten named colours, which is what its few colours and more colours modes export. The board, keys, functional keys, spacebar, key text, hint text, suggestion text, spacebar text, accent and glide trail.
• Every internal colour role, which is what its all colours mode exports: forty-odd values covering the popups, the suggestion strip, the toolbar, the emoji board, the clipboard chips and the navigation bar. This is the richer of the two and is what a carefully built theme is usually in.

A colour that keyboard worked out for itself stays worked out. Its export marks each of the ten as chosen or derived, and a derived one is left unset here so this app derives it in turn. Freezing it in would leave you unable to tell a colour you picked from one that was guessed.

Two colours land on single keys rather than on the board: the spacebar’s own background and label, and the shift key’s icon colour, all of which become per-key styles you can see and change in the theme editor.

The result message counts what landed: “The app saved Midnight and used 19 of its 19 colours.” A colour with nowhere to go here, such as the emoji search field’s own text colour, is counted as read and not used.

A theme is saved rather than switched on, the same as a FlorisBoard one, so you get to look at it first. Day or night is decided from the board colour, since neither shape records it.

FlorisBoard 0.4 themes

Both style formats are read. FlorisBoard renamed several parts in 0.5 (the board went from keyboard to window, the popup from key-popup to key-popup-box), but the colours and the way they are written did not change, so a 0.4 theme converts as well as a 0.5 one. Most themes still in circulation are the older format.

Gboard themes and Rboard packs

WM Keyboard›Appearance›Keyboard themes›Gboard

A Gboard theme is a .zip holding a metadata.json, one or more .css style sheets in Gboard’s own dialect, and the pictures they name. It is what Gboard exports and imports, and the format the Rboard community has shared several hundred themes in. An Rboard pack is a ZIP of those ZIPs, with a picture of each theme beside it.

The Gboard button offers two ways in:

• Open a file reads a theme or a pack you already have. A pack lists its themes first: press one to see it, or Add all to save every theme in it as its own entry.
• Browse Rboard opens a list of the packs in the Rboard repository (GboardThemes/PackRepoBeta on GitHub). The app asks GitHub for the list only when you open that screen, and for a pack only when you press it. Each pack is checked against the SHA-256 the list gives for it before it is opened, and kept in the cache so a second look costs nothing. While Data saver is on, the screen asks before its first request, and the answer covers the packs you open from it. If the Rboard list ever changes shape, the screen says it cannot read it rather than showing a half list; a theme ZIP from anywhere still imports through Open a file. The Google Play build leaves Browse Rboard out, and its Gboard button goes straight to Open a file; the GitHub and F-Droid builds have both.

Either way, each theme ends on a dialog with a preview of it, a count (“The app can use 29 of the 139 style rules in this theme”), and a line for each loss below. Import saves it; nothing is switched on.

Key borders become two looks. Gboard draws a theme with or without key borders by a setting of its own, and a theme ships a separate style sheet for the bordered version. Both come across, as two looks of one theme, the one the theme prefers first. A theme whose border sheet changes nothing this app draws comes across with one look.

What lands:

• The board colour, the bar above the keys, and the navigation bar band.
• The keys, the pressed key, the function keys and the enter key, including the round badge Gboard draws behind the enter icon in a borderless theme. The space bar’s own colour and label become a per-key style.
• Key outlines and their width, the corner size (a large one becomes a pill, and an empty shape means no key face at all), and the lift under the keys.
• Key text, the corner hint, the suggestion text and its dividers, the toolbar icons, the popup and its selected highlight, the glide trail and the accent.
• The background photo, and a separate landscape photo when the theme has one. A picture on the keys becomes a key texture.
• Light or dark, from the theme’s own flag.

Gboard styles far more than this app has, so most of a theme’s rules name things with nowhere to go here: GIF and sticker search, the translate bar, Gboard’s access points. Those are counted, not listed. What a person would notice is named on the dialog instead:

• Compiled or missing style sheets. Gboard can compile a sheet to a binary form (.binarypb) whose format is not published. The readable sheets are used; a theme that is compiled through and through is refused with a message that says so. Gboard’s own stock themes are all of this kind.
• Key icons. Many themes replace the shift, delete and enter pictures. This app draws its own icons.
• The space inside each key. Gboard pads each key separately; here one gap is set for the whole keyboard.
• Fonts. A Gboard theme names a font and never carries the file.
• Shadow colours. The lift comes across, the colour of the shadow does not.
• Corners rounded one at a time, usually the top of the keyboard.
• Pictures on other parts of the keyboard, such as the bar’s tabs.
• Unreadable text. A key, function-key or popup text colour too close to what sits behind it is replaced with a readable one, and the dialog says so. The enter icon and the space bar label are exempt from the line: most community themes draw the first as a picture and hide the second on purpose, so a colour there is often the key’s own and was never meant to be read.

A sheet that breaks the rules is read as far as it goes. A stray ;, a nine-digit colour, a comment that never closes, a variable used before it is defined and a metadata.json with junk after it all happen in real themes, and none of them stops the import. Eight hex digits are read as Gboard writes them, alpha last (#FFFFFF33 is a faint white).

Details & edge cases

• Almost nothing is decided by the file extension. A file is read and then judged by the format tag inside it. The one exception is this app’s own theme file, which carries no tag, so a .wmtheme.json name is the only evidence a file was meant to be a theme. Tagged formats are checked first, so a layout from another keyboard renamed .wmtheme.json is still refused rather than imported as an empty theme.
• Opening a .flex from a file manager works because the app registers that extension. If FlorisBoard is installed too, Android asks which app should open it.
• A Gboard .zip opens from a file manager by what is inside it. .zip is far too common to claim by name, but the app is offered for ZIP files by type, and one with a Gboard metadata.json or an Rboard pack.meta at its root is recognised. A pack opened that way has no list to pick from, so Import adds every theme in it.
• Size caps. A theme or pack is read up to 48 MB inflated, 4 MB per picture, 128 themes per pack; a downloaded Rboard pack is refused past 32 MB. Entry names are only ever looked up, never used as paths.
• Foreign layout files are not auto-detected from a file manager. They carry no marker that identifies them, so they go through WM Keyboard›Layout & size›Key layouts›Import from another keyboard, where you have already said what the file is. This app’s own .wmlayout.json files do open from a file manager, because they carry a format tag.
• A foreign layout over 4 MB is refused. The whole file is decoded as one string, so there is a cap, and the cap is 4 MB. Past it you get the same “The app cannot read that file as a layout” message a genuinely unreadable file gets, with nothing to say the size was the problem. No real grid is anywhere near it, so in practice this only catches a file that is not a layout at all.
• Add-on repositories stay native. Repository payloads are always WM Keyboard’s own formats; conversion applies to files you pick yourself.
• Nothing is sent anywhere. Conversion runs on the phone. There is no upload and no server. Browse Rboard is the exception to “no server”: it downloads from GitHub, and sends nothing about you.

Licences

WM Keyboard reads these formats from their published descriptions. No code from either project is used: FlorisBoard is Apache-2.0 and HeliBoard is GPL-3.0, while WM Keyboard is MIT.

Gboard’s theme format has no published description, so its reader was written from the themes in the Rboard repository rather than from any Gboard or Rboard code. Rboard themes state no licence. A theme you import stays the work of whoever made it, and a pack’s author is named on the dialog; ask before you publish one.

A .flex records its author and its licence, and the confirm dialog reads both out when you open one from a file manager. A theme here has no field to hold them in, so that dialog is where they stop. Write them down while they are in front of you. If you publish a converted theme in an add-on repository, keep them with it.