Промпт — это входные данные, а не конечный результат труда. Так же как тык по клавиатуре это не произведение, а произведение — то, что в итоге вывелось на экран. Не важно, насколько филигранно вы нажали на кнопочки на клавиатуре, как сработала автокоррекция и еще любые факторы, модифицирующие вывод, результат труда — то, что в итоге вывелось на экран.
Хорошо, автоматическая проверка орфографии в ворде — если вы прогоняете свой текст через нее и принимаете исправления, кому принадлежат права на итоговый вариант? Когда вы строите график по своим данным с помощью автоматических инструментов, кому принадлежат права на растровое изображение? Вы его не рисовали руками.
Смысл в том, что человечество изобрело великое множество сложнейших инструментов, которые многократно преумножают прилагаемые человеком усилия, ИИ в этом плане совсем не новинка. И, как это ни странно, сложилась практика, что результат этого преумножения приписывается не разработчику инструмента, а его владельцу (или арендатору). Нет смысла здесь отпираться, что вы не знакомы с фотоделом, потому что подобные инструменты существуют во всех областях жизни. Кому принадлежит яма, выкопанная экскаватором? Кому принадлежит поднятая башенным краном бетонная плита? А молоко, перевезенное грузовиком?
ИИ — такой же инструмент, как клавиатура или уже упомянутый выше фоторедактор. По вашей логике все, что человек не сделал непосредственно руками, никому не принадлежит и может быть использовано кем угодно — будь то сгенерированный с помощью ИИ код, написанный с помощью клавиатуры текст (ведь буквы на экране не нарисованы руками, это компьютер оцифровывает нажатия на кнопки, производит сложные манипуляции, сохраняет и выводит это все) или отредактированная в автоматическом режиме фотография (где можно считать, что фотография — промпт, а автоматические алгоритмы редактирования — ИИ)
Перевод этой страшной фразы (без вырезаний) на русский язык выглядит так:
Несмотря на вышеизложенное, вы признаете, что Предложения генерируются автоматически с помощью технологии машинного обучения и могут быть похожими или идентичными Предложениям, предоставляемым другим клиентам, и настоящие Условия не предоставляют вам никаких прав на любые Предложения, сгенерированные, предоставленные или возвращенные Сервисом для других клиентов или другим клиентам.
Я проанализировал статью на Habr и сравнил её утверждения с предоставленными условиями использования Cursor (Terms of Service). Вот разбор основных тезисов статьи:
1. Запрет на коллективные иски
Утверждение статьи: «Вы будете судиться с компанией один на один, и участвовать в коллективном иске не можете».
Проверка: Это правда. Данное условие является стандартной практикой для многих американских компаний. В разделе 20.2 Условий использования Cursor (Dispute Resolution and Arbitration) действительно содержится пункт об отказе от коллективных исков (Class Action Waiver). Это распространенная юридическая практика, а не уникальная особенность Cursor.
2. Авторские права на сгенерированный код
Утверждение статьи: «Все, что вы сгенерили с помощью тула, вам не принадлежит. Копирайт не ваш…»
Проверка: Это неверная интерпретация. Статья строит свой главный аргумент на вырванной из контекста части пункта 6.2.
Вот что говорится в пункте 6.1 (Customer Data):
> "You (or, if you are an Organization, your End Users) own all of your Customer Data (including any Suggestions you generate that are not the same as or substantially similar to those generated for or by other users)."
Перевод:«Вы (или, если вы Организация, ваши Конечные пользователи) владеете всеми вашими Данными клиента (включая любые Сгенерированные предложения, которые не являются такими же или практически идентичными тем, что были сгенерированы для других пользователей или ими самими)».
А вот полный контекст пункта 6.2, на который ссылается автор статьи:
> "We own all right, title, and interest in and to the Service... Notwithstanding the foregoing, you acknowledge that Suggestions are generated automatically by machine learning technology and may be similar to or the same as Suggestions provided to other customers, and no rights to any Suggestions generated, provided, or returned by the Service for or to other customers are granted to you under these Terms."
Перевод:«Мы владеем всеми правами на Сервис... Несмотря на вышеизложенное, вы признаете, что Предложения генерируются автоматически... и могут быть похожими или идентичными Предложениям, предоставляемым другим клиентам, и никакие права на какие-либо Предложения, созданные для других клиентов или им, не предоставляются вам...»
Вывод: Условия прямо говорят, что вы владеете сгенерированным кодом. Пункт 6.2, на который ссылается автор, лишь защищает компанию от претензий, если два разных пользователя получат одинаковый или похожий код. Он говорит, что вы не получаете прав на код, сгенерированный для других пользователей, а не на свой собственный. Автор статьи либо неверно понял этот пункт, либо сознательно исказил его смысл, проигнорировав предшествующий пункт 6.1.
3. Использование данных
Утверждение статьи: Данные не сохраняются в «приватном режиме», но если вы участвуете в программе по «улучшению сервиса», то данные используются.
Проверка: Это правда и является стандартной практикой для AI-сервисов. Условия использования и Политика конфиденциальности (на которую они ссылаются) обычно описывают, как данные используются для улучшения продукта, и предоставляют пользователям возможность отказаться (opt-out). Cursor предлагает режим "Privacy Mode" именно для этих целей. Статья подает это как нечто зловещее, хотя это стандартный и прозрачный подход.
4. Риск судебных исков за использование чужого кода
Утверждение статьи: «В любой момент кто-то может предъявить вам претензию за использование чужого кода. И у вас нет уже права код называть своим».
Проверка: Этот вывод основан на неверном утверждении об отсутствии у вас авторских прав. Поскольку вы владеете сгенерированным кодом (как указано в п. 6.1), этот конкретный риск, описанный в статье, некорректен.
Однако стоит отметить, что общий риск, связанный со всеми AI-генераторами кода, существует: модель может воспроизвести код из своих обучающих данных, который может быть защищен лицензиями. Это проблема всей индустрии, а не специфический риск, вытекающий из Условий использования Cursor.
5. Право компании изменять условия
Утверждение статьи: Компания может в любой момент поменять условия.
Проверка: Это правда. Практически все онлайн-сервисы оставляют за собой право обновлять свои условия. На странице Terms of Service указана дата последнего обновления ("Last updated July 24, 2024"), что подтверждает эту практику. Это стандартное положение, а не злой умысел.
Итог
Статья на Habr вводит читателей в заблуждение. Её главный и самый пугающий тезис — об отсутствии у пользователя прав на сгенерированный код — является ложным и основан на неверном толковании Условий использования. Остальные пункты (отказ от коллективных исков, использование данных для улучшения сервиса, право на изменение условий) описывают стандартные юридические и коммерческие практики в IT-индустрии, которые автор подает в неоправданно негативном свете.
Судя по всему, какое-то время назад ваше решение считалось приватным апи, поэтому не известно широкой публике (что, конечно, не умаляет костыльности решения с проигрыванием пустого звука)
Флагов -F у нас немного (порядка десятков), так как при сборке мы не используем фреймворки, за исключением бинарных. Подавляющее количество флагов — -Xcc -fmodule-map-file=... — их около тысячи.
Я правильно понял, что чем больше либ на objc содержит твой podfile, тем хорошо если квадратично больше время запуска дебаггера?
Не совсем так, взрывной рост флажков clang-а вызывает как раз рост количества Swift-модулей, а не ObjC. Как можно понять из нашего локального решения, позволившего смягчить проблему, если бы у вас был один Swift-модуль на все приложение, описанное в статье на вас бы не повлияло :)
Тем не менее, это не делает ваше наблюдение неправильным, ведь у cocoapods своя атмосфера. Вот пара фактов:
1. Даже если под написан только на Swift без примесей ObjC, поды добавляют к нему сгенерированные заголовок и m-файл.
2. Каждому поду в header search paths записываются пути поиска до всех остальных подов, вне зависимости от того, от чего он на самом деле зависит (простите за каламбур).
Вследствие этих фактов получаем такую картину: допустим, у нас были поды A, B, C, все на Swift. Поды сгенерируют проект таким образом, что, в числе прочих, у Swift-модулей будут такие флажки:
И, таким образом, количество флажков возросло с 6 до 12 (в асимптотике тут будет квадратичный рост: всего их будет N * (N - 1)). Напомню, что, как мы уже выяснили в статье, все эти флажки склеятся, несмотря на то, что они дублируют друг друга.
Давайте добавим еще один под E, но уже на ObjC. Для него не будет Swift-модуля, пагубным образом влияющего на дебаггер, поэтому картина будет такая:
Количество флажков возросло с 12 до 16, но, если бы модуль E содержал Swift (или был бы полностью на нем, это уже никакой роли не играет), то мы бы увидели не 16, а целых 20 флажков (т.к. добавилась бы еще такая же строчка для E).
tl;dr: количество флажков при использовании подов растет как M * N, где M — количество подов, использующих Swift (неважно при этом содержат ли они ObjC), а N — общее количество подов (причем во всем этом учитываются не только те поды, которые вы используете непосредственно в вашем приложении, но и их зависимости, которые вы, возможно, напрямую не используете). Таким образом, как ни парадоксально, чем больше доля подов на чистом ObjC, тем меньше взрыв флажков при сборке контекста дебаггера.
Меня мучает такой вопрос: какие преимущества у лазерной коррекции перед ИОЛ? Вроде как замена хрусталика — операция, которая отработана на огромном количестве пациентов с катарактой, риск осложнений минимален, и, насколько я знаю, ее можно делать повторно без особых ограничений. С другой стороны, лазерная коррекция — это необратимые изменения, и докоррекция там довольно нетривиальна, плюс травмируется Боуменова мембрана.
Я тоже слышал, что Йота использует мегафоновскую физическую сеть, но у меня есть еще одно свидетельство того, что что-то тут нечисто – друг также перешел с Мегафона на Йоту и тоже жалуется на отвратительное качество связи, планирует вернуться обратно.
Возможно, спорить не буду, опыта использования IB у меня нет. Доводилось просто видеть проекты с описанной мной кашей, в которой очень сложно разобраться.
Имхо, смысл не использовать IB есть, когда в приложении сложный UI с большим количеством переходов. В этом случае ваши макеты превратятся в вечнотормозящую (в Xcode) мешанину.
Дело в том, что constraints удобны для использования только в IB. Если отрисовывать интерфейс полностью кодом, то проще реализовать старый добрый layoutSubviews. А уже IB vs программная отрисовка — это отдельная большая тема для рассуждений: в каких-то случаях лучше одно, в других — другое.
Вы тоже создаете новую программу, но из чужих — вы же на чем-то обучались. Что тут принципиально меняет ИИ?
Промпт — это входные данные, а не конечный результат труда. Так же как тык по клавиатуре это не произведение, а произведение — то, что в итоге вывелось на экран. Не важно, насколько филигранно вы нажали на кнопочки на клавиатуре, как сработала автокоррекция и еще любые факторы, модифицирующие вывод, результат труда — то, что в итоге вывелось на экран.
А где там ИИ? Вы подразумеваете, что написание промпта — не творческий труд?
Хорошо, автоматическая проверка орфографии в ворде — если вы прогоняете свой текст через нее и принимаете исправления, кому принадлежат права на итоговый вариант? Когда вы строите график по своим данным с помощью автоматических инструментов, кому принадлежат права на растровое изображение? Вы его не рисовали руками.
Смысл в том, что человечество изобрело великое множество сложнейших инструментов, которые многократно преумножают прилагаемые человеком усилия, ИИ в этом плане совсем не новинка. И, как это ни странно, сложилась практика, что результат этого преумножения приписывается не разработчику инструмента, а его владельцу (или арендатору). Нет смысла здесь отпираться, что вы не знакомы с фотоделом, потому что подобные инструменты существуют во всех областях жизни. Кому принадлежит яма, выкопанная экскаватором? Кому принадлежит поднятая башенным краном бетонная плита? А молоко, перевезенное грузовиком?
Удобно это вы пример с фоторедактором проигнорировали, который как раз превентивно для подобных аргументов и был приведен.
ИИ — такой же инструмент, как клавиатура или уже упомянутый выше фоторедактор. По вашей логике все, что человек не сделал непосредственно руками, никому не принадлежит и может быть использовано кем угодно — будь то сгенерированный с помощью ИИ код, написанный с помощью клавиатуры текст (ведь буквы на экране не нарисованы руками, это компьютер оцифровывает нажатия на кнопки, производит сложные манипуляции, сохраняет и выводит это все) или отредактированная в автоматическом режиме фотография (где можно считать, что фотография — промпт, а автоматические алгоритмы редактирования — ИИ)
Перевод этой страшной фразы (без вырезаний) на русский язык выглядит так:
Надеюсь, вопросы на этом отпадают.
Я проанализировал статью на Habr и сравнил её утверждения с предоставленными условиями использования Cursor (Terms of Service). Вот разбор основных тезисов статьи:
1. Запрет на коллективные иски
Утверждение статьи: «Вы будете судиться с компанией один на один, и участвовать в коллективном иске не можете».
Проверка: Это правда. Данное условие является стандартной практикой для многих американских компаний. В разделе 20.2 Условий использования Cursor (Dispute Resolution and Arbitration) действительно содержится пункт об отказе от коллективных исков (Class Action Waiver). Это распространенная юридическая практика, а не уникальная особенность Cursor.
2. Авторские права на сгенерированный код
Утверждение статьи: «Все, что вы сгенерили с помощью тула, вам не принадлежит. Копирайт не ваш…»
Проверка: Это неверная интерпретация. Статья строит свой главный аргумент на вырванной из контекста части пункта 6.2.
Вот что говорится в пункте 6.1 (Customer Data):
> "You (or, if you are an Organization, your End Users) own all of your Customer Data (including any Suggestions you generate that are not the same as or substantially similar to those generated for or by other users)."
Перевод: «Вы (или, если вы Организация, ваши Конечные пользователи) владеете всеми вашими Данными клиента (включая любые Сгенерированные предложения, которые не являются такими же или практически идентичными тем, что были сгенерированы для других пользователей или ими самими)».
А вот полный контекст пункта 6.2, на который ссылается автор статьи:
> "We own all right, title, and interest in and to the Service... Notwithstanding the foregoing, you acknowledge that Suggestions are generated automatically by machine learning technology and may be similar to or the same as Suggestions provided to other customers, and no rights to any Suggestions generated, provided, or returned by the Service for or to other customers are granted to you under these Terms."
Перевод: «Мы владеем всеми правами на Сервис... Несмотря на вышеизложенное, вы признаете, что Предложения генерируются автоматически... и могут быть похожими или идентичными Предложениям, предоставляемым другим клиентам, и никакие права на какие-либо Предложения, созданные для других клиентов или им, не предоставляются вам...»
Вывод: Условия прямо говорят, что вы владеете сгенерированным кодом. Пункт 6.2, на который ссылается автор, лишь защищает компанию от претензий, если два разных пользователя получат одинаковый или похожий код. Он говорит, что вы не получаете прав на код, сгенерированный для других пользователей, а не на свой собственный. Автор статьи либо неверно понял этот пункт, либо сознательно исказил его смысл, проигнорировав предшествующий пункт 6.1.
3. Использование данных
Утверждение статьи: Данные не сохраняются в «приватном режиме», но если вы участвуете в программе по «улучшению сервиса», то данные используются.
Проверка: Это правда и является стандартной практикой для AI-сервисов. Условия использования и Политика конфиденциальности (на которую они ссылаются) обычно описывают, как данные используются для улучшения продукта, и предоставляют пользователям возможность отказаться (opt-out). Cursor предлагает режим "Privacy Mode" именно для этих целей. Статья подает это как нечто зловещее, хотя это стандартный и прозрачный подход.
4. Риск судебных исков за использование чужого кода
Утверждение статьи: «В любой момент кто-то может предъявить вам претензию за использование чужого кода. И у вас нет уже права код называть своим».
Проверка: Этот вывод основан на неверном утверждении об отсутствии у вас авторских прав. Поскольку вы владеете сгенерированным кодом (как указано в п. 6.1), этот конкретный риск, описанный в статье, некорректен.
Однако стоит отметить, что общий риск, связанный со всеми AI-генераторами кода, существует: модель может воспроизвести код из своих обучающих данных, который может быть защищен лицензиями. Это проблема всей индустрии, а не специфический риск, вытекающий из Условий использования Cursor.
5. Право компании изменять условия
Утверждение статьи: Компания может в любой момент поменять условия.
Проверка: Это правда. Практически все онлайн-сервисы оставляют за собой право обновлять свои условия. На странице Terms of Service указана дата последнего обновления ("Last updated July 24, 2024"), что подтверждает эту практику. Это стандартное положение, а не злой умысел.
Итог
Статья на Habr вводит читателей в заблуждение. Её главный и самый пугающий тезис — об отсутствии у пользователя прав на сгенерированный код — является ложным и основан на неверном толковании Условий использования. Остальные пункты (отказ от коллективных исков, использование данных для улучшения сервиса, право на изменение условий) описывают стандартные юридические и коммерческие практики в IT-индустрии, которые автор подает в неоправданно негативном свете.
Да вот то же самое прям для iOS https://github.com/divkit/divkit/blob/main/client/ios/DivKit/generated_sources/DivTemplate.swift
Опенсорс 3 года назад, делалось 7-8 лет назад
Судя по всему, какое-то время назад ваше решение считалось приватным апи, поэтому не известно широкой публике (что, конечно, не умаляет костыльности решения с проигрыванием пустого звука)
Не скажу про динамику заболеваемости, а вот смертность у них практически на нуле, в отличие от нас, и не растет.
-Fу нас немного (порядка десятков), так как при сборке мы не используем фреймворки, за исключением бинарных. Подавляющее количество флагов —-Xcc -fmodule-map-file=...— их около тысячи.Не совсем так, взрывной рост флажков
clang-а вызывает как раз рост количестваSwift-модулей, а неObjC. Как можно понять из нашего локального решения, позволившего смягчить проблему, если бы у вас был одинSwift-модуль на все приложение, описанное в статье на вас бы не повлияло :)Тем не менее, это не делает ваше наблюдение неправильным, ведь у
cocoapodsсвоя атмосфера. Вот пара фактов:1. Даже если под написан только на
Swiftбез примесейObjC, поды добавляют к нему сгенерированные заголовок иm-файл.2. Каждому поду в header search paths записываются пути поиска до всех остальных подов, вне зависимости от того, от чего он на самом деле зависит (простите за каламбур).
Вследствие этих фактов получаем такую картину: допустим, у нас были поды
A,B,C, все наSwift. Поды сгенерируют проект таким образом, что, в числе прочих, уSwift-модулей будут такие флажки:A:-Ipath/to/B -Ipath/to/CB:-Ipath/to/A -Ipath/to/CC:-Ipath/to/A -Ipath/to/BТеперь мы хотим добавить еще один под
D, и картина будет выглядеть уже таким образом:A:-Ipath/to/B -Ipath/to/C -Ipath/to/DB:-Ipath/to/A -Ipath/to/C -Ipath/to/DC:-Ipath/to/A -Ipath/to/B -Ipath/to/DD:-Ipath/to/A -Ipath/to/B -Ipath/to/CИ, таким образом, количество флажков возросло с 6 до 12 (в асимптотике тут будет квадратичный рост: всего их будет
N * (N - 1)). Напомню, что, как мы уже выяснили в статье, все эти флажки склеятся, несмотря на то, что они дублируют друг друга.Давайте добавим еще один под
E, но уже наObjC. Для него не будетSwift-модуля, пагубным образом влияющего на дебаггер, поэтому картина будет такая:A:-Ipath/to/B -Ipath/to/C -Ipath/to/D -Ipath/to/EB:-Ipath/to/A -Ipath/to/C -Ipath/to/D -Ipath/to/EC:-Ipath/to/A -Ipath/to/B -Ipath/to/D -Ipath/to/ED:-Ipath/to/A -Ipath/to/B -Ipath/to/C -Ipath/to/EКоличество флажков возросло с 12 до 16, но, если бы модуль
EсодержалSwift(или был бы полностью на нем, это уже никакой роли не играет), то мы бы увидели не 16, а целых 20 флажков (т.к. добавилась бы еще такая же строчка дляE).tl;dr: количество флажков при использовании подов растет как
M * N, гдеM— количество подов, использующихSwift(неважно при этом содержат ли ониObjC), аN— общее количество подов (причем во всем этом учитываются не только те поды, которые вы используете непосредственно в вашем приложении, но и их зависимости, которые вы, возможно, напрямую не используете). Таким образом, как ни парадоксально, чем больше доля подов на чистомObjC, тем меньше взрыв флажков при сборке контекста дебаггера.