Comments 16
Пора научную конфу запускать
В статье поднимается проблема, решением которой было бы здорово заниматься. Но, к сожалению, в статье, действительно, о проблеме воспроизводимости результатов сказано, лишь, несколько слов. Хотелось бы, чтобы все слова были посвящены этой проблеме.
Воспроизводимость результатов, конечно же, требует некой общей (концептуальной) модели обработки данных и возможности описывать весьма различные подходы, методы и алгоритмы в рамках единой схемы. При этом, надо всегда помнить о том, что за каждым методом и алгоритмом стоят собственные модельные предположения и ограничения, устанавливающие границы их применимости. Соответственно, для автоматизации необходима довольно глубокая формализация. (По идее, именно для такой формализации и нужны модные сейчас языковые модели.)
Далее. У нас отсутствует понятие электронного документа. Если бы всё было бы хорошо формализовано, то пользователь проводил бы свои исследования при помощи определённых программных систем и, при публикации своей работы, автоматически публиковал бы и программный код. На самом деле, у каждого исследования есть своя структура, и различные части программного кода завязаны на определённые элементы данной структуры. Это означает, что каждому пользователю нужен некий общий каркас (framework), в соответствии с которым разворачивается его работа, фиксируются источники данных, выполняются отдельные этапы исследования и формируются отчёты.
А что мы хотим получить на выходе? Мы хотим получить на выходе систему, в которой накапливается и код, и данные, и автоматически строятся соответствия между кодом и данными. Значит, если есть какая-то задача, то появление в системе нового метода будет автоматически приводить к исследованию его применимости к уже имеющимся данным, а так же исследование того, какого вида данные должны использоваться для проверки данного метода.
Помимо формализации (как таковой), здесь имеется фундаментальная проблема: потребность в едином кодовом пространстве. Другими словами, нужен какой-то единый язык (или метаязык) программирования, на котором (после соответствующего преобразования) выражаются все алгоритмы.
Короче. Всё это — задачи для внушительных размеров НИИ!
публиковать лонгриды про научный опенсорс
С какой лицензией вы распространяете эти статьи? По какой лицензии можно использовать их в открытой науке?
Те что на Хабре - под его обычной лицензией, не вполне уверен как она в международных терминах называется. Вроде бы переиспользование текста с указанием авторства она разрешает.
Текстовые материалы в наших репозиториях (например, https://github.com/aimclub/open-source-ops) - под BSD-3.
под его обычной лицензией,
Обычная лицензия Хабра не существует. Хабр не разрешает свободно использовать размещённые здесь произведения другими коммерческими предприятиями, потому что не имеет таких прав. Права на размещённые здесь произведения принадлежат авторам.
Поэтому вопрос каждый раз решает именно автор статьи.
Если вы предлагаете эту лицензию по BSD-3-Clause, то возникает проблема с третьим пунктом. По сути пункта — нельзя использовать название ИТМО, распространяя производные статьи. Таким образом, лицензия содержит внутреннее противоречие, которое затрудняет использование этой лицензии для текстов и изображений.
Насчет лицензии текстов на хабре - опираюсь на текст пользовательского соглашения про "принимая условия настоящего Соглашения, Пользователь безвозмездно предоставляет Хабру простую (неисключительную) лицензию на использование Контента "
Третий пункт BSD-3-Clause - он вроде про "software". Мне для текстов такого рода оптимальной является CC-BY, но не эксперт в вопросе не-кодовых лицензий, хорошо если кто-то более знающих выскажется.
Вы совершенно правы! Пользователь предоставляет Хабру.
А что предоставляет пользователь неограниченному кругу юридических и физических лиц? Ничего.
Третий пункт говорит про products derived. Хотя там действительно сказано software, однако если лицензировать текст по этой лицензии, тогда надо (по аналогии) читать там content. И получается, что производные произведения нельзя выхвалять, указывая на имя первичного автора. Это как если бы Маршак, переводя Бёрнса, не имел права рекламировать их как стихи Бёрнса. Вот здесь-то и получается противоречие.
Сейчас, небольшим организациям практически невозможно защитить свои интеллектуальные права и практически невозможно отследить как используются наработки проекта, код которого открыли.
И никто, конечно не будет покупать лицензию на код который скачан на гитхабе.
Надёжно защитить свои права на код, могут только гиганты отрасли.
Если будет отечественная лицензия надёжно защищающая разработчиков проектов с открытым кодом, не БСД-3(1,2,8), а ЛОК-РФ-1 (лицензия проектов с открытым кодом российской федерации, условия первые), ситуация в проектах с открытым кодом может быть изменится.
Отдельно отмечу что в журнале Scince, авторы не всегда публикуют весь ход исследования и все свои расчёты и условия экспериментов.
Надёжно защитить свои права на код, могут только гиганты отрасли.
Это вы про какой случай говорите?
Про случай, когда все могут бесплатно скачать их код с гитхаба или с их сайта?
Или про случай, когда гигант отрасли нарушил лицензию GNU и спокойно живёт, потому что никто не смеет судиться с ним?
Отследить что решение используется в коммерческих целях и нарушает авторские права под силу только гигантам.
В РФ лицензия GNU и BSD не имеют законной силы потому, что это амерской юрисдикции.
Microsoft EULA тоже относится к американской юрисдикции. Почему же российские суды считают эту лицензию действительной? Тут в ваших словах есть некая зыбкость...
Деньги на опенсорс дают неохотно.
Вы пишете, что люди не хотят платить за создание опенсорса. Однако эта задача решается с другой стороны.
Люди хотят платить за избавление от своих проблем. Поэтому решение выглядит так.
Исполнитель обещает избавить заказчика от проблемы.
Исполнитель предлагает заказчику свободное решение (опенсорс).
Заказчик видит, что решение получает не только он один, а все лица, и уменьшает оплату.
Здесь очень важно не смешивать условия решения задачи (опенсорс) и само решение задачи. Если задача нужна заказчику, он заплатит за решение. Если задача не нужна заказчику, тогда метод её решения (опенсорс) не прибавит нужности.
Опенсорс это продукт который разрабатывался в рамках коммерческого продукта, но потом приняли решение сделать его открытым для некоммерческих целей. Полностью или частично.
Опенсорс это программа, текст которой вы можете получить. Она может быть и коммерческой, и некоммерческой, и какой угодно ещё.
Известны случаи, когда программа была коммерческой, потом перестала продаваться, потом создатель опубликовал её исходный текст и дал разрешение на использование этого исходного текста по свободной лицензии.
Почему мы топим за открытый код в науке ― несколько слов о воспроизводимости результатов научных исследований