Комментарии 36
А есть простая блок-схема, как выбрать лицензию? Описания обычно слишком сложные, чтобы понять разницу.
Вот тут есть более доступные для понимания описания.
«Вздумали выложить кусок текста программы? А у вас есть лицензия?» без слез не взглянешь. Примотай текст «я разрешаю, не разрешаю, запрещаю» и сразу не смогут раздербанить прогу на строчки? или взять куском, наплевав на все «лицензии»? Лицензиями и открытыми кодами балуются, в основном, те, кому терять нечего. Вместо написания своего кода они набирают из готовых проектов кусками код, лепят из него Франкенштейна, потом выкладывают его в открытую, и уже другие из него чего то свое лепят. Получается круговорот бесплатного открытого кода в среде ленивых псевдокодеров.
https://habrahabr.ru/post/118457/ — Наглядно о популярных Open Source лицензиях
НЛО прилетело и опубликовало эту надпись здесь
Почему? Есть 4 материальных мотива выкладывать код в опенсорс (не будет упоминать хобби и самовыражение):
- Популярный опенсорс высоко ценится работодателями на Западе -> выше зар.плата -> профит,
- Опенсорс даёт возможность сэкономить на разработке, скажем всю экосистему Нadoop и ему подобных в одиночку даже гугл нормально развивать не сможет, см. Нadoop, Spark и т.п.,
- Вы делаете бизнес на поддержки опенсорс см RedHat и ему подобные компании,
- Вы выкладывайте урезанную версию в опенсорс, а полную версию продаёте за деньги, см Idea
Ну если ты делаешь действительно важную вещь — то бывает такое, что люди сами находят твой проект на том-же GitHub. По описанию простому.
НЛО прилетело и опубликовало эту надпись здесь
Если проект достаточно объёмный, то это реальный шанс привлечь помощников.
реальный шанс привлечь помощников — это нанять команду, а забесплатно — это только шанс привлечь школьников, у которых есть свободное время чтобы заниматься всякой фигней) а потом они еще и растащат ваш проект на куски себе и будет он как труп всплывать: то там рука от него показалась, то тут нога, вроде бы все ваше, но уже без всяких там лицензий, тупо украдено.
http://lionet.livejournal.com/31952.html
По поводу пункта «Документация».
Я бы предложил первым пунктом в документации указать какая у программы самая главная функция, ради чего она писалась и почему пользователь должен выбрать вашу программу именно за «это», этакий вау-эффект, а инструкция по установке уже вторым пунктом. Это надо писать не только на сайте самой программы (если таковой вообще есть), а по возможности в нескольких местах. Я так не один проект открыл и закрыл (не зацепило или сходу не разобрался, в то время как соседи по выборке предлагали более внятное объяснение).
Для примера, на сайте microsoft ооочень много плохой документации. Дофига описания как установить, но нет никакой возможности понять, а что я получу в результате настройки или установки? Не стоит надеяться на «опыт» пользователя, что он всё правильно себе представит.
Если программа зацепила, то какая бы «странная» не была установка — есть мотивация её осилить.
Я бы предложил первым пунктом в документации указать какая у программы самая главная функция, ради чего она писалась и почему пользователь должен выбрать вашу программу именно за «это», этакий вау-эффект, а инструкция по установке уже вторым пунктом. Это надо писать не только на сайте самой программы (если таковой вообще есть), а по возможности в нескольких местах. Я так не один проект открыл и закрыл (не зацепило или сходу не разобрался, в то время как соседи по выборке предлагали более внятное объяснение).
Для примера, на сайте microsoft ооочень много плохой документации. Дофига описания как установить, но нет никакой возможности понять, а что я получу в результате настройки или установки? Не стоит надеяться на «опыт» пользователя, что он всё правильно себе представит.
Если программа зацепила, то какая бы «странная» не была установка — есть мотивация её осилить.
Из-за раздела "разработка" ожидал увидеть что-то вроде:
Что нужно сделать перед тем, как выложить код открытого программного обеспечения?
A вот что:
git commit -am "new feature"
git push
git pull-request [-f] [TITLE|-i ISSUE|ISSUE-URL] [-b BASE] [-h HEAD]
Никто никому ничего не должен. Вот по моему мнению девиз ОС-движения.
А что там, кстати, с правом собственности. Вот, допустим, у меня есть одна библиотека, которую я мало-мало продаю заказчикам. Если ее выложить в опенсорс, то я смогу после этого легально продавать "свой" софт с коммитами посторонних людей, или он уже "не мой" после этого будет?
Зависит от лицензии под которой исходный код был выложен. Код «посторонних» коммитов, присоединится к данной лицензии.
BSD(или аналог) не мешает продавать. GPL(или аналог) потребует выложить исходники продаваемого продукта.
BSD(или аналог) не мешает продавать. GPL(или аналог) потребует выложить исходники продаваемого продукта.
Если заранее позаботитесь, то сможете. Оракл, вон, продает MySQL и не жужжит. Потому что каждый посторонний человек соглашается на OCA (Oracle Contributor Agreement). А вот OpenSSL не озаботился когда-то таким. И теперь они гоняются за каждым, кто когда-либо что-либо в них коммиттил и просят согласится на перемену лицензии. Вместо Contributor Agreement можно просить, чтобы коммиты были под BSD или еще какой-нибудь «мягкой» лицензией.
Короче, «ваш» будет код или «не ваш» зависит от лицензии на эти коммиты посторонних людей. Если только принимать коммиты под правильной лицензией — то «ваш» и останется.
Короче, «ваш» будет код или «не ваш» зависит от лицензии на эти коммиты посторонних людей. Если только принимать коммиты под правильной лицензией — то «ваш» и останется.
Вместо Contributor Agreement можно просить, чтобы коммиты были под BSD или еще какой-нибудь «мягкой» лицензией.
«ваш» будет код или «не ваш» зависит от лицензии на эти коммиты посторонних людей. Если только принимать коммиты под правильной лицензией — то «ваш» и останется.
Хотя с точки зрения продажи конечного продукта это не принципиально, сами по себе BSD и близкие лицензии не передают код в чье-то владение, копирайт на комиты так и остается за изначальным их автором.
Спасибо за перевод, полезная информация! Ну, и раз тут такая тема — рискну задать наболевшие вопросы…
Не было у кого-нибудь опыта старта фан-проекта сразу с небольшой командой?.. Подскажите: как вы решали конфликты при проектировании базового каркаса приложения? Не было ли проблем с пониманием друг друга в условиях не установившейся терминологии? Ну и ещё вопрос (скорее, психологического характера)… Как сломать внутренний барьер и начать доверять людям написание части своего, кровного проекта?
Был бы очень благодарен за любые советы! Надеюсь, не только я сталкивался с описанными проблемами.
Не было у кого-нибудь опыта старта фан-проекта сразу с небольшой командой?.. Подскажите: как вы решали конфликты при проектировании базового каркаса приложения? Не было ли проблем с пониманием друг друга в условиях не установившейся терминологии? Ну и ещё вопрос (скорее, психологического характера)… Как сломать внутренний барьер и начать доверять людям написание части своего, кровного проекта?
Откуда возникли вопросы
Мы начали небольшой командой делать библиотечку, и уже в первую неделю случилось так, что вроде обсудили всё по три раза, поняли друг друга в деталях… А люди коммитили — и оказывалось, что у нас на самом деле были разные взгляды на вещи, я начинал нехорошие споры (типа, как надо и как не надо писать код), как инициатор проекта тянул одеяло на себя и в результате вообще взялся всё переписывать сам…
В общем, обнаружил, что это не так-то просто доверять людям писать код, пока не устаканился стабильный каркас приложения. Хочется, с одной стороны, заложить максимально правильное (как я его вижу) направление развития, а с другой — сделать так, чтобы люди вносили что-то своё в проект, обсуждать с ними как-нибудь, чтобы не выходило так, что я один у руля стою, а остальные так, на позиции подающих.
Понять бы как забороть этих внутренних демонов и организовать разумное и продуктивное взаимодействие в команде.
В общем, обнаружил, что это не так-то просто доверять людям писать код, пока не устаканился стабильный каркас приложения. Хочется, с одной стороны, заложить максимально правильное (как я его вижу) направление развития, а с другой — сделать так, чтобы люди вносили что-то своё в проект, обсуждать с ними как-нибудь, чтобы не выходило так, что я один у руля стою, а остальные так, на позиции подающих.
Понять бы как забороть этих внутренних демонов и организовать разумное и продуктивное взаимодействие в команде.
Был бы очень благодарен за любые советы! Надеюсь, не только я сталкивался с описанными проблемами.
А это смотря какая ваша конечная цель.
Если целью является написание кода, отвечающего вашему чувству прекрасного, и дальнейшее самоудовлетворение, через его созерцание, то проще всего начинать писать все самому, а затем, когда уже фундамент будет заложен, искать тех, кто разделяет ваши идеи. Но не факт, что найдете. Зависит от строгости ваших требований. Написание такого кода — цель благородная, но труднодостижимая.
Если же цель — написание библиотеки для практического использования, то надо просто составить «на бумаге» четкое ТЗ. Без фанатизма конечно, но достаточно подробное. И договориться о Code Style. Тоже описать его «на бумаге». В принципе, для библиотеки самое главное — сохранить единообразие API. Вообще, на этапе становления, самые жесткие требования надо предъявлять к публичному программному интерфейсу, а как сам код внутри написан — дело десятое. Это же первая версия, нужно сначала сделать ее и оценить. нужно ли оно вообще, и должно ли быть сделано именно так. А уж потом, код можно рефакторить и оптимизировать хоть до посинения. Рефакторинг, его ведь вообще невозможно закончить, его можно только прекратить.
З.Ы. опенсорс пока не писал, все вышесказанное, взято из опыта программирования вообще. Не раз приходилось писать системообразующее ПО и библиотеки, которые потом использовались другими программистами.
Если целью является написание кода, отвечающего вашему чувству прекрасного, и дальнейшее самоудовлетворение, через его созерцание, то проще всего начинать писать все самому, а затем, когда уже фундамент будет заложен, искать тех, кто разделяет ваши идеи. Но не факт, что найдете. Зависит от строгости ваших требований. Написание такого кода — цель благородная, но труднодостижимая.
Если же цель — написание библиотеки для практического использования, то надо просто составить «на бумаге» четкое ТЗ. Без фанатизма конечно, но достаточно подробное. И договориться о Code Style. Тоже описать его «на бумаге». В принципе, для библиотеки самое главное — сохранить единообразие API. Вообще, на этапе становления, самые жесткие требования надо предъявлять к публичному программному интерфейсу, а как сам код внутри написан — дело десятое. Это же первая версия, нужно сначала сделать ее и оценить. нужно ли оно вообще, и должно ли быть сделано именно так. А уж потом, код можно рефакторить и оптимизировать хоть до посинения. Рефакторинг, его ведь вообще невозможно закончить, его можно только прекратить.
З.Ы. опенсорс пока не писал, все вышесказанное, взято из опыта программирования вообще. Не раз приходилось писать системообразующее ПО и библиотеки, которые потом использовались другими программистами.
Спасибо за ответ! Не сказать что он полностью дал решение проблемы, но он в чём-то дополнил мои мысли и натолкнул на некоторые дополнительные размышления.
Вот о чём подумал… Вопрос состоял в том, как добиться формированию единообразия API и того, как добиться общих взглядов на организацию API внутри команды. После первого провала менеджмента проекта с моей стороны (не проверил насколько люди поняли основные идеи проекта после обсуждений), я выбрал авторитарный стиль: взял и сформировал API по-своему, после чего рассказал написанное по по-своему API, выслушал их замечания.
Плюсы авторитарного стиля: В более или менее сжатые сроки получилось создать базовое API, от которого можно развивать библиотеку.
Минусы авторитарного стиля: Отсутствие параллелизма в решении задач и демотивация участников команды, которые чувствуют себя отстранёнными от развития библиотеки.
Теперь по поводу мыслей после вашего комментария… Осознал, что, пожалуй, в принципе не возможно распараллелить такую задачу, как построение базовой архитектуры программы. И действительно, лучший вариант — предложить коллегам по проекту поучаствовать в активном обсуждении того, что будет писаться, но акцентировать внимание на том, что код в будешь писать ты сам. При этом, конечно, не стоит закрывать возможность критики и формировать базовое API микрокоммитами, чтобы по мере реализации проговоренного на словах можно обсуждать те или иные решения. При этом также желательно как можно скорее реализовать API. Пусть самым примитивным образом — главное чтобы коллеги по проекту не заскучали и не почувствовали свои права в проекте ущемлёнными.
И вот когда базовое API будет готово и будут сформулированы общие принципы работы — стоит сразу начать параллелить задачи и разделять области ответственности между участниками проекта… Ну, и тут уже легче будет терпеть чужие изменения в проекте — они будут жить за интерфейсом, задаваемым API. Изменения эти легко осмысляются численными метриками (расход памяти, быстродействие, и т.д.), а не такими абстрактными штуками как «красота кода» или «разумность дизайна»
Вот о чём подумал… Вопрос состоял в том, как добиться формированию единообразия API и того, как добиться общих взглядов на организацию API внутри команды. После первого провала менеджмента проекта с моей стороны (не проверил насколько люди поняли основные идеи проекта после обсуждений), я выбрал авторитарный стиль: взял и сформировал API по-своему, после чего рассказал написанное по по-своему API, выслушал их замечания.
Плюсы авторитарного стиля: В более или менее сжатые сроки получилось создать базовое API, от которого можно развивать библиотеку.
Минусы авторитарного стиля: Отсутствие параллелизма в решении задач и демотивация участников команды, которые чувствуют себя отстранёнными от развития библиотеки.
Теперь по поводу мыслей после вашего комментария… Осознал, что, пожалуй, в принципе не возможно распараллелить такую задачу, как построение базовой архитектуры программы. И действительно, лучший вариант — предложить коллегам по проекту поучаствовать в активном обсуждении того, что будет писаться, но акцентировать внимание на том, что код в будешь писать ты сам. При этом, конечно, не стоит закрывать возможность критики и формировать базовое API микрокоммитами, чтобы по мере реализации проговоренного на словах можно обсуждать те или иные решения. При этом также желательно как можно скорее реализовать API. Пусть самым примитивным образом — главное чтобы коллеги по проекту не заскучали и не почувствовали свои права в проекте ущемлёнными.
И вот когда базовое API будет готово и будут сформулированы общие принципы работы — стоит сразу начать параллелить задачи и разделять области ответственности между участниками проекта… Ну, и тут уже легче будет терпеть чужие изменения в проекте — они будут жить за интерфейсом, задаваемым API. Изменения эти легко осмысляются численными метриками (расход памяти, быстродействие, и т.д.), а не такими абстрактными штуками как «красота кода» или «разумность дизайна»
Качественный Open Souce несущий пользу для бизнеса или клиентов является нематериальным активом по всем признакам.
В России физическое лицо не может иметь нематериальные активы, но могут иметь авторское право на ПО. По закону об авторском праве лицензии прилагаемые к Open Souce не имеют силы, имеет силу факт доказывания авторства через суд.
ИП и ООО имеют нематериальные активы вместо авторского права, которые являются более значимым ресурсом в силу нашего менталитета. Опять же, лицензия не является доказательством чего либо. Есть тот же закон об авторском праве, который первостепенен. Есть патентное бюро, где можно официально зарегистрировать программу.
Интересно, что если физ лицо работает на компанию по трудовому договору, то иногда там есть пункт об авторском праве, который подразумевает переход всех авторских прав на которые может претендовать компания в собственность компании. Тогда Open Source выложенный физ лицом, который хоть как то пересекается с основной деятельностью физ лица является собственностью компании.
В России физическое лицо не может иметь нематериальные активы, но могут иметь авторское право на ПО. По закону об авторском праве лицензии прилагаемые к Open Souce не имеют силы, имеет силу факт доказывания авторства через суд.
ИП и ООО имеют нематериальные активы вместо авторского права, которые являются более значимым ресурсом в силу нашего менталитета. Опять же, лицензия не является доказательством чего либо. Есть тот же закон об авторском праве, который первостепенен. Есть патентное бюро, где можно официально зарегистрировать программу.
Интересно, что если физ лицо работает на компанию по трудовому договору, то иногда там есть пункт об авторском праве, который подразумевает переход всех авторских прав на которые может претендовать компания в собственность компании. Тогда Open Source выложенный физ лицом, который хоть как то пересекается с основной деятельностью физ лица является собственностью компании.
> По закону об авторском праве лицензии прилагаемые к Open Souce не имеют силы
На столько не имеют, что о них даже отдельная статья в ГК РФ имеется: «Статья 1286.1. Открытая лицензия на использование произведения науки, литературы или искусства». И да, к программам для ЭВМ она тоже относится, так как они у нас охраняются как литературные произведения, да и в самой статье есть отдельная сноска про программы и базы данных.
> имеет силу факт доказывания авторства через суд
Имущественные и не имущественные авторские права в России возникают в момент создания произведения и не требуют отдельной процедуры регистрации или утверждения.
> то иногда там есть пункт об авторском праве, который подразумевает переход всех авторских прав на которые может претендовать компания в собственность компании
В России трудовой договор НЕ распространяется на нерабочее время. По этому у себя дома сотрудник может писать любой опенсурс в любой области деятельности. Проблемы возникнут только если сотрудник использует интеллектуальную или другую собственность работодателя.
А вот в США, например, это законная и часто используемая практика.
На столько не имеют, что о них даже отдельная статья в ГК РФ имеется: «Статья 1286.1. Открытая лицензия на использование произведения науки, литературы или искусства». И да, к программам для ЭВМ она тоже относится, так как они у нас охраняются как литературные произведения, да и в самой статье есть отдельная сноска про программы и базы данных.
> имеет силу факт доказывания авторства через суд
Имущественные и не имущественные авторские права в России возникают в момент создания произведения и не требуют отдельной процедуры регистрации или утверждения.
> то иногда там есть пункт об авторском праве, который подразумевает переход всех авторских прав на которые может претендовать компания в собственность компании
В России трудовой договор НЕ распространяется на нерабочее время. По этому у себя дома сотрудник может писать любой опенсурс в любой области деятельности. Проблемы возникнут только если сотрудник использует интеллектуальную или другую собственность работодателя.
А вот в США, например, это законная и часто используемая практика.
Выходить с oss проектом очень тяжело. Ладно ещё когда проект не осень популярный — можно и одному справляться в свободное время, а вот когда проект становиться интересным сообществу, тогда и начинаются настоящие проблемы.
Юзеры очень часто недовольны и плохо читают документацию или вообще не читают, issues в несколько раз больше чем pull request'ов, а простой минорный роадмап может нехило так вздуться из-за багрепортов причём частенько весьма и весьма посредственных, которые, опять же, некому исправлять.
История с neovim'ом довольно показательна в этом плане. Так что oss это такая странная штука — делаешь добро, а по большей части получаешь негативный фидбек в ответ и чем популярнее проект, тем больше негатива читать и разбираться.
Юзеры очень часто недовольны и плохо читают документацию или вообще не читают, issues в несколько раз больше чем pull request'ов, а простой минорный роадмап может нехило так вздуться из-за багрепортов причём частенько весьма и весьма посредственных, которые, опять же, некому исправлять.
История с neovim'ом довольно показательна в этом плане. Так что oss это такая странная штука — делаешь добро, а по большей части получаешь негативный фидбек в ответ и чем популярнее проект, тем больше негатива читать и разбираться.
Эта лицензия одобрена OSI/FSF?
Некоторые лицензии могут выглядеть так, как будто они подходят для лицензирования программного обеспечения с открытым исходным кодом. Но они не имеют такого права. Проверьте список лицензий, одобренных OSI и FSF.
Вообще говоря с точки зрения (истинного гика/настоящего линуксоида/программиста-пофигиста/сторонника открытого ПО/патлатого чувака с фотки/гражданского кодекса) совершенно монопенисуально, одобрена или не одобрена кем-то там твоя лицензия. Можно использовать готовую, можно написать «мне всё пофиг, пользуйтесь как хотите».
> «мне всё пофиг, пользуйтесь как хотите»
Такой подход может сильно помешать использованию кода людьми, которые не хотят нарушать закон.
Такой подход может сильно помешать использованию кода людьми, которые не хотят нарушать закон.
Почему?
Потому что очень размытое заявление (в таком виде выглядит очень похоже на много кем критикуемую WTFPL), действительность которого для законодательств разных стран сомнительна. И, как я понимаю, в качестве бонуса на тебя могут подать в суд за ущерб, нанесенный твоим ПО (потому что не проговаривается отказ от ответственности блаблабла), или насчет патентов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нужно сделать перед тем, как выложить код открытого программного обеспечения