Pull to refresh

Comments 24

Имеет ли смысл занижать или завышать балансовую стоимость? Оценивать её по рыночным ценам на аналогичные продукты или по затратам? Не придерется ли кто, если поставить стоимость 1 рубль?
Если себестоимость больше одного рубля, то я бы не рекомендовал её указывать в размере 1 руб. Не исключена вероятность, что такая заниженная сумма вызовет вопросы у налоговых органов. Что касается завышения, то в этом случае я не вижу проблем, поскольку это вопрос оценки. Если Вы оцениваете программу больше себестоимости разработки, то вы повышаете стоимость компании (капитализации).

Вопрос определения себестоимости сложный. Например, в трудовом договоре или подобных документах у разработчика может быть указано авторское вознаграждение в размере 1 рубля (по совету юристов, заявляющих, что отказ от вознаграждения может быть признан ничтожным) и исходя из него и считают себестоимость.


С другой стороны есть практика постановки на баланс бесплатно распространяемых продуктов с символической оценкой стоимости типа акта комиссии "потратили 1 рубль на скачивании из интернета" и вроде вопросов не вызывает.

А как правильно делать, если софт по GPL, но доработан внутри компании, и изменения не были возвращены в основную ветку разработки? (доработки для собственного использования предполагались).
Можно ли его ставить на баланс и как? С какой стоимостью?
С программистами/тестировщиками тоже не понятно —
1. все кто дорабатывал должны это делать по должностным обязанностям — тут понятно.
2. все кто дорабатывал НЕ должны это делать по должностным (к примеру, делали в свободное от работы время) — получается, никак нельзя уже включить софт в баланс.
3. Часть людей делали это в рамках должностных, а часть нет. Тут как?
Не смогу ответить универсально на этот вопрос. Нужно внимательно ознакомиться с лицензионным соглашением. Если лицензия позволяет свободно дорабатывать и использовать доработку как свой софт, то на баланс можно ставить, безусловно. Стоимость точно так же определяется как и в случае с полностью своей разработкой.
По Вашему вопросу №2: софт включить в баланс можно. Это не зависит от того, должны были или не должны в рамках должностных обязанностей сотрудники заниматься разработкой ПО. Должны или не должны – это вопрос к последующему оформлению и возникновению прав на ПО, но это никак не влияет на постановку на баланс в качестве нематериального актива.
Ну, и по вопросу № 3 ответ тот же.

Универсальный правильный способ вряд ли сейчас существует. Если под ним понимать отсутствие претензий со стороны регуляторов и сотрудников как авторов, то я бы сделал три актива:


  • апстрим — по обычной для опенсорса политики фирмы, приобретение неисключительных прав на использование программы для ЭВМ по GPL
  • патчи к апстриму вне рамок служебных заданий — полностью аналогично, с пониманием, что код может быть сотрудниками в любой момент опубликован и вмержен в апстрим, запретить им это делать возможности нет, если этот код написанный кем-то другим ваших прав типа патентных не нарушает
  • патчи к апстриму в рамках служебных заданий — по обычной для собственной разработки политики с учетом ограничений GPL. Возможный конфликт NDA и GPL нужно рассматривать отдельно, но GPL гарантирует, что у сотрудников нет права требовать дополнительное вознаграждение за использование вам их кода
На основании докладной записки специально назначенная комиссия производит анализ возможности приема программного продукта в тестовую или промышленную эксплуатацию, после прохождения которой на основании акта приемки формируется приказ по организации о переводе данного ПО в промышленную эксплуатацию

Какая же у вас мохровая бюрократия. Обычно говорят что в бизнесе на принятие решения уходят считанные минуты, а то не угонишься за конкурентами

Ну тут можно противопоставить от «семь раз отмерь» до «больше бумаги — чище жо..» -)

В бизнесе в виде размера «я директор, я и сторож» — можно и мгновенно, а как быть с бизнесами немного покрупнее?
На самом деле всё очень просто: нужно понять базовый принцип. Я в статье, скорее, говорил о запущенных случаях. Безусловно, можно оптимизировать и включить в трудовые договоры со ВСЕМИ сотрудниками положения, которые освободят от почти половины озвученных в статье бумажек и документов. Нужно иметь в виду, что мы хотим защититься и постараться минимизировать споры о правах на ПО. Поэтому лучше «закрыться» бумажками.

Решение может приниматься быстро, всё это вовсе не означает, что комиссия должна сутками сидеть и тестировть каждый патч. Решение принимается принятым в фирме способом, а потом просто секретарь заполняет приготовленную юристами "рыбы", подставляя дату, название, версию и фамилии членов комиссии и бегает за подписями, если нет нормальной СЭД.

Это очень частый вопрос со стороны программистов: «Какую выгоду я, как создатель, получаю от формализации написанного мною приложения?» Если работодатель, для которого разработчик создал приложение, юридически правильно это приложение формализовал, программисту остается так называемое личное неимущественное право автора. Никаких денежных бенефитов оно с собой, скорее всего, не несет, поскольку создатель уже получил вознаграждение за выполненную работу, и никакими имущественными правами на написанный им софт он уже не обладает. Неимущественные права позволяют потешить собственное эго и добавить проект в портфолио. Например, автор разработки вправе сам предложить название ПО, разрешать указывать свое имя в контексте приложения.

ГК РФ Статья 1295. Служебное произведение

Если работодатель в срок, предусмотренный в абзаце втором настоящего пункта, начнет использование служебного произведения или передаст исключительное право другому лицу, автор имеет право на вознаграждение. Автор приобретает указанное право на вознаграждение и в случае, когда работодатель принял решение о сохранении служебного произведения в тайне и по этой причине не начал использование этого произведения в указанный срок. Размер вознаграждения, условия и порядок его выплаты работодателем определяются договором между ним и работником, а в случае спора — судом.

ЗП за выполнение трудовых обязанностей и вознаграждение за использование — это разные деньги.

Безусловно, ЗП и вознаграждение – это юридически разные вещи, поэтому чтобы «два раза не вставать», всегда проще определиться с этим раз и навсегда для работника и работодателя в соглашении между ними. Как правило, формулировки такого соглашения сводятся к тому, что авторское вознаграждение включено в заработную плату либо выплачивается как премия. Здесь я сторонник не усложнять.
Два раза не вставать не получится.
1) Человек может уволиться, что никаким образом не отменяет вознаграждение.
2) При «учете в ЗП» это будет ЗП и оно не может быть включено в ЗП. Оно должно быть отдельной строкой, как в счете за ЖКХ.
3) На авторское вознаграждение оформляется другой документ, т.к. заранее учесть как и какие объекты авторских прав будут разработаны, невозможно.
4) На каждый объект оформляется свой документ, т.к. они разработаны в разное время.

Как видно, даже при учете пунктов 3, 4, уже невозможно авторское вознаграждение «учесть» в ЗП.
Благодарить нужно копирастов и капитализм.

Все работодатели мечтают о своем собственном рабе-разработчике программисте — всё, что он разработал за зарплату, считают своим, а зачастую, что и он не в рабочее время пытаются узурпировать. Однако, на эту позицию ГК остужает пыл.
Нашел замечательную статью:
https://geektimes.ru/post/173265/
Подскажите,
1. если софт ( программа) написаны до организации юридического лица, а в последствии на основании его регистрируется фирма( то есть фирма создается для продажи или предоставления ПО за деньги). Но софт писался 1м или более человек до факта регистрации фирмы и первых попыток продажи продукта. Какие моменты вы бы порекомендовали заранее просчитать и что необходимо сделать?
2. Не могли бы вы привести пошаговый пример регистрации в Роспатенте, с цифрами и картинками.
3. Как с подобным происходит в других странах, если известно, по примеру вашей статьи?
4. Есть ли какие-то отличия особенности в указанных вами случаях\примерах выше для развлекательного ПО ( мобильных, локальных игр, ПО с дополнительно реальностью)?
5. Как может законно разработчик ПО уйдя из компании, использовать наработки аналогичного функционала своем новом продукте, при этом не быть привлеченным к судебному иску со стороны предыдущего работодателя.

Спасибо!

1.1 Определиться с составом авторов
1.2 Определиться как авторский коллектив передаёт фирме права на использования программы (варианты от передачи в общественное достояние до полной передачи исключительных имущественных прав) и оформить эту передачу
1.3 Определиться как фирма будет передавать клиентам софт (сильно зависит от 1.2)


5 Привлеченным в качестве ответчика по судебному иску всегда может быть, а там что суд решит. Минимизировать вероятность решения в пользу бывшего работодателя — не подписывать никаких NDA, никаких полных передач исключительных прав и т. п., оставаясь полноправным автором хотя бы своих фрагментов кода. Но чем дальше тем сложнее будет найти работы без такой необходимости, в том числе благодаря этому посту :)

1. Самое важное здесь — правильно передать права на программу для ЭВМ фирме, которая будет заниматься продажей этого софта. Это может быть лицензионное соглашение, а может быть полная передача прав таким образом, чтобы фирма, созданная для продажи, стала полным правообладателем ПО.
2. Хорошая идея, в целом. Оставлю это как идею для будущего поста.
3. К сожалению, про многие страны не знаю, но в целом и общем схема приблизительно такая же в некоторых.
4. Никакой разницы в жанре ПО для целей его надлежащего оформления нет. Программа для ЭВМ — это результат интеллектуальной деятельности, и не имеет значения, какой он направленности.
5. Крайне сложный вопрос, ответить на который очень коротко я не смогу. Функционал – это, по сути, идея, то, что должен уметь делать софт. Программ с аналогичным функционалом – множество (к примеру, MS Office, Мой Офис, офисные продукты от Apple и др.). Авторское право на идею не распространяется. Поэтому никто не запрещает разрабатывать у другого работодателя ПО с аналогичным функционалом. Но код должен быть иным, интерфейс и т.д.
Коротко и понятно, но, в силу того, что коротко, не все моменты учтены. Про вознаграждение уже написали выше.
Всегда интересовал вопрос — а если нет записки о создании ПО от автора, то что, ПО не считается служебным произведением? Тогда зачем автору совершать лишние телодвижения и что-то там писать, если по идее это его программа и теоретически он может ее продать? *ситуация из разряда сферического коня в вакууме, но тем не менее* Поэтому я склоняюсь к тому, что ПО принадлежит работодателю в силу его создания автором-работником, и никакие докладные не нужны.
Также можно добавить в трудовой договор условие о том, что автор не против переработки его ПО.
И что-то непонятно с правом автора на имя, как так можно не указывать имя автора?
Ст. 1265 ГК:
1. Право авторства — право признаваться автором произведения и право автора на имя — право использовать или разрешать использование произведения под своим именем, под вымышленным именем (псевдонимом) или без указания имени, то есть анонимно, неотчуждаемы и непередаваемы, в том числе при передаче другому лицу или переходе к нему исключительного права на произведение и при предоставлении другому лицу права использования произведения. Отказ от этих прав ничтожен.

Всё что создаст человек, работающий удаленно, с ненормированным рабочим нём будет принадлежать его работодателю? Записка от автора может и не нужна, но вот без задания работодателю будет очень сложно доказать, что программа написана для него в рамках служебных обязанностей.


Сами же пишите, что автор вправе разрешать использовать произведение без указания его имени.

С удаленкой сложнее конечно.
«В силу создания» — не означает без служебного задания.
Автор да, при его желании можно не указывать, сорри.

Обычный способ выявить дыру в рассуждениях — взять максимально неудобный, гипертрофированный, даже абсурдный вариант. :) Но по сути ничем от обычного офисного работника не отличается, если нет служебного задания — максимум дисциплинарное взыскание вплоть до увольнения, если работник вместо выполнения служебных задач будет писать какой-то софт.


Частый вариант у меня — приходит бизнес и просит подготовить какой-то отчёт, а я не отчёт готовлю, а пишу софт, готовящий отчёты. Формально это моё авторское произведение, исключительные права на использование которого я бизнесу не передаю.

Ну тут смотря кого мы защищаем:) Я — бизнес, который не всегда дает именно документированные задания.
Разработка по Вашей инициативе — вопросов нет, хотя может и работодателя будет бомбить:) Но он может, узнав о разработке, выдать Вам задание написать такую же программу — и вопрос решен в его пользу.
Добрый вечер. А нет ли в качестве примера комплекта указанных документов? Беглый поиск по сети не дал отчётливых результатов!
Only those users with full accounts are able to leave comments. Log in, please.