Ви схильні писати своє власне ім’я чи назву компанії у своєму коді?

Я працюю над різними проектами вдома та на роботі, і протягом багатьох років я розробив два основні API, які використовую майже на всіх веб-сайтах на базі AJAX. Я компілював обидва ці файли в DLL і називав простори імен Connell.Database і Connell.Json.

Нещодавно мій бос побачив ці простори імен в документації на програмне забезпечення для компанії і сказав, що я не повинен використовувати власне ім’я в коді. (Але це мій код!)

Слід пам’ятати, що ми не є програмною компанією. Ми компанія, що займається інформаційною підтримкою, і я є єдиним розробником програмного забезпечення на повний робочий день, тому насправді не існує жодних процедур щодо того, як нам писати програмне забезпечення в компанії.

Ще одна річ, яку слід пам’ятати, це те, що я маю намір одного дня випустити ці DLL як проекти з відкритим кодом.

Як інші розробники групують свої простори імен у межах своєї компанії? Хтось використовує бібліотеки одного класу в особистих та робочих проектах?

Чи працює це навпаки? Якщо я пишу бібліотеку класів повністю на роботі, кому належить цей код? Якщо я бачив бібліотеку від початку до кінця, розробив її і запрограмував. Чи можу я використовувати це для іншого проекту вдома?

Спасибі,

Оновлення

Я говорив зі своїм начальником про це питання, і він погоджується, що вони мої об'єкти, і він добре, що я відкриваю їх. Перед цією розмовою я все-таки почав змінювати об'єкти, що було насправді досить продуктивним, і цей код зараз більше відповідає цьому конкретному проекту, ніж раніше.

Але дякую всім, хто бере участь у дуже цікавій дискусії. Я сподіваюся, що весь цей текст не витрачений даремно, і хтось із нього вчиться. Я, звичайно, зробив.

Ура,

(Стандартна відмова від відповідальності - я не юрист ...)

З вашого профілю ви, схоже, перебуваєте у Великобританії.

У цьому випадку це залежить від того, як ви працюєте. Якщо ви постійний співробітник, то майже напевно вашим роботодавцям належать роботи . Ви написали їх і маєте права бути ідентифікованими як автор (тобто ви можете сказати людям, що ви їх написали), але право власності на код та інтелектуальну власність у ньому знаходиться у вашій компанії.

Якщо ви підрядник, то може виникнути випадок, що ви маєте претензії до них, але це залежатиме від характеру договору. Взагалі, більшість ІТ-підрядників Великобританії класифікуються як наймані працівники, що означає, що ІС знову належить компанії, а не фізичній особі. Безумовно, розмова про типовий трудовий договір говорить про те, що це стосується того, чи будете ви постійно діючими за контрактом.

За цих обставин ви не маєте права випускати їх як відкриті джерела (або взагалі брати їх до наступного роботодавця), і ви повинні думати про них так само, як ви думаєте про будь-який інший власний програмний продукт і діяти відповідно - вони ' ти не твій, у тебе просто трапляється доступ до вихідного коду.

EDIT : Щодо того, що ви щось розробляли свого часу. Після того, як ви почали використовувати його на роботі, не заздалегідь заявляючи про свої права та не даючи ліцензії на компанію, ви зробили це дуже мутним, оскільки зараз дуже важко показати, що було зроблено коли. З того, що ви говорите, бібліотеки коду були перевірені, налагоджені та виправлені у робочий час (а компанія володіє чим-небудь зробленим у свій час), а також очевидним збігом роботи, яку ви робили для них (про що свідчить той факт, що вони Виконали вимогу компанії, над якою Ви працювали) означає, що вони мають претензію і, ймовірно, досить сильну.

Єдиний Союз має частину цього . Ключовий розділ, як видається:

"Є чіткі законодавчі положення:

· Розділ 11 (2) Закону про авторські права, зразки та патенти (CDPA) 1988 та

· Розділ 39 Закону про патенти 1977 року

справу з правом власності на працівники. Відповідно до цих положень, роботодавці по суті отримують право власності на права інтелектуальної власності стосовно будь-яких робіт, створених працівником, які він / вона

· Повинні були вироблятися на умовах їх трудового договору або

· Можна обґрунтовано очікувати, що вони виробляються на умовах цього контракту.

Очевидно, що чим ширше посадова інструкція окремого працівника, тим складніше йому буде уникнути наслідків вищевказаних розділів 11 (2) та 39.

Навіть якщо робота створена працівником у свій час та використовуючи власні ресурси, працівник не обов’язково зможе вимагати будь-яких прав на цю роботу, якщо роботодавець покаже, що характер створеної роботи був таким, який міг би бути розумно розглядаються як частина обов'язків працівника. Це демонструє випадок Missing Link Software v Magee [1989] FSR 361. Там суд постановив, що авторські права на програмну програму, написану працівником поза його робочим часом та на власне обладнання, були зроблені в процесі роботи, як це входило до сфери завдань, які містер Мейгі був використаний для виконання ".

В основному тому, що ці бібліотеки відповідали конкретній вимозі проекту, над яким ви працювали над ними, вони мають претензії на них.

EDIT 2 : Вам потрібно зрозуміти, що факт наявності двох версій коду, ймовірно, не має значення. Код відповідає потребі компанії в проекті, над яким ви працювали, і ви написали його, працюючи в компанії (навіть якщо це було у ваш час). Це надає їм серйозну претензію на "основний IP" коду, а не лише на конкретній його копії, яку ви мали реалізувати у своєму проекті - перегляд його як двох гілок цього не змінює.

Варто зауважити, що навіть переписування цього можна назвати похідною роботою, і ІР все ще буде сидіти з компанією навіть у новій версії.

Я думаю, у вас є уявлення про те, що ви хочете бути правдою, і ви намагаєтесь вивернути речі, щоб зробити це так, але з того, що ви говорите, я вважаю, що компанія має досить сильні претензії до коду, який ви не збираєтесь вміти обійтися.

Якщо ваша компанія платить вам за код, це їх код. Я б не випускав його як проект з відкритим кодом, якщо у вас немає їх дозволу.

Були випадки, коли код, написаний вдома , працюючи в компанії, вважався власністю компанії. Я не впевнений, чи було це колись перевірене в суді, але я вважаю, що очевидно, що будь-який код, який ви пишете, використовуючи обладнання компанії, під час роботи компанії (тобто час, коли ви сидите за своїм столом, а компанія платить , щоб написати код) і за програмне забезпечення компанії належить компанії. Ви уклали з ними договір (перевіряйте свій трудовий договір), в якому йдеться, що вони дадуть вам гроші натомість, щоб ви написали для них код. Ви не були б вражені, якби вони сказали, що вони утримуватимуть вашу зарплату, оскільки вони натомість надають їй благодійність.

Отже, коротше, це не ваш код. Ви не володієте нею. Простори імен повинні називати компанію, оскільки вона належить їм. Вони заплатили комусь, щоб це написати! (тобто ви).

• застереження: вам потрібно перевірити свій договір або умови роботи, щоб визначити, чи справді сказане дійсно у вашому випадку, я б сказав, що це все одно, оскільки вони могли б легко звільнити вас за те, що ви робите свою справу в час компанії, як мінімум, а потім заявляйте, що це все одно належить їм. найкраща порада в майбутньому - тримати те, що ви робите для себе, і що ви робите для свого роботодавця, повністю відокремленим.

Я думаю, що є місце, де ти помилився. Проблема полягає в тому, що ви писали код вдома свого часу, а потім виявили, що код буде корисним на роботі, тому ви просто почали використовувати його і там. Що, мабуть, було б належним чином зробити в цьому випадку - це не включити код, який було зроблено поза роботою, у код вашої компанії. Вам або доведеться використовувати час компанії, щоб переписати функціонал, про який ви вже писали, щоб їх могли використовувати. "Але це велика трата часу", - кажете ви. Тож інший варіант полягає в тому, щоб вони ліцензували / купували код у вас за ціною або безкоштовно, щоб вони знали, що їм законно дозволяється використовувати код. Я думаю, що у ваших роботодавців може статися те, що вони цікавляться, що відбувається з цим кодом, коли ви виходите? Чи вони все ще мають право використовувати цей код?

Багато програмістів у вільний час працюють над речами, які, ймовірно, будуть корисні їх роботодавцям, однак не слід починати змішувати код без схвалення компанії.

Майбутні програмісти повинні знати, хто написав код у випадку, якщо рівень документації є недостатнім (що, на жаль, часто так).

Я завжди підписую своє ім’я з цієї причини. І це також нагадує мені, що мені потрібно переконатися, що я роблю чудову роботу, бо знаю, що якщо я не злий колега подзвонить мені посеред ночі! :)

Як майже всі казали, напевно, справа в тому, що компанія має якісь претензії щодо коду (з фразами на кшталт "Я написала, мабуть, 90% цього проекту вдома." Це мутно).

Однією з речей, які слід враховувати у майбутньому, є ретельний перегляд трудових договорів та отримання бланку «власний час, власний комплект -> власна власність» або отримання відмови від проекту від компанії. На жаль, наразі це не допомагає.

Що не так з використанням якоїсь іншої назви? Ім’я вашого сина / дочки / кота / собаки / хом'яка? Тоді вам не доведеться мати цих труднощів - ви тільки що вибрали "дружнє" ім'я.

Здається, всі відповіді зосереджені на власності.
Але право власності та авторство (автори та власники, респ.) - це різні поняття.
Автор пов'язаний з моральними або невідчужуваними правами, які є :

• вічний
• невідчужувані
• Непомітне право
• Немислиме
  Якщо вже створений твір та виручені кошти від його експлуатації можуть бути вилучені кредиторами, залежно від обставин, останні не можуть вимагати розкриття зазначеної роботи з метою повернення грошових коштів, належних її автору.

Моральні чи невід’ємні авторські права не можуть бути відмовлені у більшості юрисдикцій .

Хоча право власності пов'язане з правами Економічні, а також власністю.

Чому б не просто слідувати практиці підписання наукових статей, коли працівники часто працюють в якості відвідувача дослідника / професора, зайнятого / профінансованого численними організаціями. або під незалежне фінансування 3-х партій: ім'я автора + де виконана робота + кредити, які фінансували роботу.

Зауважте, що це багато-багато стосунків (один автор, і його робота, може мати декілька приналежностей та фінансування).