Добавлю что если хорошо вести CHANGELOG.md по мере разработки, заполнение описания релиза на GH сведётся просто к копированию последнего раздела оттуда.
что мой проект внезапно удалили из github просто потому, что так кто-то захотел
Это какая-то страшилка для детей. Просто так проекты не удаляют, а если в вашему проекту могут быть законные претензии, его удалит любой хостинг, а ваш личный сервер заблокируют или его откажется обслуживать хостер.
GitHub же действительно лидер, а скорее даже безальтернативное решение.
Да, добавлю что хоститься [где и как угодно] никто не запрещает, но зеркало на GitHub — must have и лучший способ обеспечить доступность проекта несмотря ни на что.
Напротив, как раз хостить проект на своём сервере — лучший способ его потерять через пару лет, поскольку поддержка будет упираться в одного человека, работающего за бесплатно, т.е. вас. Сервер упадёт — вы этого даже не заметите. Случится что-нибудь, не дай бог, с вами, или просто переедете, сервер сломается, надоест поддерживать, кончатся деньги — проект исчезнет. У меня есть кое-какая статистика с https://repology.org: мёртвых ссылок на хостинги намного меньше чем мертвых ссылок на отдельные домены.
Единственное но: за сборку проекта в дереве исходников надо очень больно бить по рукам
Как собирать проект — личное дело пользователя, по рукам надо бить за неполную поддержку любого из способов (а особенно за запрещение одного из них). В CMake, скажем, можно сломать in-source сборку использованием FILE(GLOB ...), которое подхватит кроме исходников проекта служебные файлы cmake. А out-of-source можно сломать не(правильным) использованием переменных *_SOURCE_DIR и *_BINARY_DIR.
А зачем лицензию читать? Она типовая. Поэтому markdown тут и не нужен — это просто текстовый файл (с gnu.org, например), без изменений. Так и на глаз проще понять что это, например, GPLv3, и автоматическим системам типа fossology проще.
В "злых целях" может использоваться любой проект, независимо от того какой смысл вы в это понятие вкладываете. Так что ради бога, просто вы не даёте никому права использовать ваш код. Гораздо больше разработчиков так делает просто не указав лицензию.
Крайне порочная практика. В простом случае эти приписки просто усложняют понимание лицензии, не неся никакого смысла (потому что угостить пивом разработчиков СПО можно и без beerware), в более сложных софт становится невозможно свободно использовать и распространять.
Первый пример из статьи можно интерпретировать (If you are using FMDB in your project… Let Gus know
by sending an email) как дополнительное требование, что делает как FMDB, так и проекты его использующие и далее по цепочке несвободными. Также там есть отсылка к лицензии MIT, вместо цитирования её полного текста. А в оном, напомню, есть такое условие: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.". Т.е. лицензия требует включать текст который автор сам не включил. Я бы от этого кода держался подальше.
TEQUILA-WARE по ограниченности оставляет позади многие проприетарные EULA.
"The Software shall be used for Good, not Evil" из лицензии JSON трактуется вполне однозначно — как ограничение, что бы там автор не имел в виду. FSF считает её несвободной и несовместимой с GPL.
Остальное упомянутое (beerware, hugware, wtfpl) близко к public domain, с которым, напомню, также есть проблемы в некоторых юрисдикциях (в том числе в России), из-за чего появилась CC0.
Также всё это доставит головной боли мантейнерам пакетов, потому что вместо того чтобы заглянуть в COPYING и просто указать, например, LICENSE=MIT, придётся перечислять разрешения, совместимость, приводить текст лицензии и т.д. И не факт что пакеты потом включат в официальные репозитории — никто не хочет брать на себя риски при использовании кода под непроверенной и расплывчатой лицензией. То же касается и просто использования кода.
Парадоксально, но именно в это выливается попытка относиться к выбору лицензии "с долей юмора". Поэтому намного лучше подойти серьёзно и выбрать чёткую и проверенную лицензию из одобренных OSI.
Даже если бы были хоть какие-то основания доверять стабильности и безопасности кода написанного руками на ассемблере, даже если бы этот код был поддерживаем, даже если бы использование ассемблера давало профит хотя бы по одному параметру по сравнению с тем же C, самое наипервейшее место где пригодился бы такой сервис написанный с оглядкой на экономию ресурсов — это одноплатник на arm или mips'овый роутер. Понятно что здесь любые проекты на ассемблере заканчиваются не начавшись. А что касается ограничений shared хостинга, за те же деньги можно взять VPS, без ограничений по CPU time и процессам.
Печально в этой истории только игнорирование авторских прав и использование закопирайченных ресурсов. Так бы проект вполне мог пополнить ряды СПО игр, можно было причесать репозиторий, портировать на Qt и получить хорошую кросс-платформенную игру, но проекту с ворованными ресурсами ничего этого, увы, не светит.
> мрачные предсказания Нэйтана: «Однажды ИИ посмотрят на нас так же, как мы смотрим на ископаемые скелеты на равнинах Африки. Прямоходящие обезьяны, живущие в пыли, с грубым языком и инструментами, чьё вымирание неизбежно
Почему же мрачные? Если цивилизация машин будет настолько же эффективнее, то туда человечеству и дорога.
> Список пакетов в Debian Stable из всех 3 веток — 57 000
Количество бинарных пакетов сравнивать некорректно, потому что один логический пакет обычно разбивается на несколько бинарных (например, libfoo, libfoo-doc, libfoo-dev, libfoo-dbg), и в каждом дистрибутиве это делается по-своему. Нужно смотреть на исходники пакетов, для Debian это, например:
и там для unstable получится ~25k пакетов, для stable — ~21k (при этом testing/stable можно считать подмножеством unstable).
Я недавно сделал такую вот сравнивалку количества и качества пакетов:
http://beta.repology.org/statistics.html
AUR там, правда, нет, зато есть FreeBSD, Debian, Ubuntu, Gentoo, pkgsrc, OpenBSD, Arch, OpenSUSE, Sisyphus, SlackBuilds, Chocolatey и кое-что ещё, и я стараюсь сравнивать пакеты честно.
Добавлю что если хорошо вести CHANGELOG.md по мере разработки, заполнение описания релиза на GH сведётся просто к копированию последнего раздела оттуда.
Это какая-то страшилка для детей. Просто так проекты не удаляют, а если в вашему проекту могут быть законные претензии, его удалит любой хостинг, а ваш личный сервер заблокируют или его откажется обслуживать хостер.
GitHub же действительно лидер, а скорее даже безальтернативное решение.
Да, добавлю что хоститься [где и как угодно] никто не запрещает, но зеркало на GitHub — must have и лучший способ обеспечить доступность проекта несмотря ни на что.
Напротив, как раз хостить проект на своём сервере — лучший способ его потерять через пару лет, поскольку поддержка будет упираться в одного человека, работающего за бесплатно, т.е. вас. Сервер упадёт — вы этого даже не заметите. Случится что-нибудь, не дай бог, с вами, или просто переедете, сервер сломается, надоест поддерживать, кончатся деньги — проект исчезнет. У меня есть кое-какая статистика с https://repology.org: мёртвых ссылок на хостинги намного меньше чем мертвых ссылок на отдельные домены.
Как собирать проект — личное дело пользователя, по рукам надо бить за неполную поддержку любого из способов (а особенно за запрещение одного из них). В CMake, скажем, можно сломать in-source сборку использованием
FILE(GLOB ...), которое подхватит кроме исходников проекта служебные файлы cmake. А out-of-source можно сломать не(правильным) использованием переменных*_SOURCE_DIRи*_BINARY_DIR.Равно как и "если хотите выложить код не под GPL/LGPL".
А зачем лицензию читать? Она типовая. Поэтому markdown тут и не нужен — это просто текстовый файл (с gnu.org, например), без изменений. Так и на глаз проще понять что это, например, GPLv3, и автоматическим системам типа fossology проще.
Дожили. Обычный трюковой вертолётик уже дроном стал.
В "злых целях" может использоваться любой проект, независимо от того какой смысл вы в это понятие вкладываете. Так что ради бога, просто вы не даёте никому права использовать ваш код. Гораздо больше разработчиков так делает просто не указав лицензию.
Крайне порочная практика. В простом случае эти приписки просто усложняют понимание лицензии, не неся никакого смысла (потому что угостить пивом разработчиков СПО можно и без beerware), в более сложных софт становится невозможно свободно использовать и распространять.
Первый пример из статьи можно интерпретировать (If you are using FMDB in your project… Let Gus know
by sending an email) как дополнительное требование, что делает как FMDB, так и проекты его использующие и далее по цепочке несвободными. Также там есть отсылка к лицензии MIT, вместо цитирования её полного текста. А в оном, напомню, есть такое условие: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.". Т.е. лицензия требует включать текст который автор сам не включил. Я бы от этого кода держался подальше.
TEQUILA-WARE по ограниченности оставляет позади многие проприетарные EULA.
"The Software shall be used for Good, not Evil" из лицензии JSON трактуется вполне однозначно — как ограничение, что бы там автор не имел в виду. FSF считает её несвободной и несовместимой с GPL.
Остальное упомянутое (beerware, hugware, wtfpl) близко к public domain, с которым, напомню, также есть проблемы в некоторых юрисдикциях (в том числе в России), из-за чего появилась CC0.
Также всё это доставит головной боли мантейнерам пакетов, потому что вместо того чтобы заглянуть в COPYING и просто указать, например, LICENSE=MIT, придётся перечислять разрешения, совместимость, приводить текст лицензии и т.д. И не факт что пакеты потом включат в официальные репозитории — никто не хочет брать на себя риски при использовании кода под непроверенной и расплывчатой лицензией. То же касается и просто использования кода.
Парадоксально, но именно в это выливается попытка относиться к выбору лицензии "с долей юмора". Поэтому намного лучше подойти серьёзно и выбрать чёткую и проверенную лицензию из одобренных OSI.
Даже если бы были хоть какие-то основания доверять стабильности и безопасности кода написанного руками на ассемблере, даже если бы этот код был поддерживаем, даже если бы использование ассемблера давало профит хотя бы по одному параметру по сравнению с тем же C, самое наипервейшее место где пригодился бы такой сервис написанный с оглядкой на экономию ресурсов — это одноплатник на arm или mips'овый роутер. Понятно что здесь любые проекты на ассемблере заканчиваются не начавшись. А что касается ограничений shared хостинга, за те же деньги можно взять VPS, без ограничений по CPU time и процессам.
В здоровом обществе не должно быть рекламы.
Там не указана лицензия, а без этого код нельзя даже смотреть.
Печально в этой истории только игнорирование авторских прав и использование закопирайченных ресурсов. Так бы проект вполне мог пополнить ряды СПО игр, можно было причесать репозиторий, портировать на Qt и получить хорошую кросс-платформенную игру, но проекту с ворованными ресурсами ничего этого, увы, не светит.
Почему же мрачные? Если цивилизация машин будет настолько же эффективнее, то туда человечеству и дорога.
Количество бинарных пакетов сравнивать некорректно, потому что один логический пакет обычно разбивается на несколько бинарных (например, libfoo, libfoo-doc, libfoo-dev, libfoo-dbg), и в каждом дистрибутиве это делается по-своему. Нужно смотреть на исходники пакетов, для Debian это, например:
http://ftp.debian.org/debian/dists/{stable,testing,unstable}/{contrib,main,non-free}/source/Sources.gz
и там для unstable получится ~25k пакетов, для stable — ~21k (при этом testing/stable можно считать подмножеством unstable).
Я недавно сделал такую вот сравнивалку количества и качества пакетов:
http://beta.repology.org/statistics.html
AUR там, правда, нет, зато есть FreeBSD, Debian, Ubuntu, Gentoo, pkgsrc, OpenBSD, Arch, OpenSUSE, Sisyphus, SlackBuilds, Chocolatey и кое-что ещё, и я стараюсь сравнивать пакеты честно.