0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как лицензировать свою программу

Как лицензировать свою программу

За более подробными сведениями обращайтесь к списку вопросов о наших лицензиях.

Если вы обдумываете применение Меньшей стандартной общественной лицензии GNU, прочтите, пожалуйста, сначала статью “Почему вам не следует применять LGPL для своей следующей библиотеки”. В статье объясняется, почему вместо этого может оказаться лучше применять обычную GPL и как мы принимали бы решение об этом.

Вот краткая сводка того, что вам нужно сделать, чтобы выпустить программу под одной из наших лицензий:

  • Получить отказ от авторских прав у своего работодателя или учебного заведения.
  • Присоединить к каждому файлу соответствующие уведомления об авторских правах. Не забывайте ясно указывать, какие версии лицензии могут применять пользователи.
  • Добавить файл COPYING с копией GNU GPL или GNU AGPL.
  • Добавить также файл COPYING.LESSER с копией GNU LGPL, если вы применяете ее.
  • Поместить в каждый файл уведомление о лицензии.
  • (По желанию) сделать так, чтобы программа отображала уведомление в начале работы.
  • (Если применяется AGPL) сделать так, чтобы программа предлагала копии своего исходного текста.

Процедура включает в себя добавление двух элементов в каждый файл исходного текста вашей программы: замечание об авторских правах (например, “Copyright 1999 Терри Джонс”) и заявление о разрешении копирования, в котором сказано, что программа распространяется на условиях Стандартной общественной лицензии GNU (или Меньшей GPL, или GPL Афферо).

Отказ от авторских прав

Если вы частное лицо и работаете по найму или учитесь в школе, благоразумно попросить своего работодателя или учебное заведение подписать отказ от авторских прав на вашу программу, чтобы впоследствии они не могли заявить, что авторские права принадлежат им и что вы вообще были не вправе выпускать программу. На самом деле это никак не связано с GNU GPL — это относится к любой лицензии свободных программ, какую бы вы ни применили для выпуска программы.

Вот пример отказа от авторских прав; поменяйте имена, название и описание программы соответствующим образом:

Данной справкой ЗАО “Чудо-Юдо” отказывается от всех претензий на авторские права на программу “Дятел” (которая деконструирует деревья), написанной Яковом Хакером.

подпись Кощея Бессмертного, 1 апреля 1989 года
Кощей Бессмертный, губернатор Тридевятого царства

Если вы студент университета, мы рекомендуем вам запросить отказ на как можно более ранней стадии написания программы, чтобы снизить сопротивление. Если вы не научный сотрудник и не преподаватель, не исключено, что университет не может предъявить авторские права на вашу работу, но это нужно уточнить у юриста.

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

Замечание об авторских правах

В замечание об авторском праве должен входить год, в который вы завершили подготовку выпуска (так что если вы завершили ее в 1998 году, но не выпускали до 1999 года, пишите “1998”). Вам следует добавлять соответствующий год для каждого выпуска; например, “Copyright 1998, 1999 Терри Джонс”, если некоторые выпуски были закончены в 1998 году, а другие — в 1999. Если несколько людей помогало писать программу, вписывайте все их имена.

Для программ с несколькими выпусками в течение многих лет допустимо писать диапазон (“2008—2010”) вместо перечисления отдельных лет (“2008, 2009, 2010”) тогда и только тогда, когда каждый год в диапазоне (включительно) в действительности является значимым с точки зрения авторского права и был бы перечислен отдельно; и когда вы заявляете об этом в явном виде в своей документации.

Всегда пользуйтесь английским словом “Copyright”; по международным соглашениям оно применяется во всем мире, даже для материалов на других языках. Знак авторского права “©” можно включать по вашему желанию (в том случае, если ваш набор символов поддерживает его), но это не обязательно. Применение трехсимвольной последовательности “(C)” не имеет значения с точки зрения закона, но это не повредит.

Если вы скопировали текст из других программ под той же самой лицензией, скопируйте из них также замечания об авторских правах. Размещайте все замечания об авторских правах на файл вместе, прямо около начала файла.

Файлы лицензий

Вам следует также поместить копию самой лицензии куда-нибудь в дистрибутив программы. Все программы, независимо от того, выпущены они под GPL или LGPL, должны включать в себя текстовую версию GPL. В программах GNU принято располагать лицензию в файле под названием COPYING.

Если вы выпускаете свою программу по GNU AGPL, используйте текстовую версию GNU AGPL вместо GNU GPL.

Если вы выпускаете свою программу по Меньшей GPL, вам следует добавить также текстовую версию LGPL, обычно в файле под названием COPYING.LESSER. Обратите внимание, что поскольку LGPL является набором дополнительных к GPL разрешений, то крайне важно помещать обе лицензии, чтобы у пользователей были все материалы, необходимые им для понимания своих прав.

Уведомления о лицензии

Объявление о разрешении копирования для каждого файла (называемое также уведомлением о лицензии) должно идти прямо после заявлений об авторских правах на него. Для программы, состоящей из одного файла, это объявление (для программ, выпущенных под “GPL версии 3 и более поздней”) должно выглядеть так:

Для программ, состоящих более, чем из одного файла, лучше заменить слова “эта программа” на название программы и начать объявление со строки, в которой сказано: “Этот файл — часть НАЗВАНИЕ”. Например,

Чтобы применить другой набор версий GPL, измените конец первого большого абзаца. Например, если программа под GPL версии 2 или более поздней, замените “3” на “2”.

Это объявление должно находиться вблизи начала каждого исходного файла, рядом с замечаниями об авторских правах. Когда используется Меньшая GPL, вставьте слово “Меньшая” перед словом “Стандартная” во всех трех местах. Когда используется GNU AGPL, вставьте слово “Афферо” перед словом “Стандартная” во всех трех местах.

Для чего нужны уведомления о лицензии?

Задача лицензии свободных программ — предоставить всем пользователям программы определенные права. Если неясно, какие права вы им предоставили, то задача остается не выполнена. Наши методы составлены так, чтобы избегать всякой неопределенности.

Если у программы вместе с исходными файлами есть копия лицензии Л, но нет явного заявления, что “Эта программа выпущена по лицензии Л“, это оставляет возможность неопределенности того, распространяется ли лицензия Л на тексты этой программы.

Если в выпуске есть одно утверждение, что “Эта программа выпущена по лицензии Л”, в центральном месте, таком как файл README, это делает ситуацию ясной для этого выпуска. Однако программисты часто копируют исходные файлы из одной свободной программы в другую. Если исходный файл не содержит заявления о том, какая у него лицензия, то перемещение его в другой контекст устраняет все следы лицензии. Это приводит к путанице и заблуждениям.

Уведомление при запуске

Для интерактивных программ обычно неплохо сделать так, чтобы программа показывала краткое замечание об авторских правах и разрешении копирования, когда она запускается. Подробнее об этом см. в конце GNU GPL.

Уведомление Афферо

Если вы выпускаете свою программу по GNU AGPL и она может взаимодействовать с пользователями по сети, программа должна предлагать этим пользователям свой исходный текст тем или иным образом. Например, если ваша программа является приложением для Интернета, то она могла бы показывать ссылку “исходный текст”, которая приводила бы пользователей к архиву исходного текста. GNU AGPL достаточно гибка, чтобы вы могли выбрать метод, подходящий для вашей конкретной программы — подробности см. в разделе 13.

Прочее

По практическим причинам очень важно указывать контактную информацию, по которой с вами можно было бы связаться, например, в файле README, но это не имеет никакого отношения к юридическим аспектам применения лицензии.

По закону регистрировать ваши авторские права у кого бы то ни было не обязательно; авторские права действуют уже тогда, когда программа просто пишется. Однако для США неплохо зарегистрировать авторские права в Бюро авторских прав США, потому что это ставит вас в более сильное положение по отношению к любому нарушителю лицензии в США. В большинстве других стран системы регистрации авторских прав нет.

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

Можно также сделать вашу программу пакетом GNU, частью проекта GNU. Если вы заинтересованы в присоединении таким образом к проекту GNU, обратитесь, пожалуйста, к нашей странице оценки программ GNU за дополнительными сведениями и краткой анкетой. Мы ответим и обсудим это с вами.

Вы вполне можете применять любые наши лицензии, даже если ваша программа не является пакетом GNU; на самом деле мы надеемся, что вы будете делать это. Они доступны для всех. Если вы хотели бы показать всем, что вы применяете определенную лицензию, смело пользуйтесь нашими значками.

Ru:Перед лицензированием

Более актуальная версия на английском языке: Considerations for licensors and licensees.

В этом списке приводятся основные вещи, над которыми вы должны подумать, прежде чем вы примените лицензию Creative Commons к вашему произведению. Это не исчерпывающий перечень. Если возникнут дополнительные вопросы или проблемы, не стесняйтесь написать в один из наших дискуссионных списков рассылок, отправить нам сообщение электронной почты на адрес info@creativecommons.org или отправить сообщение электронной почты одному из наших руководителей проектов в вашей стране или же самостоятельно найти юридический совет.

Contents

  • 1 Убедитесь, что ваше произведение является объектом авторских прав
  • 2 Убедитесь, что вы обладаете правами
  • 3 Убедитесь, что вы понимаете каким образом работают лицензии Creative Commons
  • 4 Будьте точны в отношении того, что вы лицензируете
  • 5 Вы член коллективного общества управления авторскими правами? Если да, то позволяет ли оно оно применять CC-лицензии к вашим произведениям?

Убедитесь, что ваше произведение является объектом авторских прав

Лицензии Creative Commons применяются к произведениям, охраняемым авторским правом. Авторское право защищает творческое выражение. Как правило, произведениями, находящимися по защитой авторского права являются: книги, скрипты, веб-сайты, планы уроков, блоги и любые другие формы письменных трудов; фотографии и другие визуальные изображения; фильмы, видеоигры и другие визуальные материалы; музыкальные произведения, звукозаписи и другие аудиопроизведения.

Авторское право не защищает факты или идеи, лежащие в основе творческого выражения. Таким образом, лицензии Creative Commons не применяются к идеям, фактической информации и другим нетворческим элементам, которые не защищены авторским правом. Если вы находитесь в США, вы можете узнать больше о том, что является и а что не способно быть под охраной авторских прав на этом сайте. Если Вы находитесь в Великобритании, посетите этот сайт. Если вы находитесь на Тайване, соответствующие положения — это Статьи 9 and 10bis. Другие страны могут также применять разные правила и вы должны проверить их перед приминением лицензии Creative Commons к вашим произведениям.

Если вы находитесь на Украине, посетите эту страницу.

Если вы находитесь в Белоруссии, посетите эту страницу.

Если вы находитесь в Казахстане, посетите эту страницу.

Если вы находитесь в Латвии, посетите эту страницу.

Если вы находитесь в Эстонии, посетите эту страницу.

Если вы находитесь в Литве, посетите эту страницу.

Если вы находитесь в Молдавии, посетите эту страницу.

Если вы находитесь в Грузии, посетите эту страницу.

Если вы находитесь в Армении, посетите эту страницу.

Если вы находитесь в Азербайджане, посетите эту страницу.

Если вы находитесь в Киргизии, посетите эту страницу.

Если вы находитесь в Таджикистане, посетите эту страницу.

Если вы находитесь в Узбекистане, посетите эту страницу.

Если вы находитесь в Туркмении, посетите эту страницу.

Если вы находитесь в Израиле, посетите эту страницу.

Убедитесь, что вы обладаете правами

Перед применением лицензии Creative Commons к произведению вам нужно убедиться в том, что вы имеете на это полномочия. Это означает, что вам нужно убедиться, что лицо, которое владеет авторским правом на произведение, желает, чтобы это произведение было доступно по лицензии Creative Commons.

Если вы создатель произведения, то вы скорее всего являетесь владельцем авторского права и, таким образом, можете лицензировать произведение как пожелаете. Если вы сделали произведение в рамках вашего трудового контракта (служебное произведение), то ваш работодатель может владеть правами на произведение, в этом случае только ваш работодатель может принять решение о применении лицензии Creative Commons. Если Вы сделали произведение по договору (договору авторского заказа, подрядному договору, договору на выполнение НИОКР, а также госудаственному или муниципальному контракту), вы должны проверить условия договора, чтобы убедиться, что права на произведение не были переданы кому-то другому и вы обладаете исключительными правами.

Если вы объединяете уже существующие произведения, сделанные другими людьми (кроме случаев когда произведения находятся в общественном достоянии и тем самым разрешение не требуется) или создаете произведение в сотрудничестве с другими людьми, вам необходимо убедиться, что у вас есть определённое и недвусмысленное разрешение применить лицензию Creative Commons к конечному результату (за исключением вашего использования уже созданных произведений содержащих материалы на условиях добросовестного использования и, таким образом, разрешения не требуется). Вы не владеете авторскими правами в случае покупки, например, компакт-диска с песнями в исполнении Мадонны или романа Итало Кальвино и, следовательно, не можете применить лицензию Creative Commons к этим объектам. Вы можете получить точное разрешение, если вы находитесь в непосредственном контакте с владельцем авторского права, можете обсудить лицензирование Creative Commons с ними и они согласны на условия конкретной лицензии. Конечно, если вы объединяете произведение уже распространяющееся по Creative Commons, вы будете также иметь права, предоставленные вам согласно условиям этой лицензии!

Убедитесь, что вы понимаете каким образом работают лицензии Creative Commons

Перед применением вами лицензией Creative Commons к вашему произведению вы должны быть уверены, что вы понимаете, как они работают. Вы можете это делать путем изучения часто задаваемых вопросов и/или задать интересующие вас вопросы и высказать свои замечания в наших почтовых рассылках. Ниже приводится обзор некоторых ключевых элементов модели лицензирования Creative Commons.

Каким образом работает лицензия Creative Commons?

Лицензия Creative Commons базируются на авторском праве. Таким образом, они применяются для всех произведений, которые охраняются авторским правом. Разновидностями произведений, охраняемых законом об авторском праве являются книги, веб-сайты, блоги, фотографии, фильмы, видео, песни и другие аудио и видео записи. Программное обеспечение также охраняется авторским правом, но, как объяснено в часто задаваемых вопросах, мы не рекомендуем применять лицензию Creative Commons к программе.

Лицензии Creative Commons дают вам возможность давать чёткое разрешение другим использовать ваши защищённые авторским правом произведения-такое как право других копировать ваше произведение, делать производные произведения или адаптации вашего произведения, распространять ваше произведение и/или делать деньги на вашем произведении. Они не дают вам возможность ограничивать что-нибудь, что разрешено исключениями и ограничениями авторского права-включая, главным образом, добросовестное использование или честное поведение-и они не дают вам возможность что-либо, что не защищается законом об авторском праве, такое как факты и идеи.

Лицензии Creative Commons прикладываются к произведению и уполномачивает каждого, кто наткнулся на них в связи с произведением, использовать его согласно лицензии. Это значит, что если Боб имеет копию вашего произведения по Creative Commons, Боб может дать копию Кэрол и Кэрол будет уполномочен использовать произведение согласно лицензии Creative Commons. Вы таким образом имеете лицензионный договор отдельно с Бобом и отдельно с Кэрол.

Лицензии Creative Commons выражены в трех различных форматах: «общее (краткое) описание»/Commons Deed (текст понятный простому человеку), «юридический текст»/Legal Code (текст понятный юристу) и метаданные (текст понятный машине). Вам не нужно ничего подписывать, чтобы получить лицензию Creative Commons — просто выберите вашу лицензию на странице Лицензирования.

Наконец, необходимо понимать о лицензиях Creative Commons это то, что они все являются неисключительными лицензиями. Это значит, что вы можете разрешить широкой общественности пользоваться вашим произведением на условиях лицензий Creative Commons, а затем заключать отдельные и другие неисключительные лицензии с кем-нибудь ещё, например, в обмен на деньги.

Что делать, если я изменил свое решение?

Это крайне важный момент, требующий особого рассмотрения. Лицензии Creative Commons являются неотзывными лицензиями. Это означает, что вы не можете остановить кого-нибудь, кто уже получил ваше произведение по лицензии Creative Commons, от использования вашего произведения в соответствии с этой лицензией. Вы можете в любой момент, который вы пожелаете, перестать распространять ваше произведение по лицензии Creative Commons, но это никак не повлияет на права, связанные с любыми копиями вашего произведения уже распространёнными по лицензии Creative Commons. Так что вам необходимо тщательно всё обдумать при выборе лицензии Creative Commons и убедиться, что вы будете рады дать людям возможность использовать ваше произведение согласно условиям лицензии, даже если вы затем остановите распространение вашего произведения.

И большинство педагогов, которые разместили свои образовательные ресурсы в сети сделали это с идеей, что они будут широко распространяться. Но если от вашего контроля авторских прав зависят ваши средства к существованию, вы должны тщательно подумать, прежде чем раздавать коммерческие права на ваши творческие работы. Например, многие музыканты обнаружили, что, распространять произведение для некоммерческого использования может быть весьма полезным. Но всё, что выходит за эти рамки, требует очень тщательного рассмотрения. Мы ценим душевную щедрость. Но если вы хотите быть щедрыми, мы хотим, чтобы вы тщательно подумайте об этом, прежде чем что-либо предпринимать.

Будьте точны в отношении того, что вы лицензируете

Вы должны быть точны в отношении того, какие именно из условий CC-лицензий вы хотите использовать, применяя лицензию Creative Commons к вашему произведению. Мы предоставляем возможность выбора формата вашего произведения в метаданных лицензии (текстовый, аудио, видео, графический, интерактивный форматы) и вы должны использовать её. Это позволит создать более точный машиночитаемый код вашей лицензии.

Также вам следует задуматься над тем, какие именно элементы вашего произведения хотите лицензировать. Например, в случае с веб-сайтом вы хотите лицензировать только текст и изображения? Или также таблицы стилей и код, на котором работает ваш сайт? Также, если вы собиратесь сделать доступной на вашем сайте под CC-лицензиями музыку, собираетесь ли вы применить лицензии Creative Commons не только к музыкальным композициям и аудиозаписям, но и к остальным произведениям искусства и графике на вашем сайте? И напоминаем, как объяснено выше в разделе «2. Убедитесь, что вы обладаете правами», вам необходимо быть уверенным, что вы имеете права на каждый элемент, который вы лицензируете по лицензии Creative Commons.

Уделите всего несколько минут на то, чтобы внимательно разобраться с тем, что вы намерены лицензировать, а затем определить рамки ваших метаданных и правовых условий, составив точное уведомление, например такое: «Все изображения на этом сайте лицензированы по лицензии Creative Commons [добавить описание типа лицензии] 2.5».

Вы член коллективного общества управления авторскими правами? Если да, то позволяет ли оно оно применять CC-лицензии к вашим произведениям?

Вам необходимо обратиться к вашему обществу. В настоящее время множество обществ управления авторскими правами в Австралии, Финляндии, Франции, Германии, Люксембурге, Испании, Тайване и Нидерландах получают поручения на осуществление прав (или что во Франции называется “мандат” прав, что тем не менее имеет такой же правктический эффект как поручение) от вас на существующие или будущие произведения (таким образом, что они по сути становятся владельцами этих прав) и управляют ими от вашего имени. Если вы уже являетсь членом такого общества в одной из этих юрисдикций, у вас может не быть права лицензировать ваше произведение по лицензии Creative Commons, поскольку необходимыми правами владеете не вы, а общество управления авторскими правами. Пожалуйста прочитайте часто задаваемые вопросы и ответы на веб-сайте команды Creative Commons в вашей юрисдикции для получения более подробной информации об этой проблеме в вашей юрисдикции.

Creative Commons взаимодействует с обществами коллективного управления авторскими правами в указанных странах, где имеется данная проблема, с целью попытаться найти решение, которое позволит создателям контента пользоваться преимуществами обеих предлагаемых систем.

Если у вас возникли проблемы с лицензиями Creative Commons из-за вашего членства в обществе коллективного управления авторскими правами в вашей стране, и эта страна не перечислена выше, пожалуйста сообщите об этом команде проекта Creative Commons в вашей стране или отправьте письмо на следующий адрес: mailto:info@creativecommons.org. Если вы хотите обсудить пути разрешения такой ситуации, также свяжитесь с командой проекта Creative Commons в вашей стране.

Если вы уже являетесь участником одного их таких обществ, не стесняйтесь требовать от вашего общества, чтобы оно дало вам возможность пользоваться лицензиями Creative Commons.

Зачем лицензировать программное обеспечение или «а оно мне надо?»

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

Однако все это касается только материальных ценностей — всего того, что можно пощупать руками. Но, кроме материальных ценностей, есть еще и ценности интеллектуальные (например, программное обеспечение). И очень часто существует мнение, что я ничего никому не должен, ведь я не украл «напрямую» у разработчиков. Давайте разбираться, зачем нужно ПО, его легализация и лицензирование?

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

  • банальная бессознательность, незнание того, как грубо нарушается закон в их случае;
  • жадность — зачем платить, если все итак можно получить бесплатно;
  • лень — нежелание разбираться в вопросе софта и уверенность, что судебные разбирательства обойдут стороной.

Что мы имеем в итоге, при использовании пиратского ПО:

  • «Человек и закон» (чтобы организации попасть под статью Уголовного кодекса России – «Нарушение авторского и смежных прав», достаточно, чтобы на рабочих компьютерах было установлено программного обеспечения суммарной стоимостью свыше 50 тыс. руб.)
  • Компьютерная эпидемия (для рядовых пользователей гораздо большую опасность представляют «сюрпризы», которые неизвестные «благодетели», взламывающие программы и системы, встраивают в них перед распространением)
  • Проблемы совместимости программного обеспечения (нелицензионные копии ПО могут стать причиной несовместимости программ, которые в обычных условиях хорошо взаимодействуют друг с другом)
  • Отсутствие прав на техническую поддержку и обновление продуктов (производитель программного обеспечения не предоставляет технической поддержки нелицензионных копий продуктов. При возникновении технической проблемы, «тормозящей» работу, компании придется самостоятельно заниматься ее разрешением)
Право выбора
Что такое лицензирование?
Легализация программного обеспечения

Правильно проведенная легализация ПО позволяет сэкономить предприятию значительные деньги, а чтобы этого достичь требуется квалифицированный подход с использованием знаний опытных специалистов в области лицензирования ПО.

Процесс легализации
Итог легализации ПО

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

Проблемы снижающие эффект от легализации:

  • Использование нелегального ПО сотрудниками без санкции руководства. Есть стратегия использования легального ПО в компании, но она неизвестна сотрудникам или попросту игнорируется;
  • Каждый факт покупки дополнительного лицензионного ПО оборачивается для компании непрогнозируемыми расходами;
  • Лицензии приобретены законным путем, но при проверке не удается найти подтверждение их легальности (отсутствуют лицензионные соглашения, документы поставщиков и т.п.).
Что делать в сложившейся ситуации?
Решать вам

Между прочим, легализация не такой уж дорогой процесс, как многие думают, не верите, тогда давайте посчитаем вместе!

Цена вопроса
Что стоит за нелегальным ПО или набор рисков в «подарок»

Для начала — четко обозначим как минимум первичный набор этих рисков:

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

Конечно, в каждой конкретной компании список рисков будет выглядеть несколько иначе, но это, так называемый, «стандартный набор».

Шкала оценок

Высчитывая общий итог, надо перемножать полученные баллы по каждому риску. Так, если риск утечки информации вы оценили в 0 (не произойдет никогда — у вас отличная служба информационной безопасности), то итоговое значение «веса» риска при любой тяжести последствий составит 0 баллов. Но если риск изъятия компьютеров органами вы оцениваете хотя бы в 2 (возможно, произойдет), при значении ущерба в 5 серьезные последствия) общий вес риска составит 10 баллов из 25 возможных. Это очень серьезно.

Новые меры по помощи игровой индустрии от правительства России написаны в интересах Mail.Ru Group

Пакет мер, которые должны помочь российской игровой индустрии, вызывает вопросы по двум причинам. Первое — оригинального документа в публичном доступе нет. Имеющиеся формулировки — сложны и противоречивы. Второе — если в них покопаться, то главным и очевидным бенефициаром в них выглядит Mail.Ru Group.

Но обо всем по порядку.

Вчера стало известно, что министерство цифрового развития предлагает ввести 88 мер. Среди них:

  • 1) старт межправительственных переговоров для облегчения доступа российских разработчиков игр на китайский рынок;
  • 2) введение вычета НДС при лицензировании программного обеспечения (ПО) иностранными пользователями, в случае если ПО включено в реестр отечественного;
  • 3) создание российского магазина приложений для игр (для игр по зарубежной лицензии порог выплат правообладателям планируется повысить с 30% до 70%).

Первая мера вопросов не вызывает. Если российские власти смогут уговорить китайского «брата» дать отечественным играм приоритет перед западными тайтлами в выдаче ISBN, это действительно может помочь отечественным командам.

Однако формулировки двух оставшихся инициатив вызывают вопросы.

Мы попросили юридические компании прокомментировать эти пункты. Оба спикера дали ответ, но предупредили, что по имеющейся публикации сложно понять, что же имеется в виду. Более того, один из наших собеседников отметили, что в представленной информации точно есть какая-то путаница. Без оригинального документа с предложенными мерами возможность только делать предположения, что же Минцифры на деле предлагает.

Мера «Введение вычета НДС при лицензировании ПО иностранными пользователями»

Сейчас у меры странная формулировка. Есть несколько версий, как можно ее понять.

Согласно одной из них, министерство предлагает обнулить НДС с продажи цифрового контента и цифрового софта любой иностранной компанией российским пользователям. Однако у этого обнуления есть условие: иностранная компания должна лицензировать в России свою программу, внести ее в реестр отечественного. По крайней мере, так видит меру Алина Давлетшина, старший юрист VERSUS.legal. Она же говорит, что этой льготой вряд ли многие смогут воспользоваться:

«Дело в том, что одно из условий включения в реестр российского ПО – его доступность на территории всей России, а значит и на территории Крыма. А с этим условиям из-за санкционного режима российские приложения могут попасть под угрозу нарушения правил App Store, Google Play, Steam и прочих сторов, соблюдающих режим санкций. До этого у Apple, например, уже были прецеденты блокировки российских мобильных приложений, работающих в Крыму. А если отбросить лицензирование через американские маркетплейсы, как много приложений сможет воспользоваться этой льготой? Разве что те, кто присоединятся к российскому магазину приложений – его как раз тоже предлагает запустить Минцифра».

С подобной версией не согласен Роман Лукьянов, управляющий партнер Semenov&Pevzner:

«В реестр российского ПО не может попасть иностранная компания. Это в целом противоречит целям реестра российского ПО и телеологии налоговых льгот для российских разработчиков (цель — стимулирование и протекционизм)».

Лукьянов допускает, что при подготовке оригинального материала о мерах была допущена ошибка, поскольку «операции, связанные с лицензированием ПО и так не подлежат налогообложению НДС». Исходя из этого он делает вывод, что налоговый вычет по НДС должен относиться не к лицензированию ПО, а к чему-то еще.

«Скорее всего, речь идет о возможности принятия к вычету входящего НДС по услугам (каким именно – неизвестно). Исходя из целей представленного проекта мер, речь идет об услугах, которые предоставляются иностранным пользователям (видимо, речь идет про SaaS IT-решения, т.е. вычет, ориентированный на экспорт IT-решений; это не лицензирование с юридической точки зрения)».

Проще говоря, это может быть той самой мерой, о которой просили разработчики при введении «Налога на Google» в 2016 году. Напомним, налог тогда ввел по сути двойное налогообложение для российских игровых компаний. Дело в том, что сегодня отечественные команды продают свои игры через иностранные платформы (Steam, App Store, Google Play), а не напрямую. В итоге НДС с одной и той же покупки платится дважды: сначала его платит платформа в России, а потом разработчик, когда получает свои деньги на российское юридическое лицо.

Предложенная мера, возможно, позволит сделать налоговый вычет с услуг (к которым относится по российскому законодательству микроплатежи в играх — IAP), оказанных иностранным пользователям.

Мера «Магазин игр с порогом выплат правообладателям в 70%»

У этой меры хоть и менее противоречивая, но все-таки более сложная и трудная для понимания формулировка. Тем более, тут сразу смущает и наличие рядом слова «магазин» со словосочетанием «повысить с 30% до 70%», и понятие «порог выплат правообладателям».

Чтобы понять контекст, рассказал нам Роман Лукьянов, необходимо вспомнить об одном из обязательных требований к приложениям, если они хотят попасть в реестр российского ПО. Согласно ему, «общая сумма выплат по лицензионным договорам, предусматривающим предоставление прав на результаты интеллектуальной деятельности (…) в пользу иностранных лиц, контролируемых ими российских коммерческих организаций (…) должна составлять менее тридцати процентов от выручки правообладателя (…)».

Проще говоря, в реестр не могут попасть приложения с большими лицензионными отчислениями иностранным компаниям или лицам.

Исходя из этого, Лукьянов делает вывод, что, возможно, российский магазин игр не сможет удовлетворять этим требованиям. И, чтобы этого избежать, возможно, предлагается (только не понятно – для этого магазина предложений или вообще) повысить этот 30%-й порог до 70%.

«Если такую поправку примут, то правообладатели ПО смогут включить свое ПО в реестр, чтобы получить налоговые льготы, если выручка от лицензий иностранным лицам составит до 70% от общей выручки», — заключает Роман.

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

Согласно «Коммерсанту», предложения по игровой индустрии представлял вице-президент Mail.ru Group Владимир Габриелян. И, если мы в редакции правильно поняли трактовку этих предложений, они действительно в первую очередь отвечают интересам московской корпорации:

  • игровое подразделение Mail.Ru Group сейчас готовит к релизу свой магазин игр MY.GAMES Store (не о нем ли идет речь в документах?);
  • более 70% выручки MY.GAMES идет с иностранных рынков (она напрямую заинтересована в появлении налоговых вычетов);
  • у компании в портфеле начинают появляться игры по западным брендам (встает вопрос отчислений и возможного желания попасть с продуктом по западной лицензии в реестр отечественного ПО).

Появление игрового лоббиста — это замечательно. Но при этом хотелось бы, чтобы формулировки были бы яснее. О том, насколько корректно их передали наши коллеги из «Коммерсанта» мы, скорее всего, сможем понять уже на следующей неделе. Вице-премьер Дмитрий Чернышенко обязал Минцифры отдать в правительство пакет мер до 20 ноября.

Как я должен защищать авторские права и лицензировать свое свободное программное обеспечение?

Я совсем новичок в свободном программном обеспечении с открытым исходным кодом, но в любом случае я вхожу в него довольно хорошо (я думаю!!).

Теперь дело в том, что для распространения моей программы мне придется распространять свой исходный код, так что это будет (.gz) с установщиком наверняка или, может быть, (. deb).

Мои вопросы таковы:

(Я знаю, что это глупо, но я здесь новичок) Как я могу быть уверен, что никто не возьмет мой исходный код и не будет использовать его как свой, я имею в виду, что программа бесплатна, но нужно ли мне какое-то доказательство того, что эта вещь была написана мной?

Какую лицензию с открытым исходным кодом я должен поставить на программу? (учитывая, что я использую Debian, Ruby, Cron, Partimage, Qt4)

9 ответов

  • Как сделать программное обеспечение безопасным?

Возможный Дубликат : Защитить код .NET от обратного инжиниринга? Я хочу сделать свое программное обеспечение таким, чтобы оно не распространялось без покупки? Один из способов, как я думал, состоял в том, чтобы сделать веб-сервис, отслеживать и все такое. Но ограничение заключается в том, что не.

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

Существует множество различных лицензий с открытым исходным кодом, и многие из них имеют незначительные различия. Вам нужно решить, что важно для вас в том, как ваш код будет использоваться и распространяться другими.

В Википедии есть хорошее сравнение некоторых доступных лицензий .

Из этого списка вы также должны проверить страницу википедии на каждой лицензии для получения подробной информации об их специфике.

основные из них, на которые вам следует обратить внимание, — это GPL, LGPL, MIT, BSD, Apache и Mozilla.

Также стоит взглянуть на различные лицензии creative commons . Они предлагают несколько легко настраиваемых опций для создания подходящей вам лицензии.

Имейте в виду, что некоторые лицензии, такие как GPL, требуют, чтобы, если кто-то хочет работать с вашим кодом, они должны выпускаться под той же (или совместимой) лицензией. Это может наложить ограничения на использование вашего кода коммерческими компаниями или в программном обеспечении, поэтому некоторые люди предпочитают менее ограничительную лицензию. Это, конечно, полностью зависит от вас и от того, как вы хотели бы использовать свой код.

Ваши теги предполагают, что вы хотите распространять программное обеспечение ruby. Вы можете распространить его как gem через gemcutter .

И невозможно гарантировать, что никто не будет повторно использовать ваш код как свой собственный, поскольку не все соблюдают условия лицензий.

Как я могу быть уверен, что никто не возьмет мой исходный код и не будет использовать его как свой, я имею в виду, что программа бесплатна

Может быть, вы вообще не хотите открывать исходный код. Вы все равно можете сделать его доступным бесплатно даже без источника.

Если вы откроете его с открытым исходным кодом, нет никакого способа (и нет смысла) препятствовать другим людям использовать и изменять ваш исходный код, также делая его своим исходным кодом. Так что в то время это уже не будет «yours». По крайней мере, не исключительно.

  • Лицензия на свободное программное обеспечение для библиотек

Я разрабатываю библиотеку и хочу использовать лицензию на свободное программное обеспечение. Существуют тысячи лицензий, но я не понимаю их различий. Мне нужна помощь, чтобы выбрать лицензию. Мне нужна лицензия, которая: Позволяет статически или динамически связывать немодифицированную библиотеку.

Я работаю над программным обеспечением, которое хотел бы со временем продать. Прямо сейчас я вполне согласен поделиться им с людьми, которые заинтересованы в том, чтобы играть с ним и тестировать его, возможно, на веб-странице в качестве альфа-версии. Но я не хочу, чтобы люди украли мой код.

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

Линус Торвальдс пошутил, что настоящие мужчины не делают резервную копию, они просто загружают свои вещи и позволяют миру отражать их.

На практике более вероятно, что немногие люди будут использовать часть программного обеспечения, а не кто-то будет достаточно заботиться о том, чтобы выдать ее за свою собственную.

2) Вы должны использовать лицензию, соответствующую условиям лицензий на программное обеспечение, которое вы повторно используете. Вот почему GPL называется вирусным — если вы пишете программное обеспечение, которое напрямую ссылается на любую часть GPL программного обеспечения, вы должны использовать GPL для своего кода или получить освобождение от правообладателя.

Если у вас есть свободный выбор, я бы предложил использовать лицензию MIT, потому что это стандартная лицензия для кода Ruby. Она очень короткая и читабельная.

Выбранная вами лицензия в значительной степени зависит от лицензии используемых вами компонентов. Насколько я могу судить, partimage-это GPL, остальные, вероятно, MIT или BSD и LGPL. Вам необходимо использовать лицензию, совместимую со всеми вашими компонентами. Итак, если ваш проект (например) в основном является расширением partimage, вам придется пойти на GPL.

Если вы хотите пойти с «Debian spirit» вещей, GPL также будет естественным выбором.

1) — однако это невозможно. Таким образом, лежит DRM и тяжелый крипто-материал. Единственное, что вы можете сделать, — это получить лицензию и ожидать, что люди будут ее уважать. Или, конечно, обращаться в суд всякий раз, когда вы замечаете, что кто — то нарушает лицензию- дорого и раздражает.

Существует только один способ убедиться, что кто-то использует ваш исходный код как свой. Не публикуйте свой исходный код. Но, судя по тому, как вы написали свой вопрос, это не вариант для вас.

Лицензии

Будь аваре. Никакая лицензия на свободное программное обеспечение не запрещает любому человеку делать с вашим исходным кодом все, что он хочет, до тех пор, пока он его не опубликует.

Правильная лицензия для вашего проекта зависит от вашего намерения поделиться:

  • Если вы просто не хотите, чтобы ваше имя запоминалось в каждой производной, независимо от того, является ли производная бесплатной или правильной, используйте лицензию в стиле BSD. Но будьте внимательны. Даже microsoft будет разрешено включить ваш код в свою новую версию windows, не сообщая вам об этом. Существует несколько таких лицензий (BSD, MIT, MPL, . ). Список из них находится по адресу http://en.wikipedia.org/wiki/ BSD_licenses#BSD-style_licenses .
  • Если вы хотите убедиться, что все производные вашего программного обеспечения также бесплатны. Вы могли бы использовать GPL. GPL заставляет все производные также быть GPL.

Существует несколько вариантов GPL с различными ограничениями:

  • AGPL любая производная, использующая ваш код, должна быть опубликована под AGPL. Даже если производная доступна только в сети (например, если я изменяю ваш сервер http и он работает на моем сервере), она должна быть опубликована под AGPL.
  • GPL любая производная, использующая ваш код, должна быть опубликована под GPL или AGPL. Даже если они используют ваш код только в качестве библиотеки
  • LGPL любая производная, которая непосредственно использует ваш исходный код, должна быть опубликована под LGPL, GPL или AGPL. Если кто-то просто использует вашу библиотеку, не упаковывая ее в свой собственный проект, он может использовать любую лицензию, какую захочет.

Поэтому, если вы используете программное обеспечение GPL, а partimage-это программное обеспечение GPL, вы должны использовать GPL в качестве лицензии на свое программное обеспечение. Лично я предпочитаю AGPL.

Имейте в виду: GPL только говорит, что вы должны дать исходный код тем, кому вы дали программу. Поэтому, если кто-то продает свою производную, он должен только дать вам исходный код, если вы купите программу.

Вы можете использовать MyFreeCopyright , чтобы показать, что вы защищаете его авторским правом. Наверное, это самый простой способ.

Какая лицензия вам нужна, зависит от того, что вы позволяете другим делать с ней.

  • GPL — общее назначение, держите его свободным, только для сообщества с открытым исходным кодом
  • LGPL — может использоваться в коммерческих приложениях, если какие-либо улучшения в приложении/библиотеке также бесплатны
  • MIT — бесплатно для всех целей, если лицензия сохранена в целости и сохранности
  • Авторское лево — делайте с ним все, что хотите
  • Creative Commons — несколько вариантов, более простых для понимания

Лицензирование деятельности

Основной нормативно-правовой документ, который регламентирует лицензирование — это Федеральный закон «О лицензировании отдельных видов деятельности» № 99-ФЗ от 04 мая 2011 года. Также особенности лицензирования каждого вида деятельности устанавливаются положениями, утвержденными Правительством РФ.

Получение лицензии на осуществление лицензируемой деятельности — это требование законодательства, поэтому вопрос «зачем нужно лицензирование» не стоит, т.к. без получения лицензии государство не позволит предприятию заниматься бизнесом.

Давайте разберемся, в каком случае и как получить лицензию.

Новым ИП — год Эльбы в подарок

Год онлайн-бухгалтерии на тарифе Премиум для ИП младше 3 месяцев

Когда лицензия нужна

Перечень видов деятельности, на которые требуются лицензии, строго определен в п.1 ст. 12 99-ФЗ. Если деятельности в списке нет, значит на её осуществление разрешение не требуется.

На каждый вид деятельности предоставляется отдельная лицензия. которая действует на всей территории РФ. Только нужно уведомить лицензирующий орган, того региона, куда вы планируете расширяться.

Документы для получения лицензии необходимо подать сразу же после государственной регистрации. Или перед началом ведения лицензируемой деятельности.

Требования, которым должна соответствовать организация, чтобы получить лицензию и осуществлять деятельность, устанавливаются положением о лицензировании конкретного вида деятельности.

Например, если вы решили заняться врачебной деятельностью, тогда для того, чтобы получить лицензию вы должны соответствовать следующим основным характеристикам:

  1. должно быть помещение в собственности или снятое в аренду;
  2. должно быть мед.оборудование, аппараты, необходимые для оказания услуг;
  3. у руководителей и ответственных сотрудников должно быть высшее мед.образование, соответствующая квалификация и стаж работы не менее 5 лет;
  4. с работниками должны быть заключены трудовые договоры;
  5. наличие контроля качества и безопасности.

Также могут быть ограничения на организационно-правовую форму, например, ИП не может получить лицензию на производство и продажу алкогольной продукции, лицензии предоставляются исключительно юр.лицам.

Какие документы нужны для получения лицензии

В лицензирующий орган нужно подать следующий пакет документов:

  • заявление по установленной форме;
  • копии учредительных документов организации, заверенных у нотариуса;
  • необходимые документы, которые могут быть установлены положением о лицензировании конкретного вида деятельности;
  • опись прилагаемых документов.

Форма заявления устанавливается положением о лицензировании отдельного вида деятельности.

Способы предоставления документов

  • В лицензирующий орган — с 1 января 2021 только в электронном виде при помощи электронной подписи.
  • Через МФЦ — можно на бумаге. Только уточните перед визитом в МФЦ, оказывают ли они подобную услугу.

Куда подавать заявление и сроки получения лицензии

Лицензирующие органы определены по видам деятельности в Перечне, утвержденном Постановлением Правительства Российской Федерации от 21 ноября 2011 г. N 957. Необходимо обращаться в их региональные управления. Например, МЧС осуществляет лицензирование деятельности по обеспечению пожарной безопасности, МВД —охранную деятельность, Росздравнадзор —фармацевтическую деятельность.

В течение трех рабочих дней со дня представления заявления лицензирующий орган принимает решение о рассмотрении или о возврате с мотивированным обоснованием причин возврата.

Если в заявлении будет выявлено нарушение требований или документы представлены не в полном объеме, то в течение трех рабочих дней лицензирующий орган вручает уведомление о необходимости устранения. На исправление даётся 30 дней.

В течение 45 рабочих дней со дня приема заявления и документов, осуществляется проверка полноты и достоверности сведений и принимается решение о предоставлении лицензии. Решение оформляется приказом (распоряжением) лицензирующего органа. В течение 3 рабочих дней после подписания лицензии лицензирующим органом предпринимателю отправляют уведомление — на email или по почте. Заодно могут отправить выписку из реестра, если вы выбрали такую опцию в заявлении.

Бумажные лицензии с 1 января 2021 года не выдают. Имеет значение только запись в реестре.

Проверки

За фирмами, которые получили лицензию на осуществление деятельности, ведётся контроль, поэтому предпринимателю нужно быть готовым к плановым и внеплановым проверкам.

Плановые проверки проводятся на основании утвержденного плана-графика. Для каждого вида деятельности разная периодичность проверок, сроки варьируются от одного года до трех лет.

Внеплановая выездная проверка может быть назначена, если:

  1. истек строк устранения выявленных нарушений лицензионных требований;
  2. в лицензирующий орган поступили обращения, заявления о грубых нарушениях лицензионных требований;
  3. истечение срока, на который было приостановлено действие лицензии;
  4. если организация просит о проведении лицензирующим органом внеплановой выездной проверки в целях установления факта досрочного устранения нарушений лицензирующего органа;
  5. по приказу (распоряжению), изданного лицензирующим органом в соответствии с поручением Президента Российской Федерации или Правительства Российской Федерации.

Какие лицензии продлили из-за пандемии

Лицензии бывают срочные и бессрочные. Бессрочные продлевать не надо: они действуют до тех пор, пока не изменятся важные реквизиты организации. Все срочные лицензии продлили на 2020 год постановлением правительства № 440. На 2021 год лицензии продлят уже не всем, а только определённым сферам. Например, медицине, охране труда и образованию.

Получайте новости и обновления Эльбы

Нажимая кнопку Подписаться, вы соглашаетесь на обработку персональных данных и получение информационных сообщений от группы компаний СКБ Контур

Microsoft Enterprise Agreement Subscription (EAS)

Разработчики:Microsoft
Технологии:Офисные приложения

Microsoft Enterprise Agreement – самое оптимальное предложение корпорации Microsoft для крупных организаций по всему миру, готовых выбрать платформу Microsoft в качестве корпоративного стандарта. В рамках соглашений EA компания лицензирует базовые продукты Microsoft для всех используемых ПК, при этом оплата производится в виде ежегодных платежей. Заказчик может использовать выбранные продукты на всех компьютерах, в том числе на территориально удаленных, а также на новых ПК, добавляемых в течение срока действия соглашения. В рамках соглашения лицензии приобретаются в постоянное пользование с правом лицензирования дополнительных продуктов. В течение действия соглашения заказчику предоставляется пакет дополнительных бесплатных услуг по программе Software Assurance – обучение в сертифицированных учебных центрах, техническая поддержка серверных продуктов, право использовать Office на домашнем ПК, подписка на TechNet Plus и многое другое. Одно из ключевых достоинств, которое получает заказчик – упрощение схемы лицензирования и снижение риска нелицензионного использования программного обеспечения.

Microsoft Enterprise Agreement (EA) и Microsoft Enterprise Agreement Subscription (EAS) — программы корпоративного лицензирования, предназначенные для организаций с числом компьютеров от 250, готовых выбрать платформу Microsoft в качестве корпоративного стандарта. В рамках соглашений Enterprise Agreement и Enterprise Agreement Subscription организация лицензирует базовые продукты Microsoft для всех используемых ПК, при этом оплата производится в виде ежегодных платежей.

К базовым продуктам относятся:

  • Microsoft Windows Pro Upgrade;
  • Microsoft Windows Pro Upgrade c MDOP;
  • Microsoft Office Professional Plus или/и Office Enterprise;
  • Набор клиентских лицензий для доступа к серверам Microsoft (Core CAL Suite или Enterprise CAL Suite).

Организациям предоставляется возможность лицензировать весь набор трех продуктов — так называемую платформу Desktop Platform — или каждый из базовых продуктов в отдельности и в течение всего срока действия соглашения использовать самые последние версии выбранных продуктов (право Software Assurance заложено в стоимость лицензий).

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

Преимущества Enterprise Agreement и Enterprise Agreement Subscription

Снижение риска нелицензионного использования программного обеспечения. В течение срока действия соглашения Enterprise Agreement Ваша компания получает право использовать лицензированные продукты на всех компьютерах, включенных в соглашение, и добавлять новые компьютеры в течение срока действия соглашения, размещая заказы на новые лицензии по мере начала использования этих лицензий или в годовщину соглашения. Возможность полностью контролировать расходы на приобретение программного обеспечения. Стоимость лицензий в расчете на один ПК остается постоянной в течение всего срока действия соглашения, а автоматическое включение опции Software Assurance позволяет застраховаться от возможного повышения цен в связи с выходом новых версий.

2016: Microsoft повышает минимальное количество ПК для соглашений Enterprise Agreement

В марте 2016 года корпорация Microsoft объявила о внесении важного изменения в свою программу корпоративного лицензирования Enterprise Agreement. Начиная с 1 июля 2016 г. минимальный порог для заключения соглашения EA возрастет с 250 до 500 ПК.

1 февраля 2016 года корпорация Microsoft сделала ещё один шаг в развитии своей стратегии «Мобильные устройства и облачная среда – прежде всего» («Mobile first, Cloud first»), о которой она объявила еще в 2014 г. Требования о повышении порогового значения для программы Enterprise Agreement направлены на значительное упрощение соглашений о корпоративном лицензировании. Они также прольют свет на запутанную процедуру получения лицензий, которая часто подвергается критике со стороны клиентов и партнеров, являясь чрезвычайно сложной. Клиенты, использующие менее 500 ПК, смогут заключить соглашение EA исключительно до 30 июня 2016 г. С 1 июля 2016 г. будут приниматься только заказы, превышающие количество в 500 ПК. Порог останется неизменным в тех странах, где соглашение Microsoft Products and Service Agreement (MPSA) недоступно, например, в Китае и Индии.

Почему Microsoft вносит изменения в свою программу Enterprise Agreement?

По данным Microsoft, программа Enterprise Agreements предлагает значительные преимущества компаниям, использующим более 500 ПК. Компании поменьше чаще прибегают к комбинированным решениям или полностью переходят на использование облачной среды, т.е. перестают соответствовать требованиям соглашения ЕА.

Когда установленное в соглашении изменение вступит в силу и кого затронет?

Изменение вступит в силу 1 июля 2016 г. и будет распространяться исключительно на клиентов-предпринимателей и только на тех рынках, на которых доступно соглашение Microsoft Products and Service Agreement (MPSA).

Что будет с текущими клиентами, которые не соответствуют минимальному порогу в 500 ПК?

Существует два варианта действий, которые могут предпринять клиенты, уже заключившие соглашение Enterprise Agreement: во-первых, они имеют право на однократное продление своего соглашения ЕА до 36 месяцев; во-вторых, они могут выбрать программу альтернативного корпоративного лицензирования.

Какие альтернативные решения предлагает Microsoft своим клиентам, которые не соответствуют требованию о минимальном пороге в 500 ПК?

Компания, использующая от 250 до 499 ПК, претендует на заключение соглашения Microsoft Products and Service Agreement (MPSA). Данная программа существует с 2014 г., исправно предлагая гибкость и прозрачность, в которых нуждаются компании такого размера. Она предусматривает подписание единственного соглашения, выступающего основой для получения всех лицензий на программное обеспечение и принятия решений, касающихся облачной среды. Программное обеспечение можно приобрести с легкостью и именно тогда, когда оно действительно необходимо. Кроме того, клиенты могут приобрести лицензию для внутрихозяйственной деятельности или в качестве «облачного» решения или же комбинированно.

Программа Microsoft Cloud Solution Provider (CSP) является ещё одной альтернативой программе Enterprise Agreement. Данная программа разработана специально для клиентов, желающих переместить все свои данные в облачную среду.

Коснется ли данное изменение государственных органов и государственного сектора?

Нет. Минимальный порог в 250 ПК останется в силе для государственных органов и государственного сектора.

Корабль Тесея применяется к GPL — Могу ли я повторно лицензировать свою программу, если я заменю все производные части?

Я перевел C программу на GPLv2 Python , но обнаружил, что ее сложно расширить, как задумано, и переписал ее значительную часть. Программа в настоящее время структурно совершенно другая, но в ней используется несколько дословно переведенных функций.

Корабль Тесея Paradox (как указано в Википедии) «поднимает вопрос о том, остается ли объект , который имел все его компоненты заменены принципиально тот же предмет.»

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

В связи с этим, смогу ли я вытащить развитую архитектуру и использовать ее с другой лицензией? Я думаю, что это было бы очень полезно само по себе, но мне не нравится идея, что теперь он «испорчен» лицензией GPL.

Продолжение : я решил связаться с правообладателем и получил разрешение на повторную лицензию . Иногда лучший способ — это взаимодействовать, а не программно!

Во-первых, ответ «нет» (для перевода), вы не можете юридически лицензировать его или делать что-либо, выходящее за рамки оригинальной лицензии. Вы, возможно, очень хорошо сделали 10 раз работу оригинального автора, но это не имеет значения, это вирусный. Не только потому, что это GPL, но и потому, что это не чистый дизайн или переписывание.

Я кратко боролся с этим в 1992 году, когда я сделал большую переписку старой базы кода MUD. У нас была успешная игра, но мы хотели заниматься своим делом, и люди были готовы платить за нее, но лицензия DikuMUD строго запрещала нам зарабатывать деньги. Конкурент, в то время, также основывал их на той же кодовой базе, и они решили явно игнорировать авторское право, вырвать все его следы и в основном лгать всем, включая себя. Их логика заключалась в том, что «ни один из исходных кодов не существует» и «мы проделали огромную переписку и улучшения» и вообще игнорировали тот факт, что они начали с 20 000 строк кода. Они заряжали предметы в игре и зарабатывали слишком много денег, чтобы остановиться.

Я был по общему признанию завистлив. Но я исследовал закон об авторском праве, советовался со своей совестью и решил, что даже не смогу использовать написанный мной код, потому что, честно говоря, не создавал игровой сервер с нуля.

Поэтому я решил положить свои деньги туда, где я был, и писать с нуля, с копией сетевого программирования У. Ричарда Стивена для UNIX , которое я всегда брал с собой. Писать с нуля, по-моему, научило меня намного больше, чем когда я переписал DikuMUD, и это также научило меня, что я действительно не понимаю, что значит стоять на чужих плечах. В течение шести месяцев у меня было 50 000 строк операционного кода, который я мог назвать своим. Я назвал это MUD ++ и выпустил его под BSD. Плохо написанный в раннем стиле C ++, он все еще был первым свободным открытым исходным кодом C ++ MUD, о котором я знаю. По сей день никто не может отобрать это у меня. У меня был лучший TCP-сервер в то время, никто не мог выполнить «горячую перезагрузку», не выбрасывая игроков, и вскоре все стали воровать эту функциюи я заметил, что во многих GPL MUD есть фрагменты моего BSD-кода — всегда интересно, как GPL может перехватить BSD-программу, но не наоборот ). В конце концов, я пошел дальше, так что это не было похоже на то, что решение было удачей или неудачей для моего состояния, но в то время как другие ребята какое-то время зарабатывали много денег, в последний раз я смотрел, как они истощились в мире графических игр. массового спроса на текст больше нет.

История не заканчивается . несколько лет спустя я работал в IBM, и Дисней нанял нас для написания многопользовательской 3D-игры в реальном времени для центра Epcot, и я смог использовать ядро ​​TCP из MUD ++ в качестве основы для этого. игровой сервер! Если бы я не владел своим собственным кодом, мне бы не разрешили его использовать, и это честно сэкономило мне недели кодирования. В конце я горжусь тем выбором, который я сделал, и у меня есть история, которую я могу рассказать своим детям.

Люди недооценивают и недооценивают выгоду, начиная с чьей-то основы, на которой можно строить

Если вы думаете, что «владеете» им, проверьте себя. Начните сначала, с книгой Python рядом с вами. Посмотрите, каково это. Не обманывайте и не смотрите на старую кодовую базу. Посмотри на вывод. Заставьте себя самостоятельно продумать каждый аспект, проводя честное исследование. Вы будете лучше за это, и, вероятно, есть лучший продукт.

Прежде чем сделать это, попробуйте связаться с автором оригинала. Спросите их, не захотят ли они получить лицензию. Если вы планируете продавать двоичные файлы, предлагайте лицензионные платежи. Многие авторы, которые выпустили GPL в 90-х и 2000-х годах, сейчас им по 30, 40 и 50 лет, и они понимают, что значит зарабатывать на жизнь программным обеспечением. Я видел больше, чем одну лицензию их версий от GPL до MIT, Apache, Boost или BSD.

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

Я верю, что БЕСПЛАТНО. Если вам нужно прикрепить строки, не называйте это бесплатно. Несколько лет спустя кто-то отправил мне письмо и сказал, что они использовали мою игру в коммерческом движке, в основном, в TCP и, возможно, в интерпретаторе байт-кода. Они делали деньги. Я не возражал ни капли. Я был счастлив, как и сейчас, как гордый отец.

Лицензирование программного обеспечения

Эта статья написана для тех, кто хочет понять, что такое лицензия и лицензирование программного обеспечения и для чего это нужно. Рассмотреть все возможные схемы лицензирования ПО в небольшой по объему статье, естественно, не представляется возможным, поэтому я попытаюсь кратко показать лишь наиболее популярные из них.

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

Классификация лицензий и типы лицензирования ПО

В основном программы делятся на две большие группы — свободного использования (бесплатная и открытая лицензия) и несвободного (коммерческая лицензия), а также между ними существуют условно-бесплатные программы, которые можно отнести к двум группам пополам, такие программы можно скачать и использовать, но пока ее не оплатить у вас могут возникнуть некоторые проблемы или ограничения.

К открытым относятся: Open Source программы с открытым кодом которые можно модифицировать.

К бесплатным относятся: Freeware, GPL, Adware, Postcardware, Donationware, Nagware/Begware.

К условно-бесплатным относятся: ShareWare, TrialWare, Demoware.

К коммерческим относятся: Commercial главная цель таких программ получение прибыли, код программ закрыт.

Для наглядности рассмотрим сравнительную характеристику условий самых распространенных лицензий в виде таблицы, где будет указано о наличии или отсутствии в лицензии тех или иных требований. Все лицензии, которые будут рассматриваться являются лицензиями, одобренными Open Source Initiative для распространения ПО с открытым исходным текстом.


* Если нет письменного разрешения об использовании наименования продукта создателей лицензии.
** В данном случае речь идет об исходном тексте.

Защита своих авторских прав для разработчика — это и есть различные схемы лицензирования программного обеспечения. По каждому отдельному виду программного продукта применяются разные типы лицензирования.

Кратко разберем какой тип лицензирования что из себя представляет.

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

Full Package Product. «Коробочный» продукт применяется в основном для розничной торговли и удобен для частных лиц или малого бизнеса. Разрешение на использование программного продукта на одном компьютере дает покупка одной «коробки» и не важно, сколько людей будет пользоваться этим ПК. Так же можно сменить ПК, но определенное количество раз.

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

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

Итак, теперь посмотрим в чем же разница типов лицензирования, а что бы это было нагляднее представим в виде таблицы.

Теперь по этой таблице можно сделать вывод, кому, что больше подойдет.

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

FPP версия подойдет для тех у кого уже куплено оборудование, но отсутствует на нем нужное ПО, особенно если компания маленькая и сотрудники будут пользоваться одним ПК по несколько человек.

VL версия подойдет для больших компаний которым нужна быстрая тех. поддержка и возможность решения нестандартных ситуаций. А также при покупке лицензии для всей компании всегда существуют очень хорошие скидки.

SUB версия подойдет для тех кто хочет использовать ПО кратковременно, или не знает на сколько данное ПО ему пригодится. Если же продукт нужен на долгое использование, то лучше посмотреть версию из “коробки”.

Тенденция развития лицензирования.

В заключении хотелось бы показать, как развивается лицензирование и к чему все идет. На данный момент популярны два направления:

1) Подписка на лицензирование ПО. Производители программного обеспечения серьезно взялись за перевод своих продуктов на платную «подписку». Зачем платить за продукт сразу всю сумму если можно платить частями по мере использования? Сравним достоинства и недостатки данного лицензирования для пользователя, а также приведем пример выгоды данного способа для разработчиков программного обеспечения.

Разработчики программного обеспечения плавно переводят от “вечного” использования продукта к подписке. Рассмотрим наглядно как это работает:

Тем самым производители программного обеспечение стимулируют пользователей покупать подписку непрерывно.

2) Частичный перевод коммерческих продуктов на открытые лицензии. Тем самым привлекая к себе для спонсирования крупные компании и государства.

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

0 0 голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector