или так https://choosealicense.com/

я не умаляю ваше желание, я к тому, что материалов на эту тему уже прилично

Эта статья содержит обзор на основные open source лицензии. Наше исследование преследует немного иные цели. Для начала, мы пытаемся понять, есть ли проблема в использовании open source в принципе, если есть - какие сложности возникают у разработчиков, почему они могут отказаться от использования open source и др. Пока, например, по результатам опроса лидирует мнение, что условия часто бывают непонятны, но на это не обращают внимания и используют open source несмотря на нарушение.

Мы готовим материал с целью рассказать про более тонкие и сложные вопросы, связанные с open source лицензиями - толкование отдельных положений, вирусность GPL, импортозамещение, юрисдикция и др. Акцент будет сделан на правовых аспектах - как безопасно использовать открытый код в России и других юрисдикциях, чтобы через 6 лет к тебе не пришла компания {X}ambler :) И все эти сложные правовые вопросы мы пытаемся объяснить простыми словами. Целевая аудитория проекта - разработчики, менеджеры по продажам, владельцы бизнеса - должны понимать особенности использования open source, представлять себе возможные риски и быть готовыми к защите своих прав при необходимости (в дальнейшем планируем уделить внимание возможности структурирования сделок с ПО по иностранному праву и переноса споров в зарубежные юрисдикции, что может быть очень актуально). Потому что на самом деле все немного сложнее, чем кажется.

Мы начали работу над исследованием потому что к нам поступает очень много вопросов по open source от ИТ-специалистов и мы решили собрать все вместе и сделать полезный материал. Но может быть это не для всех актуально :)

Thx

Коллеги, а поясните плиз,
почему историю с nginx как-то рассматривают в ключе «как у нас с open source» («Open source наше всё» и так далее).
Если б нгинкс был не оупен сорс, всё было бы иначе?
В юридическом плане, конечно (то есть без «я люблю нгинкс только потому что он бесплатный»)

По-моему, основная загвоздка в том, что это типа сторонний проект во время основной работы. И теперь эта «основная работа» (ну не она сама, но не важно) претендует на тот сторонний проект. Open или не open — здесь роли не играет.

Нет?

(вопрос не только к Сергею, просто к слову к его сообщению)

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

Это конечно.
Ну а open source здесь не причём, правильно?

Просто нам дополнительно симпатичен nginx и Сысоев, потому что это open source, но правила вроде должны быть беспристрастны

Open source тут при том, что большáя часть кода была написана за пределами Рамблера

Привет!
Интересует следующий вопрос: в одном департаменте несколько продуктовых команд (product+dev+qa). Подскажите, у кого схожая ситуация, как у вас: DevOps внутри команды или шаренные ресурсы на департамент?
Продукты сильно разные как по стеку, так и по релизному циклу

В моей компании к сожалению девопс это вылеленный ресурс. Что в корне неверно. А современном мире деплой и архитектура софта очень переплетены. Поэтому девопс должен быть внутри команды. Жить кодом и участвовать вместе с дев/тех лидом в проработке архитектуры и того как это будет деплоится, обновлятся и тд. Особенно если речь идет о SAAS решениях

Внутри команды, но чужой

Что значит чужой?

Внутри команды. Пробовали внешнего общий на несколько команд devops - очень плохо. Внешний выделенный - плохо. Проблемы с коммуникацией и вовлеченностью.

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

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

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

Для начала расскажите что вы вкладываете в понятие DevOps :)

Сейчас слишком много всего этим словом называют