По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Образы Docker в работающем контейнере не обновляются автоматически. После того, как вы использовали образ для создания контейнера, он продолжает работать с этой версией даже после выхода новых выпусков.
Рекомендуется запускать контейнеры из последнего образа Docker, если у вас нет особой причины использовать более старую версию.
В этом руководстве вы узнаете, как обновить образ и контейнер Docker до последней версии.
Обнолвение образа и контейнера Docker до последней версии
Лучший способ обновить существующий контейнер c новым образом - загрузить последний образ и запустить новый контейнер с той же конфигурацией. Следуйте инструкциям ниже, чтобы обновить свой контейнер до новейшего образа Docker.
Примечание. В этом руководстве используется пример запуска контейнера MySQL Docker, чтобы проиллюстрировать, как обновить образ и контейнер Docker до последней версии.
Шаг 1. Проверьте текущую версию
Убедитесь, что у вас устаревший образ, выведя список образов в вашей системе с помощью команды:
sudo docker images
Тут отображаются загруженные изображения и их теги (номера версий). В приведенном ниже примере система показывает, что она использует образ mysql версии 5.7.31. Официальные образы MySQL от Docker, перечисленные на DockerHub, показывают, что последняя версия - 8.0.21.
Поэтому, если у вас есть контейнер, работающий с этим образом, лучше его обновить.
Чтобы указать только определенный образ, который может быть устаревшим, используйте docker images | grep [docker_image], чтобы сузить поиск.
Шаг 2. Скачайте новейший образ
Загрузите более новую версию образа с помощью команды docker pull:
docker pull [docker_image]
По умолчанию Docker загружает последнюю версию. Чтобы убедиться в этом, вы можете добавить тег :latest.
Например, чтобы получить последний образ mysql, вы должны запустить:
docker pull mysql/mysql-server:latest
Шаг 3. Запустите новый обновленный контейнер
После того, как вы загрузили последний образ Docker, вам необходимо остановить и удалить старый контейнер. Затем создайте новый с последним образом.
1. Найдите имя запущенного контейнера с устаревшим образом, перечислив контейнеры в системе:
docker ps
В этом примере на выходе показан контейнер с образом mysql / mysql-server: 5.7.31.
2. Остановите и удалите существующий контейнер, чтобы вы могли запустить новый под тем же именем:
docker stop [container_id]
docker rm [container_id]
3. Воссоздайте контейнер с помощью команды docker run и желаемой конфигурации, используя обновленный образ Docker:
docker run --name=[container_name] [options] [docker_image]
Если он у вас есть, обязательно смонтируйте том Docker, назначенный ранее использовавшемуся контейнеру, чтобы обновленный контейнер имел такое же содержимое. Для этого используйте параметр -v, за которым следует путь к каталогу тома.
Например, чтобы запустить обновленный контейнер MySQL, вы должны запустить:
docker run --name=mysql --restart=always -e MYSQL_ROOT_PASSWORD=mypassword -v /path/to/directory:/var/lib/mysql -d mysql
4. Вы можете проверить, обновлен ли ваш контейнер последней версией образа Docker, таким образом:
sudo docker ps
Таким образом, вы должны были успешно обновить свой контейнер Docker.
Итак, вы хотите стать DevOps-инженером? Это впечатляющий, сложный и высокооплачиваемый вариант карьеры, но такая ключевая роль объединяет разработку программного обеспечения и его эксплуатацию. Мы составили дорожную карту DevOps, которая включает в себя все шаги, которые необходимы для того, чтобы занять место эксперта DevOps.
Как вы знаете, DevOps – это набор практик и инструментов для интеграции и автоматизации процессов между IT-командами и командами разработчиков программного обеспечения. Поэтому он фокусируется на общении и сотрудничестве между командами, используя лучшие инструменты автоматизации, доступные для повышения эффективности.
Следующий акцент делается на объединении тех, кто работает в области разработки программного обеспечения с развертыванием ПО, а также на обеспечении высокого уровня структурной и технической поддержки.
Это все означает, что DevOps-инженеры должны знать свое дело, чтобы справиться с этой неподъемной задачей. А что же тогда такое «их дело»? Оказывается, что это не просто их дело, но и дело всех остальных.
Конечно, это может звучать, как что-то невероятное, что мало кто может преодолеть. DevOps-инженеры действительно являются экспертами высокого уровня, и стать одним из них также практически невозможно. Вместе с тем, данное руководство поможет вам четко понять, какие шаги необходимо предпринять, прежде чем начать свое путешествие по DevOps.
Давайте посмотрим.
Зачем вам нужна дорожная карта DevOps?
В нашей статье о DevOps рассказывается о том, почему стать DevOps-инженером так сложно, ведь DevOps-команды включают в себя разработчиков и IT-специалистов, работающих рука об руку на протяжении всего жизненного цикла проекта.
И поэтому, дорожная карта DevOps предполагает высокие навыки и необходимые шаги, которые помогают повысить скорость и качество разработки и развертывания и предотвратить организационную разрозненность. Иногда команды объединяются, чтобы максимизировать эффективность, при этом инженеры работают на протяжении всего жизненного цикла продукта или приложения.
Итак, каковы же эти требования? Вот этот исчерпывающий список для того, чтобы получить эту дорожную карту, которая направит вас на верный путь.
Как стать DevOps-инженером за 14 шагов
1. Изучайте языки программирования
Первый шаг к тому, чтобы стать DevOps-инженером, - это владение одним или несколькими языками программирования. Конечно, вы не будете интегрировать базы данных или автоматизировать процессы разработки и развертывания, отлаживать базы данных, отлаживать код и исправлять возникающие проблемы, но в результате вы должны внести свой вклад в поддержание конвейера непрерывной интеграции/поставки в рабочем состоянии.
Если вы читаете эту статью, то мы можем предположить, что вы владеете хотя бы одним из «больших» языков программирования, таких как Java, JavaScript или Python. Но если все же нет, то мы рекомендуем вам повысить уровень знания до высокого как минимум двух или трех языков программирования из списка ниже:
Python
Perl
Java
JavaScript
Go
Ruby
Rust
C
C++
2. Научитесь работать с разными ОС
DevOps-инженеру необходимо знать, как работают разные операционные системы, а также различия между ними, в основном потому, что вы будете запускать приложения на серверах. В связи с этим, оптимальным решением для такого рода вещей, как правило, является Linux – ее используют большинство компаний и поставщиков серверов. Если вы используете веб-приложение, то оно, вероятнее всего, находится на сервере Linux.
Есть и другие операционные системы, которые не помешает знать:
Windows
Unix
Debian
SUSE Linux
Fedora
Ubuntu
CentOS
RHEL
macOS
FreeBSD
OpenBSD
NetBSD
3. Концепция ОС
Так вот, операционные системы – это лишь часть дорожной карты DevOps. Также вы должны быть в состоянии углубиться, понимая базовую инфраструктуру ОС, которая позволяет вам запускать приложение. Это называется «концепцией операционной системы», и вы должны быть знакомы с:
Управлением запуском
Управлением процессом
Сокетами
Front-end разработкой
Потоками и параллелизмом
Управлением вводом/выводом
Основами POSIX
Виртуализацией
Файловыми системами
Памятью и хранилищем
Управлением службами
Сетью
4. Сетевая безопасность и протоколы
Как DevOps-инженер, вы должны быть всегда спокойны. Сетевая безопасность и протоколы помогут вам обеспечить целостность и безопасность ваших данных. Они определяют процессы и методологии, которые вы будете использовать для защиты вашей сети от попыток несанкционированного доступа.
Вот протоколы, о которых вам следует знать:
HTTP
HTTPS
FTP
Межсетевые экраны
SSH
SSL/TTS
IPsec и VPN
Переадресация портов
AT-TLS
SNMP
Аутентификация OSFP
Прокси-доступ
5. Терминалы – ваш новый дом
Консоль позволяет разработчикам автоматизировать, создавать сценарии и выполнять системные задачи без использования графического пользовательского интерфейса.
В следствие чего, вы должны уметь работать с текстом, создавать bash-сценарии, отслеживать процессы, производительность системы, работать в сети, компилировать приложения из исходника, Vim, Nano, Emacs и Powershell.
Мы готовы поспорить, что, если вы уже привыкли, и вам удобно, создавать файлы .cfg в выбранной вами FPS, то здесь вы будете как дома. И вам в любом случае нужно будет это делать.
6.Веб-серверы
Когда пользователь запрашивает информацию, сервер выполняет запрос. На веб-сервере может размещаться один или несколько веб-сайтов с использованием одного и того же оборудования и ресурсов. Он взаимодействует с веб-браузером через HTTP/HTTPS. Быть DevOps-инженером означает знать, как контролировать сервер.
Вот некоторые распространенные веб-серверы, о который вам стоит узнать:
Apache
Nginx
IIS
Tomcat
Caddy
Istio
Envoy
Consul
Linkerd
7. Инструменты непрерывной интеграции/непрерывной поставки
Конвейер непрерывной интеграции/поставки (CI/CD) необходим для разработки программного обеспечения в рамках DevOps. Как было сказано в предыдущей статье, непрерывная интеграция – это методика разработки программного обеспечения, при которой разработчики объединяют все изменения кода, которые они вносят, в единый репозиторий.
В то время как, непрерывная поставка реализует изменения кода, которые автоматически создаются, тестируются и подготавливаются в производственному выпуску. Ее можно рассматривать как расширение непрерывной интеграции.
Вот некоторые из инструментов, которые вы можете использовать для этой цели:
TravisCI
GitHub
GitLab
Bamboo
Jenkins
TeamCity
Azure DevOps
8. Изучите инфраструктуру как код (IaC)
Пожалуй, это одно из основных направлений работы DevOps-инженеров. Поэтому неудивительно, что эта тема довольно обширная и разнообразная. Знание таких контейнеров, как Kubernetes и Docker, а также различных инструментов управления конфигурацией имеет жизненно важное значение для вашего собственного развития и успеха проектов, которые вы возглавляете.
Вот некоторые DevOps-инструменты, о которых вам следует знать:
Docker
Containers
LXC
Ansible
Salt
Chef
Puppet
Mesos
Kubernetes
Docker Swarm
Nomad
Istio
Service Mesh
Linkerd
Consul Connet
Maesh
Kuma
Terraform
9. Управление приложениями
Управление приложениями относится к процессу измерения доступности, возможностей и производительности приложения. Данные, собираемые в процессе, позволяют выявлять и устранять баги и ошибки до того, как у пользователей возникнут проблемы. Обычно используется такое программное обеспечение, как:
AppDynamic
Instana
New Relic
Jaeger
OpenTracing
10. Управление инфраструктурой
Эта часть дорожной карты DevOps влечет за собой процесс получения как можно большего количества данных о вашей инфраструктуре с целью принятия обоснованных оперативных решений.
В этой связи, используются данные, генерируемые помимо прочего приложениями, серверами и сетевыми устройствами, с целью отслеживание таких показателей, как мощность оборудования, пропускная способность сети и время работоспособности. В свою очередь, эта информация помогает повысить эффективность и устранять ошибки, показывая, какие области требуют большего внимания.
Вот некоторые хорошие инструменты для управления инфраструктурой:
Grafana
Prometheus
Zabbix
Nagios
Datadog
11. Шаблон облачного проектирования
Этот шаблон помогает создавать масштабируемые, надежные и безопасные приложения в облаке. Однако для этого необходимо быть знакомым с одним ли несколькими шаблонами облачного проектирования. На наш взгляд, одними из самыми важными являются следующие:
Источники событий
Посредник
CQRS
Агрегирование на шлюзе
Консолидация вычислительных ресурсов
Внешнее хранилище конфигурации
Уровень защиты от повреждений
Каналы и фильтры
Перенесение в шлюз
Маршрутизация шлюза
Расширение за счет внешних устройств
12. Управление логами
Логи помогают составлять список событий, происходящих в системе, и изучать их детали. Благодаря этому, управление журналами поможет вам, то есть начинающему DevOps-инженеру, улучшить службы и процессы, предотвратить уязвимости и выявить узкие места.
Вот некоторые из инструментов, которые вы так или иначе будете использовать:
Splunk
Elastic stack
Graylog
Papertrail
13. Поставщики облачных услуг и пакеты услуг
Как мы уже поняли, облачные услуги – это то, с чем обязательно нужно быть знакомым DevOps-инженеру. Кроме того, вам необходимо понимать преимущества и особенности каждого поставщика облачных услуг для того, чтобы ваша организация могла сделать верный осознанный выбор. Некоторые из популярных заслуживают того, чтобы их изучили, например:
Google Cloud
AWS
Azure
Digital Ocean
Linode
Alibaba
Конечно, стоит отметить, что эти провайдеры редко работают по фиксированной стоимости. Как правило, цены на эти услуги зависят от необходимого количества доменов и памяти и SSL-сертификатов, требуемых ЦП.
14. Другие технологии
Это лишь краткий список того, что вам нужно сделать, чтобы получить знания на пути к тому, чтобы стать DevOps-инженером.
Таблица кэша
Обратный прокси-сервер
Прокси-сервер переадресации
Межсетевой экран
Балансировка нагрузки
Сервер кэширования
Заключение
Дорожная карта DevOps предназначена для того, чтобы направить вас на правильный путь к профессиональным навыкам DevOps. Конечно, это не означает, что он уже устоявшийся и не подлежит изменению. Технологии меняются ежедневно, и вы должны постоянно быть в курсе новых инструментов и решений. Еще один пункт на пути к становлению DevOps-инженером – это обучение и адаптация, и, пожалуй, самое важное – хорошо выполнять свою работу.
Если вы следуете этой дорожной карте и у вас уже есть солидная база знаний в области компьютерных наук, то вам потребуется всего каких-то шесть месяцев для того, чтобы сдвинуться с той точки, в которой вы сейчас, и дойти до начала своей карьеры DevOps-инженера.
Не забудьте добавить следующие пункты в список того, что нужно выучить:
Языки программирования
Концепции ОС
Терминалы
Сеть и безопасность
Инструменты CI/CD
Веб-сервер
Инфраструктура как код
Управление приложением
Управление инфраструктурой
Шаблон облачного проектирования
Управление журналом
Поставщики облачных услуг и управление службами
Другие технологии
Часто задаваемые вопросы
Чем занимается DevOps-инженер?
DevOps-инженер использует инструменты, процессы и методологии, чтобы удовлетворить все потребности в процессе разработки программного обеспечения, разработки оболочки пользовательского интерфейса и кодирования для развертывания, обслуживания и обновлений.
Сколько времени нужно, чтобы стать DevOps-инженером?
Если у вас уже есть опыт работы с Linux и сетями, и вы следуете дорожной карте DevOps-инженера, то это займет примерно шесть месяцев.
Что такое CI/CD в DevOps?
Это передовая методология DevOps, которая использует автоматизацию разработки приложений, позволяя увеличить скорость разработки и развертывания приложений. CI/CD относится к непрерывной интеграции, поставке и развертыванию.
Это подробное руководство предоставит вам информацию для эффективного сравнения лицензий Open Source, что должно помочь вам при выборе лицензии Open Source, подходящей для Вашего проекта.
Итак, вы уже некоторое время работаете над крутым проектом – и вот вы готовы сделать важный шаг и превратить ваш закрытый код в открытый.
Эта задача кажется несложной – просто почистить исходники и историю версий перед тем, как залить свой репозиторий на GitHub или Bitbucket... пока не всплывает вопрос о лицензии. Оказывается, выбор такой широкий. Какую лицензию выбрать? И нужна ли она вам вообще на самом деле?
Можно коротко ответить на последний вопрос: да, вам действительно нужна лицензия. А на вопрос о том, какая лицензия вам нужна, мой ответ ещё короче: когда как. Но если вы серьёзно относитесь к своему проекту, вам, вероятно, потребуется немного больше деталей. Что ж, читайте дальше – и помните: вы вступаете на территорию бесконечных споров!
Нужна ли мне лицензия? И что вообще такое лицензия?
Лицензия – это официальное разрешение, предоставленное автором какой-либо работы («Лицензиаром») сторонним лицам («Лицензиатам») и регулирующее использование лицензиатом работы лицензиара. Она имеет форму договора, с которым должны согласиться обе стороны. В наше время - это согласие бывает неявным: подразумевается, что, просто используя какую-либо работу, вы соглашаетесь с условиями её лицензии на использование.
Поясню: выпуская свою собственную работу, лицензиаром являетесь именно вы. А лицензиатом – любое лицо, использующее ваш код. Проще говоря, речь идёт о двух главных категориях: разработчиках и конечных пользователях.
И для закрепления ещё некоторых терминов: модифицируя вашу работу, лицензиат создаёт то, что называется производной работой (производным произведением). Не все лицензии одинаково трактуют то, становится ли более масштабный по сравнению с вашей работой проект производным произведением, если она была использована в этом проекте. Как вы увидите ниже, некоторые лицензии отдельно прописывают такие случаи.
Какова цель лицензии?
В целом, лицензия – это способ договориться о правах и обязанностях сторон для лицензиара и лицензиата. Эти права и обязанности могут быть любыми – в рамках законодательства. К примеру, лицензиар может потребовать обязательного указания имени правообладателя при использовании работы лицензиатом. Или разрешить копирование своей работы, но запретить любую её модификацию. Или даже потребовать, чтобы производная работа выпускалась на тех же условиях, что и оригинальная.
С другой стороны, лицензия защищает и лицензиата. Поскольку в ней явно прописаны условия использования работы, ему не угрожает то, что вы внезапно потребуете лицензионные отчисления или любые другие виды компенсации за использование своей работы. Это важно для распространения вашей работы.
Итак, лицензия защитит вашу работу. Защитит лицензиата. Но помимо этого она защитит и вас – и я имею в виду вас лично. К примеру, ограничивая ответственность лицензиара за потенциальный вред, причиной которого стала его работа.
А что, если я не буду использовать лицензию?
При отсутствии лицензии, ассоциированной с работой, «по умолчанию» действуют авторские права в соответствии с юрисдикцией страны автора. Другими словами, никогда не считайте, что «отсутствие лицензии» подразумевает, что другие люди могут делать с вашей работой что угодно. Всё как раз наоборот: без определенной лицензии вы, автор, не отказываетесь ни от каких прав, предоставленных законом.
Но всегда помните, что лицензия регулирует права и обязанности. Вы когда-нибудь задумывались, почему в тексте многих лицензий содержится написанное БУКВАМИ В ВЕРХНЕМ РЕГИСТРЕ предупреждение о гарантиях, предоставляемых вместе с продуктом – или, куда чаще, об отсутствии таковых? Это делается для того, чтобы защитить владельца работы от пользовательских ожиданий и того, что подразумевается какая-либо гарантия. Последнее, что вам нужно – это чтобы на ваш открытый код подали в суд!
Могу ли я использовать кастомную (собственную) лицензию?
Да, можете. Но, вероятно, не стоит этого делать.
Являясь договором, лицензия не может иметь приоритет над территориальными законами. Отсюда возникает сложность соблюдения лицензионных прав в глобализированном мире. Скорее всего, будет проще (я имею в виду, менее сложно) защитить в суде «стандартную» лицензию. Собственно, такие дела уже защищались в некоторых юрисдикциях и на них можно ссылаться в качестве прецедента. Очевидно, что нельзя сказать то же про кастомную лицензию.
К тому же, кастомные лицензии (прозванные «лицензиями для тщеславных») могут оказаться несовместимыми с другими лицензиями, результатом чего станет плохая совместимость вашей работы.
Могу ли я использовать несколько лицензий?
Да. Мульти-лицензирование – и в особенности двойное лицензирование – встречается нередко. Это особенно верно, если вы хотите создать бизнес на основе своего бесплатного произведения. В этом случае ваш проект, скорее всего, будет выпушен одновременно и под лицензией FOSS (Free And Open Source Software - Свободное и открытое программное обеспечение), и под коммерческой лицензией.
Другое применение мульти-лицензирования – для улучшения совместимости, чтобы ваша работа была сочетаема с работами, опубликованными под другими условиями, или для удовлетворения иных потребностей и запросов пользователей. По этой причине некоторые проекты выпускаются под несколькими лицензиями FOSS.
Но предупреждаю: не все лицензии совместимы между собой! Опять же, я рекомендую не переизобретать колесо и использовать лицензии, совместимость которых широко известна, если вы хотите пойти этим путём.
Могу ли я поменять лицензию «позже»?
Да. Держатель авторских прав отвечает за условия лицензирования. Довольно просто поменять лицензию, если вы – единственный автор. Но если, в качестве яркого примера, Линус Торвальдс захочет выпустить ядро Линукс под другой лицензией, ему, вероятно, сначала потребуется согласие нескольких тысяч других участников этого проекта. Это невозможно в действительности.
Для проекта средней величины это реально. И на самом деле делалось, как вы увидите в некоторых примерах ниже.
Какую лицензию Open Source мне следует использовать?
Хорошо, допустим, мне удалось убедить вас в том, что вам нужна стандартная лицензия. Но какую выбрать? Окончательный выбор за вами. И в сети достаточно хороших компараторов, которые помогут вам в этом выборе. Вот некоторые их них:
http://oss.ly/licdif
https://choosealicense.com/ или https://choosealicense.com/appendix/
https://opensource.org/licenses
https://tldrlegal.com/
Но как всегда в юридических вопросах, надежнее всего будет прочитать – и понять – официальный текст самих лицензий. Для этого может потребоваться помощь профессионального юриста.
Рассмотрим некоторые общие сведения о наиболее распространённых лицензий, чтобы помочь вам сделать первые шаги в нужном направлении.
Стандартная общественная лицензия GNU (GPL - GNU General Public License)
GPL – одна из наиболее популярных лицензий Open Source. У неё есть несколько версий – но для нового проекта вам лучше рассматривать последнюю из них, на момент написания этой статьи ей является GPL 3.
Поддерживая сильный копилефт, GPL, пожалуй, защищает больше всех остальных свободных лицензий. Что может быть, как плюсом, так и минусом, в зависимости от вашей точки зрения. Основной концепт GPL – что любые производные работы должны также выпускаться под этой лицензией.
Copyleft - это практика предоставления людям права свободно распространять копии и измененные версии произведения с условием сохранения тех же прав в производных работах, созданных позже.
Сильный копилефт;
Лицензиаты могут модифицировать работу;
Лицензиаты могут распространять исходный код вместе с производной работой;
Производная работа должна выпускаться на тех же условиях.
Популярные проекты
GPL – лицензия, наилучшим образом подходящая для проектов Фонда свободного программного обеспечения (Free Software Foundation - FSF), в том числе за счёт инструментов GNU в основе любой системы Linux. Большие проекты – заведомо коммерческие – часто используют GPL вместе с одной или несколькими другими лицензиями.
Inkscape (векторный графический редактор): GPLv2
Drupal (система управления веб-контентом): GPLv2
MariaDB (базы данных): GPL v2
MySQL (базы данных): GPL и коммерческая лицензия
Qt (кроссплатформенный фреймворк для разработки приложений): LGPL, GPL и коммерческая лицензия— в зависимости от модулей и соглашения об уровне обслуживания (SLA).
Меньшая стандартная общественная лицензия GNU (LGPL - GNU Lesser General Public License)
GPL – лицензия, очень строгая к тому, чтобы каждая производная работа публиковалась на тех же условиях, что и исходная, и с открытым исходным кодом. Это особенно неудобно в случае с библиотеками, которые служат «кирпичами» для крупных программных продуктов: если библиотека выпущена под GPL, то любое использующее её приложение должно также выпускаться под GPL. Эту сложность адресует LGPL.
В отношении библиотек Фонд свободного программного обеспечения (FSF) выделяет три случая:
Ваша библиотека реализует стандарт, который конкурирует с несвободным стандартом. В таком случае широкое распространение вашей библиотеки поможет продвижению свободного ПО. В этой ситуации FSF рекомендует использование довольно либеральной (разрешительной) лицензии Apache (она описана в статье далее).
Ваша библиотека реализует стандарт, уже реализованный другими библиотеками. В этом случае, полный отказ от копилефта никак не послужит продвижению свободного ПО. Для этого случая FSF рекомендует LGPL.
Наконец, если ваша библиотека не конкурирует ни с какими другими библиотеками или стандартами, FSF рекомендует GPL.
Рекомендации FSF имеют преимущественно этические и идеологические основания. В жизни у разработчиков могут быть иные заботы. Особенно если они планирует развивать дело на базе своей лицензированной работы. Ещё раз, возможно, в таком случае стоит присмотреться к двойному лицензированию.
Слабый копилефт (из-за динамического связывания с библиотеками);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты могут выпускать исходный код вместе с производной работой;
Если вы модифицируете работу, её необходимо выпускать на тех же условиях;
Если вы просто используете работу (в качестве библиотеки), нет необходимости выпускать производную работу на тех же условиях.
Популярные проекты
OpenOffice.org 3 (пакет офисных приложений): LGPLv3 — но Apache OpenOffice 4 перешёл на лицензию Apache 2.0.
GTK+, the GIMP Toolkit (библиотека элементов графического интерфейса): LGPLv2.1
CUPS (кроссплатформенная система печати): GPL or LGPLv2, за исключением ОС Apple, — в зависимости от компонентов.
WineHQ (слой совместимости с Windows): LGPLv2.1
GNU Aspell (проверка орфографии): LGPLv2.1
Eclipse Public License (EPL 1.0)
С более слабым копилефтом, чем в LGPL, лицензия Eclipse больше подходит для бизнеса и допускает сублицензирование и создание программного обеспечения (ПО) на основе кода как под EPL, так и под другими лицензиями (даже проприетарными), с условием, что код под другой лицензией вынесен в отдельный модель программного продукта.
Кроме того, EPL предоставляет дополнительную защиту соавторам кода под EPL в случае судебных исков/ущерба, вызванного коммерческой деятельностью, связанной с этой работой.
Слабый копилефт (из-за связанных подключаемых в продукт модулей);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Если вы модифицируете работу, её необходимо выпускать на тех же условиях;
Если вы просто используете работу, нет необходимости выпускать производную работу на тех же условиях
При коммерческом распространении продукта распространители обязаны защитить или выплатить компенсацию оригинальным авторам (под EPL) в случае судебных исков/ущерба в результате коммерческого использования продукта.
Популярные проекты
Очевидно, что EPL – наиболее подходящая лицензия для проектов Eclipse Foundation, в том числе Eclipse IDE. Но она прибрела некоторую популярность и за пределами этого – особенно в мире разработки на Java:
Clojure (язык программирования)
Graphviz (пакет утилит по визуализации графов)
Jetty (сервер для приложений): двойная лицензия EPL1.0/Apache 2.0 с версии Jetty 7
JUnit (фреймворк для модульного тестирования ПО на Java)
Mozilla Public License (MPL)
MPL – лицензия, которая используется для ПО, созданного Mozilla Foundation. Но её применение этим не ограничено. MPL пытается достичь компромисса между строгими лицензиями (такими как GPL) и либеральными лицензиями (такими как лицензия MIT).
«Лицензионной единицей» в MPL является исходный файл. Лицензиарам запрещено ограничивать права пользователей и доступ к любому файлу, на который распространяется MPL. Но один и тот же проект может содержать как файлы под MPL, так и файлы под проприетарной лицензией. Полученный в результате проект может быть опубликован под любой лицензией, при условии, что предоставляется доступ к файлам под MPL.
Слабый копилефт (в связи с отдельными файлами);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не могут заново лицензировать исходный код под MPL;
Лицензиаты обязаны выпускать исходный код под MPL вместе со своей производной работой.
Популярные проекты
Mozilla Firefox (веб-браузер), Mozilla Thunderbird (почтовый клиент): MPL
LibreOffice (пакет офисных приложений): MPL 2.0
H2 Database Engine (база данных): MPL2.0 и Eclipse License 1.0
Cairo (2D графическая библиотека) MPL 1.1 или LGPLv2.1
Apache License 2.0 (ASL 2.0)
С ASL мы попадаем в мир либеральных свободных лицензий. Но даже FSF в некоторых случаях рекомендует лицензию Apache. Лицензия Apache считается либеральной, поскольку не требует того, чтобы какие-либо производные работы выпускались на тех же условиях. Другими словами, это «не-копилефт» лицензия.
ASL – единственная лицензия, которая используется для проектов Apache Software Foundation. Считающаяся удобной для бизнеса, она получила широкое распространение за пределами этой организации. Можно нередко увидеть проекты корпоративного уровня, выпущенные под этой лицензией.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой.
Популярные проекты
Android (операционная система): ASL 2.0 с некоторыми исключениями (особенно касательно ядра Linux)
Apache httpd (веб-сервер): ASL 2.0
Apache Spark (кластерная вычислительная система): ASL 2.0
Spring Framework (фреймворк для создания корпоративных приложений на Java): ASL 2.0
MIT License
Ещё одна очень популярная лицензия. Возможно, даже самая популярная. Устанавливая совсем немного ограничений на повторное использование, лицензия MIT может быть легко связана с другими лицензиями, будь то GPL или проприетарные лицензии.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой.
Популярные проекты
node.js (среда выполнения для JavaScript): MIT License
jQuery (клиентская библиотека JavaScript): MIT License (до 2012, двойная лицензия MIT/GPL)
Atom (текстовый редактор): MIT License
AngularJS (JavaScript- фреймворк): MIT License
SQLAlchemy (инструментарий SQL и объектно-реляционное отображение для Python): MIT License
Лицензии BSD
Лицензии BSD бывают трёх видов. Оригинальная лицензия «4-х пунктов», «пересмотренная» лицензия, состоящая из 3-х пунктов и «упрощённая» лицензия из 2-х пунктов. По духу все три очень близки к лицензии MIT. И действительно, между упрощенной лицензией BSD и лицензией MIT нет существенных различий.
Лицензии BSD, состоящие из 3-х и 4-х пунктов, содержат больше требований в отношении повторного использования наименований и рекламы. Это полезно учесть, если вы хотите защитить название вашего продукта или марки.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой;
Лицензиаты не могут использовать название продукта или торговую марку оригинального автора для продвижения своей производной работы (лицензии BSD из 3-х и 4-х пунктов);
Лицензиаты обязаны упоминать оригинального автора работы во всех рекламных материалах, ссылающихся на функции или использование этой работы (лицензия BSD из 4-х пунктов).
Популярные проекты
Django (фреймворк для веб-приложений): лицензия BSD из 3-х пунктов
Redis (хранилище данных): лицензия BSD из 3-х пунктов
Ruby (язык программирования): лицензия BSD из 2-х пунктов и кастомная лицензия
Nginx (веб-сервер): лицензия BSD из 2-х пунктов
NetBSD (операционная система): лицензия BSD из 2-х пунктов — лицензия BSD «4-х пунктов» до 2008
В заключение о лицензиях Open Source
Вы дочитали до этого места, поздравляю! Теперь вы понимаете, что лицензирование – это обширная и сложная тема. Но потратить время на то, чтобы выбрать подходящую лицензию для вашего проекта – стоит того, и лучше сделать этот выбор как можно раньше. Это убережёт вас от множества проблем в дальнейшем, и вы сможете направить ваше время и энергию на работу над проектом вместо того, чтобы тратить силы на разборки с авторским правом и юридической совместимостью лицензий.
И помимо нескольких известных лицензий, о которых вкратце рассказано здесь, существует ещё множество других, используемых более или менее широко. Поэтому, не стесняйтесь писать в комментариях о том, какую лицензию вы предпочитаете и почему.