ПЕРЕПИСЫВАЯ код с опорой на образец, не учитывая лицензию, вы нарушаете. Потому, что генерируете производное произведение.
На практике здесь многое зависит от конкретной юрисдикции, конкретной ситуации и даже судей. Но в целом, признаки derivative work не означают автоматического нарушения копирайта. Например Transformative use, куда подпадает цитирование, пародии, использование в новом контексте и т.п. Естественно, создавая свое вы будете в курсе про образец.
Использование произведений в составе датасетов для обучения AI все ещё под вопросом. Защитники пока ссылаются как раз на transformative use. Но все идёт к тому, что его разрешат явно.
когда свободный код используется для обучения нейросетей, не наследуя липкой свободной лицензии copyleft в производном коде. А это нарушение самой идеи.
Такая возможность была всегда - переписать код другими словами. Использовать обфускатор на худой конец. Нейросети лишь добавили автоматизации в это процесс, которая делает его на порядок дешевле, оставляя результат человекопонятным.
Если сгенерированный кусок кода вдруг окажется точь-в-точь похожим на чей-то, то инструменты композиционного анализа отловят проблему.
Почему не pre-commit, если нужно проверять только измененные файлы? Для Ruff есть готовый хук https://docs.astral.sh/ruff/usage/. В принципе, там аналогично решаются вопросы и с остальными линтерами.
Вообще мне нравится такая подача материала. В начале автор с абсолютно детской наивность рассказывает про эксперимент, как бы случайно пришедший ему в голову. Но когда количество сошедшихся случайностей начинает превосходить все разумные вероятности: конкретные вещества, оптимальные пропорции, температура, и т.п. - как бы невзначай появляются ссылки на случайные научные диссертации каких-то случайных людей.
€20 тысяч на то, чтобы 30 цифровых кочевников со всего мира смогли бесплатно жить целых три месяца
Ух ты, по €7.5 в день на кочевника? Видимо жить они будут в своих кибитках, умываться утренней росой и питаться молоком кобылиц.
Казахстан тоже молодцы: приезжайте - условия расскажем, потом. Но если по факту компенсируют больше итальянцев, то значит - переплатили (или я не понимаю зачем эти две новости в одном тексте)?
Думаю, что у каждого своё понимание зачем он программирует. Соседство Run и Business в статье скорее всего говорит об изначально рациональных мотивах автора. Это достойно уважения на самом деле.
Для меня программирование это игра. Как играть на гитаре, например, или в шахматы. На кухне, в парке, в пабе - какая разница? Это не спорт и не бизнес. Критерии оценки результата в первую очередь основаны на внутреннем ощущении удовольствия, красоты и достаточности (здесь я говорю о личных мотивах, а не формальных quality attributes, которые зависят от целей конкретного проекта). На работе я это делаю за деньги, решая бизнес задачи, чтобы кормить свою семью и давать возможность колллегам делать то же самое. Но по большому счету эта суета тут за скобками.
Microsoft умеет в корпоративном сегменте и не умеет в масмаркете. Apple делает софт чисто под своё железо и за счёт этого хорошо экономит. Google выложили половину Android в опенсорс, и теперь силами китайцев запускаются даже на кофеварках. Microsoft первое не могли себе позволить, а второе - не захотели. Windows CE оказался конфеткой и лицензии по началу разлетались как пирожки. Спустя короткое время они получили зоопарк желёза и заморочки с поддержкой, которая ни в какой бюджет.
Ну строго говоря типы учить как то особо не надо. Просто используешь их и все.
Ну вообще вы наверное правы, хотя проблем на самом деле хватает даже в python https://github.com/python/typing/issues. Т.е на практике интуитивно понятные вещи здесь довольно быстро заканчиваются.
На одной типизации все равно до конца не доедешь - рано или поздно придётся расставлять костыли и писать тесты. Потому, что в пределе логика упирается в Теорему Гёделя о неполноте: любая формальная система либо неполна, либо противоречива. На практике лучше иметь дело с неполнотой. Это значит, что какие-то утверждения во всякой непротиворечивой системе типов будут невыводимыми.
В теории СУБД выбирается под модель данных, когда становится понятно, что за данные и какие запросы. Но на практике нередко приходится подстраиваться под ограничения существующей инфраструктуры.
Где описывать типы это вопрос синтаксиса на самом деле. Долгое время в python для этого использовали docstrings и комментарии. Потом добавили отдельную нотацию. Но сам питон туда практически не смотрит. То есть вы можете указывать какие угодно типы и на работоспособность программы это ни как не влияет.
где я просто не понимаю, что принимает данная функция
Вообще есть ещё два варианта: заглянуть в документацию или подсмотреть в реализацию функции. Проекты на динамических языках без документации почти бесполезны. Ну и отчасти поэтому мощность языков разметки документации там зачастую сопоставима с возможностями основного языка.
Различают идеи и реализацию (https://en.m.wikipedia.org/wiki/Idea–expression_distinction). Копирайты распространяются только на реализации идей. Сами идеи защищаются патентами или торговыми марками.
Назовись книгой лиц и в список внесут сами.
Тогда статью придётся скрыть ещё на 23 года, судя по дате на картине.
На практике здесь многое зависит от конкретной юрисдикции, конкретной ситуации и даже судей. Но в целом, признаки derivative work не означают автоматического нарушения копирайта. Например Transformative use, куда подпадает цитирование, пародии, использование в новом контексте и т.п. Естественно, создавая свое вы будете в курсе про образец.
Использование произведений в составе датасетов для обучения AI все ещё под вопросом. Защитники пока ссылаются как раз на transformative use. Но все идёт к тому, что его разрешат явно.
Такая возможность была всегда - переписать код другими словами. Использовать обфускатор на худой конец. Нейросети лишь добавили автоматизации в это процесс, которая делает его на порядок дешевле, оставляя результат человекопонятным.
Если сгенерированный кусок кода вдруг окажется точь-в-точь похожим на чей-то, то инструменты композиционного анализа отловят проблему.
PR с лексикой на грани фола, как будто больше выделиться не чем.
Почему не pre-commit, если нужно проверять только измененные файлы? Для Ruff есть готовый хук https://docs.astral.sh/ruff/usage/. В принципе, там аналогично решаются вопросы и с остальными линтерами.
Докстринги выглядят как результат автоперевода с русского на английский. В принципе в этом нет ни чего такого, автор же не нейтив спикер.
Кодинг из искусства превратили в энтерпрайзное болото. Когда-то люди программировали just for fun и исходники было читать интересно.
На всякий случай, есть одноименная sys.exit(), которой эти ограничения не касаются. Автор благоразумно пропустил импорты в тексте.
Вообще мне нравится такая подача материала. В начале автор с абсолютно детской наивность рассказывает про эксперимент, как бы случайно пришедший ему в голову. Но когда количество сошедшихся случайностей начинает превосходить все разумные вероятности: конкретные вещества, оптимальные пропорции, температура, и т.п. - как бы невзначай появляются ссылки на случайные научные диссертации каких-то случайных людей.
Ух ты, по €7.5 в день на кочевника? Видимо жить они будут в своих кибитках, умываться утренней росой и питаться молоком кобылиц.
Казахстан тоже молодцы: приезжайте - условия расскажем, потом. Но если по факту компенсируют больше итальянцев, то значит - переплатили (или я не понимаю зачем эти две новости в одном тексте)?
Думаю, что у каждого своё понимание зачем он программирует. Соседство Run и Business в статье скорее всего говорит об изначально рациональных мотивах автора. Это достойно уважения на самом деле.
Для меня программирование это игра. Как играть на гитаре, например, или в шахматы. На кухне, в парке, в пабе - какая разница? Это не спорт и не бизнес. Критерии оценки результата в первую очередь основаны на внутреннем ощущении удовольствия, красоты и достаточности (здесь я говорю о личных мотивах, а не формальных quality attributes, которые зависят от целей конкретного проекта). На работе я это делаю за деньги, решая бизнес задачи, чтобы кормить свою семью и давать возможность колллегам делать то же самое. Но по большому счету эта суета тут за скобками.
Microsoft умеет в корпоративном сегменте и не умеет в масмаркете. Apple делает софт чисто под своё железо и за счёт этого хорошо экономит. Google выложили половину Android в опенсорс, и теперь силами китайцев запускаются даже на кофеварках. Microsoft первое не могли себе позволить, а второе - не захотели. Windows CE оказался конфеткой и лицензии по началу разлетались как пирожки. Спустя короткое время они получили зоопарк желёза и заморочки с поддержкой, которая ни в какой бюджет.
Ну вообще вы наверное правы, хотя проблем на самом деле хватает даже в python https://github.com/python/typing/issues. Т.е на практике интуитивно понятные вещи здесь довольно быстро заканчиваются.
На одной типизации все равно до конца не доедешь - рано или поздно придётся расставлять костыли и писать тесты. Потому, что в пределе логика упирается в Теорему Гёделя о неполноте: любая формальная система либо неполна, либо противоречива. На практике лучше иметь дело с неполнотой. Это значит, что какие-то утверждения во всякой непротиворечивой системе типов будут невыводимыми.
Можете привести несколько примеров таких языков?
В теории СУБД выбирается под модель данных, когда становится понятно, что за данные и какие запросы. Но на практике нередко приходится подстраиваться под ограничения существующей инфраструктуры.
Где описывать типы это вопрос синтаксиса на самом деле. Долгое время в python для этого использовали docstrings и комментарии. Потом добавили отдельную нотацию. Но сам питон туда практически не смотрит. То есть вы можете указывать какие угодно типы и на работоспособность программы это ни как не влияет.
Вообще есть ещё два варианта: заглянуть в документацию или подсмотреть в реализацию функции. Проекты на динамических языках без документации почти бесполезны. Ну и отчасти поэтому мощность языков разметки документации там зачастую сопоставима с возможностями основного языка.