Использование морфологического словаря от OpenCorpora в коммерческом проекте?

Question

[Семён Приходько]

Этот словарь является переработкой словаря от AOT (распространяется под LGPL), который в свою очередь базируется на словаре А.А.Зализняка. Материалы OpenCorpora распространяются под лицензией Creative Commons Attribution-ShareAlike 3.0. Соответственно, производное произведение должно распространяться под той же лицензией. Вопрос в том, подпадает ли под этот случай внутреннее использование в коммерческом продукте собственной бинарной базы, полученной из такого словаря? Спасибо.

Answer 1

[kmike]

Производное произведение от словаря — да, под CC. При этом коммерческий продукт может так и оставаться закрытым и коммерческим. Если вы коммерческий продукт распространяете, то нужно просто где-то указать, что словари взяли из OpenCorpora.

Там в FAQ ( opencorpora.org/?page=faq ) написано: «На условиях лицензии Creative Commons Attribution-ShareAlike 3.0. Т.е. бесплатно, но при создании чего-либо на основе этих данных вы обязаны указать, что эти данные взяли у нас, а распространять их дальше можно только на этих же условиях.»

Cначала было вот так написано:

«На условиях лицензии Creative Commons Attribution-ShareAlike 3.0. То есть бесплатно, но при создании чего-либо на основе этих данных вы обязаны, во-первых, указать, что эти данные взяли у нас, во-вторых, лицензировать свой продукт или данные на тех же условиях.»

Т.е. к лицензии CC добавлялось еще ограничение «лицензировать свой продукт на тех же условиях» (смотря как читать); я с ребятами связался и они сказали, что это просто неточность была, такого ограничения нет, и текст переписали.

Если совсем точно знать хотите — спросите в groups.google.com/forum/?fromgroups#!forum/opencorpora-dev, да и на хабре разработчики OpenCorpora бывают.

Comments

[Семён Приходько]

Если коммерческий продукт не является словарём и не позиционируется как словарь, а просто использует его внутренне для решения своих задач?

[kmike]

Словарь — это данные или оболочка к ним? Лицензия — к данным. Вы не можете запретить расковыривать и менять данные, сказать, что это вы все придумали и не указать OpenCorpora как источник. Но вполне можете использовать эти данные в любых целях (втч коммерческих) и закрыть программный код оболочки к словарю — если лицензию на данные сохраните прежней.

Кстати, может интересно будет — pymorphy2.readthedocs.org/en/latest/internals/dict.html — о том, как словарь OpenCorpora упаковывал. Вроде несложно вышло. Сам словарь (со всеми данными) получается мегабайт 10..15 — код библиотеки sqlite может больше места в памяти занять, чем словарь целиком, ну и работает in-memory решение в сотни (если не тысячи) раз быстрее. «Скомпилированную» версию пока нигде не выложил, но если интересно — могу прислать; почта в профиле.

[kmike]

упс, почты в профиле нет, [e-mail]

[Семён Приходько]

А что мешает держать базу в памяти, пользуясь для загрузки SQLite Online Backup API?

[kmike]

Да в принципе ничего; просто в упакованном виде быстрее доступ (я думаю, раз в 100 будет быстрее sqlite), и места занимать будет значительно меньше (думаю, раз в 10-20). Но вполне допускаю, что для многих задач и sqlite будет достаточно.

[Семён Приходько]

Да почему же медленнее в 100 раз, когда база тоже в памяти, а слова не целиком будут храниться (по сути, тот же поиск что и у вас)? Просто sqlite стандартный иструмент, а не велосипед самописный + расширять и поддерживать легче.

[kmike]

По крайней мере из питона вот что получается:

>>> import sqlite3
>>> conn = sqlite3.connect(':memory:')
>>> c = conn.cursor()
>>> c.execute("create table words (word text)")
>>> с.execute("create index word_index on words(word)")
>>> words = ... # загружаем 3млн слов
>>> c.executemany("insert into words values (?)", words_to_insert)
>>> 
>>> import dawg
>>> d = dawg.CompletionDAWG(words)

и потом замеряем:

In [31]: %timeit c.execute(u"select 1 from words where word='ВАСЯ'").fetchall()
100000 loops, best of 3: 7.27 us per loop

In [32]: %timeit u'ВАСЯ' in d
1000000 loops, best of 3: 188 ns per loop

In [33]: %timeit c.execute(u'select * from words where word like "ВАСЯ%"').fetchall()
1 loops, best of 3: 720 ms per loop

In [34]: %timeit d.keys(u'ВАСЯ')
100000 loops, best of 3: 12.3 us per loop

C sqlite имеем где-то 150тыс простых запросов/сек и 1.5 тыс поисков по префиксу, с DAWG — 5млн простых запросов/сек и 80тыс поисков по префиксу (и там, и там — из питона, со всяческими накладными расходами; из C будет быстрее и то, и другое).

Тут несколько объяснений может быть: во-первых, sqlite нужно разбирать SQL-запрос (+ еще куча накладных расходов); во-вторых — индекс там то-ли B-Tree, то-ли хэш, не знаю, но он в любом случае быстрый поиск по префиксам не обеспечивает. Может, конечно, накладные расходы на питонью обертку у sqlite больше — но неужели на столько (какая-нибудь там подготовка запросов). Или может там что-то с sqlite сделать хитрое еще можно. Но базовые структуры данных в sqlite это не изменит.

По памяти — sqlite база заняла где-то 300-400 мегабайт, данные в DAWG — 3 мегабайта.

Оказалось т.е. наоборот — по памяти раз в 100, по скорости раз в 20-50.

[kmike]

Если не целиком слова хранить (а выделять парадигмы или еще как-то), то медленнее получается, т.к. нужно более сложные запросы делать и потом результаты собирать. По памяти, думаю, должно мегабайт 40 получиться тогда.

[Семён Приходько]

Когда попробую, отпишу данные о производительности. Если получится так печально, то придётся велосипедом…

[kmike]

С другой стороны — 150тыс слов/сек с учетом обертки на скриптовом языке — это не очень-то и печально :) Но буду благодарен, если о своих результатах дадите знать потом.

Answer 2

[Busla]

Вы БД в другой формат преобразуете, или же ещё и сам набор данных меняете?

Comments

[Семён Приходько]

Xml словаря переводится, например, в SQLite базу и используется внутри продукта.

Answer 3

[Семён Приходько]

Да почему же медленнее в 100 раз, когда база тоже в памяти, а слова не целиком будут храниться (по сути, тот же поиск что и у вас)? Просто sqlite стандартный иструмент, а не велосипед самописный + расширять и поддерживать легче.