Siberium

Алексей Сорокин, представитель компании Siberium, свой доклад по открытым решениям для сектора СМБ начал с фундаментального вопроса — какие российские предприятия следует относить к данному сектору? Ответ в российских условиях не вполне очевиден. У западных компаний, напомнил докладчик, есть достаточно четкая внутренняя классификация. Oracle, привел пример г-н Сорокин, к сектору СМБ относит предприятия с годовым оборотом до 150 млн. долл., SAP — до 100 млн. евро. В России, отметил он, предприятия данного сектора “никто не квалифицировал”. Месте с тем, независимо от конкретного размера бизнеса, для многих относительно небольших российских предприятий при невысоких оборотах характерно полноценное производство и сложная логистика, т. е. с точки зрения ИТ требуется полноценная достаточно мощная ERP-платформа, по функционалу — на уровне западной, а позволить себе ее по экономическим соображениям российские предприятия не могут. Здесь и могут выручить (и уже выручают) СПО-платформы, и один из вариантов решения данной коллизии — платформа разработки компании Siberium на базе Adempiere. Данный продукт, по словам Алексея Сорокина, “ERP-решение, а не платформа для программирования”, и если кастомизация продукта на стадии внедрения превышает 10—15% — это ЧП.

Полный текст статьи здесь.

По закону, автору (разработчику) компьютерной программы (или любого иного произведения) первоначально (кроме некоторых особых случаев) принадлежит исключительное право на программу. Исключительное право похоже на право собственности, следовательно, автор (как правообладатель) вправе по СВОЕМУ УСМОТРЕНИЮ использовать и распоряжаться программой, разрешать или запрещать другим лицам использование программы (ст. 1229 ГК РФ). Это значит, что автор может передавать программу пользователю (выпускать программу в свет) по любой лицензии, какая ему нравится (или вообще без каких-либо лицензионных условий). Поэтому российская свободная лицензия ни в каком случае не может автоматически  применяться к программным продуктам, которые созданы и выпущены российскими разработчиками. Российская свободная лицензия, если таковая появится, может использоваться только по желанию данного разработчика применительно к конкретной созданной им программе.

Если программа создана с использование исходного кода, ранее полученного по какой-либо   свободной лицензии (BSD, GNUGPLи проч.), разработчик должен прежде всего выполнять условия этой первоначальной лицензии, относящиеся к созданию и распространение модификаций и производных программ (производные программы – программы,  основанные на полученном исходного коде другого разработчика). Здесь важно отличать простые разрешительные (академические) свободные лицензии на ПО от взаимных (copyleft, авторско-левых) лицензий на ПО.  Простые разрешительные свободные лицензии, например, BSD, не требуют сохранять свободы программы при дальнейшем распространении получателем ни этой же программы, ни производных программ или модификаций. Поэтому программу можно «перелицензировать», т.е. простую разрешительную лицензию можно при дальнейшем распространении заменить на любую другую лицензию (даже собственническую лицензию). Если программа была получена по BSD (простая разрешительная лицензия) и изменена российским разработчиком, то новая (производная) программа может спокойно распространяться по российской свободной лицензии. Но нет никаких обязательных ограничений по территории применения лицензии: например, если пользователь на Западе согласится получить программу на условиях российской свободной лицензии, то программа может быть лицензирована западному пользователю по российской свободной лицензии. Удобный инструмент при распространении свободного ПО – так называемое множественное лицензирование, когда одна и та же программа выпускается одновременно под несколькими лицензиями, например, под BSD(для западных пользователей) и под российской свободной лицензией (для российских пользователей).

Но не все так просто применительно к взаимным лицензиям, основанным на принципе авторского лева, например, GNUGPL. Авторское лево (copyleft) может быть разным, но в целом  принцип авторского лева требует, чтобы программа оставалась свободной в ходе дальнейшего распространения, при любой передаче новому пользователю. В зависимости от конкретной взаимной лицензии, авторское лево может распространяться только на оригинальный полученный исходный код, но не его модификации, в других случаях – как на оригинальный исходных код, так и на модификации,  и производные программы. Иногда авторское лево пытаются распространить также на относительно независимые программные компоненты, взаимодействующие с программой, полученной по взаимной лицензии. В общем, требуется внимательно смотреть конкретную взаимную лицензию, чтобы понять, какие именно правила установлены этой лицензии для сохранения свобод ПО при дальнейшем распространении (какой объем авторского лева предусмотрен). Сложность связана также с тем, что взаимные лицензии иногда требуют, чтобы дальнейшее распространении программы не только обеспечивало сохранение свобод ПО, но более того, производилось только по конкретной лицензии, по которой программа была получена. К таким лицензиям относится, в частности, GNUGPL. Такие свободные лицензии запрещают использовать другие лицензии (даже другие свободные лицензии) при дальнейшем распространении программы/модификаций/производной программы. Следовательно, если исходный код был получен российским разработчиком по GNUGPL, затем  была создана производная программа, то производная программа не может быть выпущена в свет по российской свободной лицензии, но только по GNUGPL, иначе российский разработчик нарушит лицензионные условия GNUGPL. Однако допустимо распространять отдельные модули (программные компоненты), взаимодействующие с GPL– программой, допустим, по российской лицензии, – но это зависит от характера взаимодействия (не углубляясь в детали, образуется в результате такого взаимодействия  одна программа или нет). Если одну свободную лицензию нельзя заменить на другую лицензию в ходе распространения программы, то первая лицензия НЕСОВМЕСТИМА со второй лицензией. Но не всегда также наоборот: например, GNUGPLникогда не разрешает замену GNUGPLна другую лицензию, но некоторые другие лицензии иногда разрешают свою замену на GNUGPL.

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

Лицензий, составленных по российскому законодательству, может быть сколь угодно много, - любой разработчик может написать свою собственную свободную лицензию и распространять по ней созданные им программы. Лицензионный договор – просто юридический текст, он вообще может быть написан любым лицом. Но множество свободных лицензий создает проблему совместимости лицензий друг с другом. По моему мнению, сложность состоит не в том, чтобы написать российскую свободную лицензию как таковую, а в том, чтобы лицензия была хорошего качества, отражала интересы российских разработчиков и пользователей ПО, а значит, имела перспективы (относительно) широкого использования. Это обеспечит российскому свободному ПО более прочную юридическую основу, а следовательно, поможет развитию свободного ПО в России в целом.