какое утверждение характерно для лицензии на прикладное по с открытым исходным кодом
Открытые (свободные) лицензии (open source): история и действие в условиях российского права после 01.10.2014
С 1 октября 2014 года в России легализованы свободные лицензии (open source). Соответствующие изменения были внесены законодателями в 4 часть Гражданского кодекса.
Теория
История
Внутренние противоречия не прошли мимо и этого движения, и в итоге произошло разделение — одни ратовали за открытый исходный текст ПО, другие борются за свободные программы в целом.
В некоторых странах программные продукты могут быть зарегистрированы как объекты патентного права и на них получены патенты (например, США, Южная Корея, Япония и др). Возникает некое противоречие между открытой лицензией и охраной патентным правом объекта патентования. Возможно, поэтому последние версии открытых лицензий включают в себя условия, ограничивающие автора в использовании своих прав, вытекающих из полученных патентов.
Все эти препятствия приводят к тому, что в большинстве стран правовое положение «свободных лицензий» является неопределенным и часто не соответствует закону страны. Интересно просмотреть судебную практику последних десятилетий:
В России
Но не путем признания существующих свободных лицензий.
А путем предоставления права автору опубликовать свою лицензию на сайте (со ссылкой на нее при скачивании или заключения договора иным способом). А уже сам автор может решить, использовать ли имеющиесялицензии или составить свою.
В принципе, ничто не мешает автору при опубликовании взять текст имеющихся лицензий [7] и использовать их.
Открытая лицензия является безвозмездной, если ею не предусмотрено иное.
В случае, если срок действия открытой лицензии не определен, в отношении программ для ЭВМ и баз данных договор считается заключенным на весь срок действия исключительного права, а в отношении других видов произведений договор считается заключенным на пять лет.
В случае если в открытой лицензии не указана территория, на которой допускается использование соответствующего произведения, такое использование допускается на территории всего мира.
В том числе, возможно и предусмотреть обязанность всех, кто использует ПО на основе открытой лицензии, публиковать модификации ПО, доработки и т.д., делая все это доступным за плату или безвозмездно.
Единственное ограничение: правообладатель может отозвать свою лицензию (расторгнуть договор), если пользователи будут предоставлять больше прав, чем получили сами.
Практика
Такое заявление касается любых объектов авторского права: песен, музыки, картинок, фотографий, программ для ЭВМ и т. д. Публикацию можно будет разместить после 01.01.2015 года.
[1] Операционная система GNU. http://www.gnu.org/
[2] Войниканис Е.А. Право интеллектуальной собственности в цифровую эпоху: парадигма баланса и гибкости. М.: Юриспруденция, 2013
[3] Виды открытых лицензий. http://www.gnu.org/licenses/license-list.html#SoftwareLicenses.
[4] Welte v. Sitecom. Deutschland GmbH, LG Muenchen, 21 O 6123/03; Welte v. Fortinet UK Ltd., Landgericht Muenchen 1, N 21 O 7240/05; Welte vs. Skype Technologies SA 7 O 5245/07.
[5] SFLC v. Monsoon Multimedia, Inc. 07-CV-8205.
[6] Free Software Fdn., Inc. v. Cisco Sys., Inc. United States District Court for the Southern District of New York, case N 08-CV-10764 (S.D.N.Y. Dec. 11, 2008).
[9] На данный момент постановление не принято.
Образование | Лицензии открытого кода: краткое руководство
Все лицензии на программное обеспечение делятся на две больших группы: несвободные (проприетарные) и свободные. У этих категорий есть существенные различия, которые определяют права использования. Открытый исходный код распространяется на основе открытой лицензии. В этой статье мы разберем, какие существуют виды открытых лицензий и что они означают.
Открытая лицензия позволяет свободно и совместно использовать, модифицировать программное обеспечение.
То есть исходный код таких программ полностью доступен. Именно лицензии описывают, что можно делать с этим кодом, а что нет.
В некоторых случаях есть небольшие ограничения, например, разработчики должны сослаться на предыдущих создателей или сохранить принцип открытости при последующем распространении программы.
На схеме показана детализация категорий программ. Изображение с сайта www.gnu.org
Список одобренных лицензий для открытого ПО
Такой список составила организация по продвижению открытого ПО Open Source Initiative. В него вошли несколько популярных подтвержденных лицензий.
1. GNU, General Public License (GPL). В сообществе программистов это одна из ключевых лицензий, которая используется при написании открытого ПО. Ее создал программист, основатель движения открытого ПО и проекта по разработке свободного ПО GNU ( The GNU Project ) Ричард Столлман.
Пользователь имеет право распространять ПО под этой лицензией, участвовать в его разработке или изменять различными способами. Но есть такое правило: любые изменения программы, сделанные пользователем и распространенные им, должны иметь исходный код этих изменений.
Например, под этой лицензией распространяется ядро Linux, MySQL, Asterisk и многие CMS-системы (системы управления содержимым): MovableType, MODx, WordPress, Joomla, Drupal, osCommerce.
2. Apache License 2.0. Гибкая лицензия, которая имеет четкие права. Плюс в том, что они могут применяться к копирайтам и патентам. Некоторые из доступных прав: права безвозмездны, вечны, не эксклюзивны и глобальны. Если вы распространяете код, вы должны указать имя разработчика.
3. BSD (Berkeley Software Distribution). В этой лицензии не такие строгие правила, как в GPL. Разработчики должны выполнить несложные условия: указывать в документации, что в продукте используются разработки создателей оригинального программного обеспечения и не использовать имена (или названия) создателей этого ПО в рекламных целях без письменного согласия.
BSD-лицензий существует несколько видов. Наиболее используемые New BSD/Modified BSD и Simplified BSD/FreeBSD. Лицензия New BSD разрешает распространять ПО с любой целью, не дает гарантий и не несет ответственности за последствия использования. Есть пункт в виде специального разрешения: нельзя использовать имена участников вашего проекта. Между этими лицензиями единственное отличие: в Simplified BSD не ограничено использование имен.
Например, компания Apple использует преимущественно лицензии BSD.
4. GNU Lesser General Public License (LGPL). Появилась в рамках проекта GNU. Дает больше прав, чем GPL. Главное отличие в том, что она позволяет использовать продукты LGPL в проектах, которые распространяются под другими лицензиями.
Один из известных продуктов, выпускаемый под этой лицензией, – офисный пакет OpenOffice.org.
5. MIT license (Massachusetts Institute of Technology). Очень короткая и достаточно свободная лицензия. Она разрешает использовать, копировать и модифицировать программное обеспечение на ваше усмотрение. ПО можно предоставлять бесплатно или даже продавать. Ограничений нет. Но есть ограничение в том, что ваше ПО должно сопровождаться лицензионным соглашением.
Программное обеспечение, которое лицензировано MIT, можно использовать в закрытых продуктах. Лицензия схожа с BSD. Но в MIT можно использовать название продукта и имена создателей в рекламных целях. Под MIT распространяются X Window System (X11) и Ruby on Rails.
6. Mozilla Public License 2.0. Содержит в себе черты BSD и GPL. Исходный код, скопированный или измененный под лицензией MPL, должен быть лицензирован по правилам MPL. Лицензия позволяет объединить его в одной программе с проприетарными (несвободными) файлами.
7. Common Development and Distribution License. Эта лицензия позволяет совмещать открытый и закрытый код, защищенный авторскими правами. Файлы можно совмещать с файлами, которые находятся под другими открытыми или проприетарными (несвободными) лицензиями.
8. Eclipse Public License. Лицензия наиболее подходит для бизнес-ориентированного свободного ПО и базируется на лицензии CPL. У нее более гибкие правила отказа на авторские права.
По мнению разработчика свободного программного обеспечения Сергея Матвеева стоит использовать лицензии семейства GNU GPL. «Мне важно, чтобы мой труд был свободным ПО, чтобы он принес пользу обществу, чтобы никто не смог сделать мое ПО не свободным или использовать его в помощь несвободному, так как это обесценило мой вклад, – объясняет эксперт. – Многие говорят, что не хотят использовать GPL, потому-что хотят свободны, абсолютного отсутствия ограничений. В таком случае подходит только public domain: общественное достояние, где ПО действительно перестает что-то требовать или ограничивать».
С полным списком одобренных лицензий можно ознакомиться на сайте Open Source Initiative.
Вкратце о лицензиях Open Source
Многие разработчики и дизайнеры хотят опубликовать свои работы в виде открытых проектов. Они хотят иметь возможность делиться своим кодом. Сообщество open-source с каждым днём всё прочнее стоит на ногах. Открытые программы существуют для любых видов задач, каких вы только можете себе вообразить. А многие веб-разработчики используют свободное ПО как фундамент для своей работы (WordPress, Drupal и многие другие CMS открыты, свободны и бесплатны).
Но ситуация такова, что лицензий open-source существует великое множество, и подчас нелегко понять что на самом деле они означают. Какие права получают разработчики, когда выбирают ту или иную открытую лицензию? Попробуем хотя бы в общих чертах разобраться.
Что такое лицензирование?
В двух словах: лицензирование даёт определённые полномочия сторонним лицам на использование вашего продукта.
Лицензирование является прекрасной альтернативой простой передаче продукта в общественное достояние или предоставлению разрешения в каждом конкретном случае. Выпустив на публику свой продукт, вы лишаетесь всех прав на него и никто вам ничем не обязан. В особо клинических случаях этот шаг чреват судебными тяжбами, если ваша программа причинила кому-то вред. А во втором случае, вы будете тратить больше времени на выдачу разрешений, чем на саму разработку.
Лицензии open-source предоставляют людям возможность внести свой вклад в проект не спрашивая ни у кого специального разрешения. Они также защищают вас как автора, что гарантирует хотя бы наличие вашего имени в списках разработчиков. Это также обезопасит вашу работу от кражи другими лицами.
GNU General Public License
Лицензия GNU GPL одна из самых часто используемых лицензий для open-source проектов. GPL гарантирует широкий диапазон прав разработчикам, которые работают над открытыми проектами. Она позволяет пользователям легально копировать, распространять и модифицировать ПО. Это означает, что вы можете:
Копировать программное обеспечение.
Копировать на свои серверы, на серверы клиентов, на собственный компьютер, да и вообще куда угодно. Также нет никаких ограничений на количество сделанных копий.
Распространять программное обеспечение по своему усмотрению.
Можете сделать прямую ссылку на своём сайте. Можете записывать на болванки и дарить друзьям. Можете распечатать исходники программы, сделать из них самолётики и пускать с крыши дома.
Зарабатывать на распространении программного обеспечения.
Если вы хотите продавать бесплатное ПО – нет проблем. Но вы обязаны приложить к нему лицензию GPL, в которой разъясняется тот факт, что это ПО вообще-то бесплатное. Многие зарабатывают на технической поддержке, почтовой рассылке дисков и т.п.
Делать какие угодно модификации ПО.
Если вы хотите добавить или убрать какой-то функционал программы – нет никаких преград для этого. Если вы хотите использовать часть кода в своём проекте, вы имеете на это право. Условие состоит лишь в том, что проекты, основанные на GPL должны и дальше распространяться под этой лицензией.
Использовать GPL очень легко. Необходимо лишь внести необходимую информацию в исходный код своей программы и приложить к нему копию GPL.
GNU Lesser General Public License
От GNU появилось много производных лицензий. Самая популярная из них – LGPL. Она даёт несколько больше прав, чем стандартная GPL. Обычно используется для лицензирования библиотек, которым нужно работать в связке с не-GPL и с не-открытыми программами. Так как GPL требует, чтобы ПО с участками GPL также распространялось под GPL, разработчики не могут использовать код под GPL-лицензией для разработки проприетарного коммерческого ПО. LGPL даёт такое право.
Лицензия BSD
Существует целое семейство BSD-лицензий, которые накладывают гораздо меньше ограничений на распространение продукта, чем строгая GPL. Среди всей палитры BSD-лицензий, существуют 2 наиболее используемые: New BSD/Modified BSD и Simplified BSD/FreeBSD. Обе GPL-совместимы и одобрены в качестве свободных лицензий влиятельной организацией Open Source Initiative.
Лицензия New BSD разрешает неограниченное распространение с любой целью, не даёт никаких гарантий и не несёт никакой ответственности. Лицензия содержит также положение, ограничивающее использование имён участников проекта для подтверждения работы без специального разрешения. Говоря нормальным языком, “делайте с кодом что хотите, но не говорите, что это вы его написали”. Основное различие между New BSD и Simplified BSD в том, что последняя не включает в себя пункт этого “специального разрешения”.
MIT License
Лицензия MIT, наверное, самая короткая и самая обобщённая из всех популярных лицензий open-source. Её положения более либеральны, чем в других лицензиях. Основные положения выглядят следующим образом:
Данная лицензия разрешает, безвозмездно, лицам, получившим копию данного программного обеспечения и сопутствующей документации (в дальнейшем именуемыми “Программное Обеспечение”), использовать Программное Обеспечение без ограничений, включая неограниченное право на использование, копирование, изменение, добавление, публикацию, распространение, сублицензирование и/или продажу копий Программного Обеспечения, также как и лицам, которым предоставляется данное Программное Обеспечение, при соблюдении следующих условий:
Вышеупомянутый копирайт и данные условия должны быть включены во все копии или значимые части данного Программного Обеспечения.
Что всё это значит:
Вы можете использовать, копировать и модифицировать программное обеспечение как вам угодно. Никто не может препятствовать вам использовать такое ПО в своих проектах, копировать столько раз, сколько нужно и модифицировать так, как вы хотите.
Вы можете предоставлять своё ПО бесплатно, а можете и продавать его. Нет никаких ограничений по этому поводу.
Единственное ограничение состоит в том, что ваше ПО должно сопровождаться лицензионным соглашением.
Проще говоря, каждый может делать всё, что нужно до тех пор, пока продукт сопровождается лицензией.
Лицензия Apache
Лицензия Apache, версия 2.0, даёт набор чётких прав. Эти права могут быть применимы как к копирайтам, так и к патентам. Так как многие лицензии могут быть применимы только к копирайтам или только к патентам, гибкость лицензии Apache имеет в определённых случаях очевидное преимущество.
Вот основные положения:
Права вечны
Как только они вам предоставлены, вы можете использовать их всегда.
Права глобальны
Если права выданы в одной стране, то они распространяются и во всех других странах. Например, если вы живёте в США, а оригинальная лицензия была выдана в Индии, вы всё равно не ограничены в использовании кода (ничего не могу сказать про Украину, Россию и Белоруссию, у нас всё очень зыбко).
Права дарованы безвозмездно
Плата за пользование ни в коем случае не взимается.
Права не эксклюзивны
Вы можете использовать работу, как и любой другой.
Права неотъемлемы
Никто не может отобрать у вас права. Другими словами, вам не стоит беспокоится о том, что однажды, создав некий потрясающий код, кто-то скажет вам: “Извини, но ты больше не можешь его видеть”.
У распространения кода также есть специальные требования, в основном они касаются упоминания имён разработчиков.
Creative Commons
Лицензия Creative Commons (CC) не совсем open-source лицензия, так как она обычно используется в мультимедиа и дизайн-проектах. Существует широкое множество CC-лицензий и каждая из них даёт определённые права. У CC есть 4 основных положения, которые могут быть использованы по одиночке или в комбинации друг с другом. Вот они:
Атрибуция (указание авторства) – BY
Эта лицензия позволяет другим распространять, перерабатывать, исправлять и развивать произведение, даже в коммерческих целях, при условии указания автора произведения. Это наиболее свободная лицензия, с точки зрения того, что могут делать с произведением пользователи.
Копилефт – SA
Эта лицензия позволяет другим модифицировать, исправлять и развивать произведение даже в коммерческих целях при условии указания авторства и лицензирования производных работ на аналогичных условиях.
Некоммерческое использование – NC
Работа может модифицироваться, распространятся и т.д., но только для некоммерческих нужд. Понятия “коммерческий” и “некоммерческий” немного расплывчаты. Например, некоторые могут интерпретировать “некоммерческий” как синоним фразы “не для продажи”. Другие могут могут предположить, что они не имеют права на использование даже там, где просто есть реклама. В общем, “коммерческий” означает какую-либо материальную выгоду.
Без производных – ND
Это значит, что вы можете копировать и распространять лицензированную работу, но не имеете права модифицировать её или создавать собственные работы на основе оригинала.
Как уже было сказано, эти составляющие можно комбинировать. Наиболее жёсткая лицензия — “С указанием авторства – Некоммерческая – Без производных” (BY-NC-ND). Это наиболее хороший вариант для того, чтобы освободить свою работу, но сохранить над ней контроль. А наименее жёсткая лицензия — “С указание авторства” (BY) означает, что люди могут использовать вашу работу до тех пор, пока указывают ваше авторство.
Лицензии CC разработаны для дизайнерской работы, а не для разработки ПО, но ничто не мешает использовать её в обеих случаях. Просто внимательно пройдитесь по всем пунктам и выберите то, что вам по душе.
Вот шесть наиболее часто используемых лицензий мира open-source. На самом деле их намного больше, некоторые источники уверяют, что около 60-ти. Многие практически дублируют друг друга с некоторыми небольшими оговорками, что создаёт сложности в их выборе и использовании. Open Source Initiative работает над тем, чтобы сократить их количество до приемлемого. Я же считаю, что на все случаи жизни хватило бы и четырёх: GPL, LGPL, BSD и CC. Рекомендую вам более подробно ознакомиться с каждой из них, а если вы заинтересовались использовать эти лицензии в своём бизнесе, как это делают IBM, Google и сотни других крупных компаний, обязательно проконсультируйтесь со своим юристом. В постсоветских странах, насколько мне известно, нет никакой правовой защиты open-source лицензий, по крайней мере не было ни одного судебного прецедента. С другой стороны, юристы OSI (Open Source Initiative) гарантируют защиту ваших прав по каждой из указанных лицензий.
Поправка от tarzanasg:
«Некоммерческое использование – NC» и «Без производных – ND» к open source не относятся. Применение этих условий делает лицензию и тексты с медиафайлами собственническими.
Пять заблуждений об открытом ПО
Программное обеспечение с открытым кодом имеет своих почитателей, а в последнее время если речь заходит о разработке каких-то «национальных» продуктов, так в основном open-source и подразумевают. Парадоксально, но интерес к этому виду программного обеспечения породил массу искажений и заблуждений, которые на практике мешают его распространению.
Наша компания участвует в открытых проектах с 2005 года – и благодаря разработке собственных open source решений (проекты OpenVZ, CRIU), участвуя в других открытых проектах (QEMU, OpenStack, libvirt, libcontainer, и т.д.). За 10 лет мы собрали несколько наиболее распространённых мифов об открытом программном обеспечении. Я расскажу про каждое из заблуждений и объясню, почему оно ошибочно. Наверняка, вы вспомните еще столько же, но, на мой взгляд, эти пять самые «адовые».
Проект с открытым исходным кодом это открытый проект.
Любой программный проект состоит из множества артефактов: исходный код проекта, информация о неисправленных дефектах, исходный код тестов, документация. Исходный код проекта — это только его часть, свободный доступ к которой не даёт права называть весь проект открытым. Помимо исходного кода, свободный доступ должен быть открыт и к другим артефактам разработки, и чем больше артефактов открыто, тем больше проект открыт для контрибьюторов (людей, которые захотят сделать вклад в проект). Помимо этого, необходимы прозрачные процессы между всеми участниками сообщества, открытые коммуникации в проекте и т.д. Все эти меры будут только способствовать развитию проекта и плодотворному сотрудничеству участников сообщества.
Oracle VirtualBox — это пример закрытого проекта с открытым исходным кодом. Код полностью доступен, но процесс разработки закрыт и непрозрачен.
Продукты на основе открытых проектов содержат только открытый исходный код
Компании, которые разрабатывают коммерческие решения на базе открытых проектов, могут включать закрытые компоненты в свои продукты. Потому что именно дополнительная закрытая функциональность может дать им конкурентное преимущество среди компаний, которые также строят бизнес на основе этого открытого проекта. Именно закрытые компоненты зачастую формируют продукт, который компания может продавать своим клиентам и зарабатывать на нём деньги.
Например, недавно мы объявили о разработке следующей версии Virtuozzo, дистрибутив которой будет распространяться бесплатно. Пользователь получит возможность использовать виртуальные машины и последнюю версию наших контейнеров свободно и без ограничений, но при желании он сможет установить набор дополнений (распределенное хранилище данных, компонент для увеличения плотности контейнеров на одном физическом сервере и другие), которые помогут ему успешнее решать его задачи. В этом часть свободы открытого ПО. Вы сами выбираете тот вариант, который вам больше подходит: использовать базовую версию или расширенную. В нашей практике есть примеры компаний-клиентов, которые предоставляли услуги на основе технологий OpenVZ, но позднее оценили преимущества коммерческой версии, и с тех пор стали нашими платными клиентами. Это стратегия win-win, в которой выигрывают обе стороны.
Использование открытого ПО полностью бесплатно
Существует расхожее мнение о том, что свободный софт является в то же время и полностью бесплатным. Однако цена самого ПО — лишь малая часть расходов, связанных с его использованием. Свободное ПО – не исключение, поэтому перед его использованием необходимо оценивать весь его жизненный цикл. Только так можно сделать вывод о том, будет внедрение открытого ПО выгодным или нет.
Разберём это на примерах:
Во всех примерах не было покупки права использования программы (лицензии), что на самом деле происходит во время приобретения коммерческого ПО. Но каждый раз возникала другая стоимость, к примеру, стоимость услуг или стоимость собственного бизнеса плюс экономия средств за счет свободного права использования.
Одно из достоинств Open Source — предельные затраты, по существу, отсутствуют, так как здесь, как правило, не требуется дополнительных лицензий по мере того, как расширяется внедрение.
Нельзя построить бизнес на открытых решениях из-за отсутствия технической поддержки
Поддержка — это ключевой момент для пользователей. Рядовой пользователь вполне может обойтись без нее при использовании открытого ПО, как мы это объяснили в примерах выше, но компаниям техническое сопровождение в большинстве случаев необходимо.
Серьёзные открытые проекты либо активно поддерживаются сообществом разработчиков, либо существуют компании, которые на коммерческой основе могут обеспечить поддержку для крупного бизнеса. А при необходимости — и добавить в продукт нужную функциональность.
Именно такой модели мы придерживаемся в проекте OpenVZ. Компоненты проекта распространяются свободно, но если вам нужна поддержка или разработка дополнительной функциональности, то мы можем её обеспечить.
Качество открытого ПО хуже, потому что код для него может писать любой желающий
Главный принцип открытого ПО – открытая совместная разработка – сам по себе является залогом того, что некачественный код, костыли и заплатки попросту невозможно будет скрыть от других участников. Человек, участвуя в такого рода проектах, готов к тому, что его работа будет подвергнута и анализу, и критике, а, значит, халтурить не будет. На кону его репутация, а её терять никто не хочет.
Кроме того, в некоторых сообществах (например, сообщество вокруг разработки Linux-ядра) существует и жесткий принцип – в исходное ядро принимается только самый лучший, оттестированный и идеальный код. Попытку добавить некачественные изменения отклонят, вторая попытка чревата потерей репутации для человека или компании-контрибьютора.
То есть открытый проект действительно даёт возможность любому человеку принять участие в написании кода, но в серьёзных проектах из-за высокого порога вхождения код не будет принят от людей с недостаточным уровнем экспертизы.
В большинстве крупных ИТ-компаний (IBM, Google, Canonical, Parallels и т.д.) есть целые департаменты, в которых специалисты получают зарплату за то, что работают над проектами с открытым исходным кодом и таким образом косвенно работают над продуктами компании.
Отдельно стоит упомянуть, что компании, которые разрабатывают продукты на базе открытых проектов, в ходе тестирования заинтересованы в улучшении кода открытых проектов, которые они используют. Поэтому все обнаруженные проблемы необходимо исправлять и добиваться, чтобы это исправление было добавлено в основную ветку проекта, чтобы иметь как можно меньше отличий в своём коде и коде открытого проекта. Наши продукты используют код других открытых проектов, поэтому проблемы, найденные в коде этих проектов, мы исправляем и отправляем в upstream. Так было с уязвимостями в ядре RHEL: Red Hat отметил Владимира Давыдова за обнаружение серьезных уязвимостей CVE-2014-0203 и CVE-2014-4483 в одном из обновлений ядра RHEL6 (вторая проблема, кстати, была найдена с помощью одного из наших автоматических тестов, использующих Linux Test Project). Василий Аверин получил благодарность за обнаружение ошибки CVE-2014-5045, Дмитрий Монахов – за CVE-2012-4508. Факт хорошего тестирования Linux-ядра был даже отмечен Эндрю Мортоном (кто это?): “Мне интересно. За последние несколько месяцев люди из @openvz.org нашли (и исправили) кучу непонятных, но серьезных и довольно древних багов. Как вы обнаружили эти баги?”
На самом деле все перечисленные мифы возникают по большей части у пользователей, которые либо только начинают работать с OpenSource ПО, либо не пробовали этого делать вообще. Лучший способ избавиться от предубеждений – начать вплотную работать с такими решениями.
Мы недавно анонсировали открытый процесс разработки новой версии нашего продукта Virtuozzo 7. Если вы также заинтересованы в создании лучшей технологии контейнерной виртуализации, то присоединяйтесь.