Eu tenho trabalhado em vários projetos em casa e no trabalho e, ao longo dos anos, desenvolvi duas APIs principais que uso em quase todos os sites baseados em AJAX. Eu compilei esses dois em DLLs e chamei os namespaces Connell.Database e Connell.Json.
Meu chefe recentemente viu esses espaços para nome em uma documentação de software para um projeto para a empresa e disse que não deveria estar usando meu próprio nome no código. (Mas é o meu código!)
Uma coisa a ter em mente é que não somos uma empresa de software. Somos uma empresa de suporte de TI e sou o único desenvolvedor de software em tempo integral aqui, portanto não há realmente nenhum procedimento sobre como devemos escrever software na empresa.
Outra coisa a ter em mente é que pretendo um dia liberar essas DLLs como projetos de código aberto.
Como outros desenvolvedores agrupam seus namespaces na empresa? Alguém usa as mesmas bibliotecas de classes em projetos pessoais e de trabalho?
Isso também funciona ao contrário? Se eu escrevo uma biblioteca de classes totalmente no trabalho, quem é o proprietário desse código? Se eu vi a biblioteca do começo ao fim, a projetei e a programi. Posso usar isso para outro projeto em casa?
Obrigado,
Atualizar
Conversei com meu chefe sobre esse assunto e ele concorda que eles são meus objetos e que ele está bem em eu abri-los. Antes dessa conversa, comecei a alterar os objetos de qualquer maneira, o que era realmente bastante produtivo e o código agora se adapta a esse projeto específico mais do que antes.
Mas obrigado a todos os envolvidos por um debate muito interessante. Espero que todo esse texto não seja desperdiçado e que alguém aprenda com ele. Eu certamente fiz.
Felicidades,
Respostas:
(Isenção de responsabilidade padrão - não sou advogado ...)
Pelo seu perfil, você parece estar no Reino Unido.
Nesse caso, depende de como você está empregado. Se você é um membro permanente da equipe, quase certamente seu empregador é o dono das obras . Você os escreveu e tem os direitos de ser identificado como o autor (ou seja, você pode dizer às pessoas que os escreveu), mas a propriedade do código e a propriedade intelectual nele residem na sua empresa.
Se você é um contratado, pode ser que você tenha alguma reclamação, mas isso depende da natureza do contrato. De um modo geral, a maioria dos prestadores de serviços de TI do Reino Unido são classificados como trabalhadores contratados, o que significa que novamente o IP é da empresa e não do indivíduo. Certamente, falar de um contrato de trabalho padrão sugere que esse será o caso, caso você seja permanente no contrato.
Nessas circunstâncias, você não tem o direito de liberá-los como código aberto (ou mesmo de levá-los ao seu próximo empregador) e deve pensar neles da mesma maneira que pensa em qualquer outro software proprietário e agir em conformidade - eles ' você não é seu, por acaso você tem acesso ao código fonte.
EDIT : Quanto ao fato de você ter desenvolvido algumas delas em seu próprio tempo. No minuto em que você começou a usá-lo no trabalho sem reivindicar seus direitos e licenciá-lo com antecedência para a empresa, ficou muito sombrio, pois agora é muito difícil mostrar o que foi feito quando. Pelo que você está dizendo, as bibliotecas de código foram testadas, depuradas e corrigidas no tempo de trabalho (e a empresa possui tudo o que foi feito no tempo), além da óbvia sobreposição com o trabalho que você estava fazendo por elas (como evidenciado pelo fato de que elas atendeu a um requisito que a empresa tinha no qual você estava trabalhando) significa que eles têm uma reivindicação e provavelmente uma exigência bastante forte.
A União Unida tem uma peça sobre isso . A seção principal parece ser:
"Existem disposições legais expressas:
· Seção 11 (2) da Lei de Direitos Autorais, Desenhos e Patentes (CDPA) de 1988 e
· Seção 39 da Lei de Patentes de 1977
lidar com a propriedade das obras dos funcionários. De acordo com essas disposições, os empregadores adquirem essencialmente os direitos de propriedade intelectual em relação a quaisquer obras criadas por um funcionário que ele / ela
· Era obrigado a produzir de acordo com os termos do contrato de trabalho ou
· Poderia razoavelmente esperar produzir sob os termos desse contrato.
Obviamente, quanto maior a descrição do trabalho de cada funcionário, mais difícil será para ele evitar os efeitos das Seções 11 (2) e 39 acima.
Mesmo que o trabalho seja criado pelo empregado em seu próprio tempo e utilizando seus próprios recursos, o empregado não poderá necessariamente reivindicar nenhum direito nesse trabalho, se o empregador mostrar que a natureza do trabalho criado foi a que poderia ser razoavelmente contemplado como parte dos deveres do funcionário. Isso é demonstrado pelo caso de Missing Link Software / Magee [1989] FSR 361. Lá, o tribunal sustentou que os direitos autorais de um programa de software escrito por um funcionário fora do horário de trabalho e de seu próprio equipamento foram feitos durante o emprego, como se enquadrava no escopo das tarefas que o Sr. Magee estava empregado para realizar ".
Basicamente, porque essas bibliotecas atendem a um requisito específico em um projeto no qual você está trabalhando para elas, elas têm uma reivindicação.
EDIÇÃO 2 : Você precisa entender que o fato de haver duas versões do código é provavelmente irrelevante. O código atende a uma necessidade da empresa em um projeto em que você estava trabalhando e você o escreveu enquanto era empregado pela empresa (mesmo que fosse no seu próprio tempo). Isso dá a eles uma forte reivindicação sobre o "IP principal" do código, não apenas sobre uma cópia específica que você implementou no projeto deles - visualizá-lo como duas ramificações não muda isso.
Vale a pena notar que mesmo a reescrita seria denominado trabalho derivado e o IP ainda permaneceria com a empresa, mesmo em uma nova versão.
Eu acho que você tem uma idéia do que quer que seja verdade e está tentando distorcer as coisas para fazer isso, mas pelo que você está dizendo, acredito que a empresa tem uma reivindicação muito forte do código de que você não vai ser capaz de contornar.
fonte
Se sua empresa está pagando para você codificar, é o código deles. Eu não o lançaria como um projeto de código aberto, a menos que você tenha a permissão deles.
fonte
Houve casos em que o código escrito em casa enquanto trabalhava para uma empresa era considerado propriedade da empresa. Não tenho certeza se isso já foi testado em tribunal, mas acho óbvio que qualquer código que você escreve usando equipamentos da empresa, durante o tempo da empresa (ou seja, o tempo em que você está sentado em sua mesa sendo pago pela empresa para escrever o código) e por O software da empresa pertence à empresa. Você firmou um contrato com eles (verifique seu contrato de trabalho) que diz que eles lhe darão dinheiro em troca de você escrever um código para eles. Você não ficaria impressionado se eles dissessem que reteriam seu salário porque pretendiam dar-lhe caridade.
Então, em suma, não é o seu código. Você não é o dono. Os namespaces devem ser o nome da empresa porque pertencem a eles. Eles pagaram alguém para escrever! (você é).
fonte
Eu acho que há um lugar onde você cometeu um erro. O problema é que você escreveu o código em casa em seu próprio tempo e descobriu que o código seria útil no trabalho, então você começou a usá-lo também. O que provavelmente seria a coisa certa a fazer nesse caso, não é incorporar o código que foi feito fora do trabalho no código da sua empresa. Você precisaria usar o tempo da empresa para reescrever a funcionalidade que você já escreveu, para que eles pudessem usá-la. "Mas isso é uma grande perda de tempo", você diz. Portanto, a outra opção é que eles licenciem / comprem o código de você por um preço ou gratuitamente, para que saibam que têm permissão legal para usar o código. Eu acho que o que pode estar acontecendo na sua mente dos empregadores é que eles estão se perguntando o que acontece com esse código quando você sai? Eles ainda têm o direito de usar esse código?
Muitos programadores trabalham em coisas em seu tempo livre que provavelmente seriam úteis para seus empregadores, mas você não deve começar a misturar o código sem a aprovação da empresa.
fonte
Os futuros programadores precisam saber quem escreveu o código, caso o nível de documentação seja inadequado (o que, infelizmente, é frequente).
Eu sempre assino meu nome por esse motivo. E também me lembra que preciso garantir um ótimo trabalho, porque sei que, se não o fizer, algum colega irado me ligará no meio da noite! :)
fonte
Como quase todo mundo disse, provavelmente é o caso da empresa ter alguma afirmação sobre o código (com frases como "eu escrevi provavelmente 90% desse projeto em casa". É obscuro).
Uma das coisas a considerar no futuro é revisar cuidadosamente os contratos de trabalho e obter um 'tempo próprio, kit próprio -> propriedade própria' ou obter uma isenção por projeto da empresa. Infelizmente, isso não ajuda em nada.
fonte
O que há de errado em usar outro nome? O nome do seu filho / filha / gato / cachorro / hamster? Então você não precisa ter essas dificuldades - você acabou de escolher um nome 'amigável'.
fonte
Todas as respostas parecem concentrar-se na propriedade.
Mas propriedade e autoria (autores e proprietários, resp) são noções diferentes.
O autor está vinculado a direitos morais ou inalienáveis que são :
Se uma obra já criada e o produto de sua exploração puder ser apreendida pelos credores, conforme o caso, este último não poderá exigir que a referida obra seja divulgada com a finalidade de recuperar o dinheiro devido por seu autor.
Direitos morais, ou inalienáveis, de autor não podem ser renunciados na maioria das jurisdições .
Embora a propriedade esteja relacionada aos direitos Econômicos, também conhecidos como propriedade.
Por que não seguir apenas a prática de como os artigos científicos estão sendo assinados, quando os trabalhadores frequentemente trabalham como pesquisador / professor visitante, empregados / financiados e várias entidades. ou sob financiamento independente de terceiros: nome do autor + onde o trabalho foi realizado + créditos que financiaram o trabalho.
Observe que esses são muitos para muitos relacionamentos (um autor e seu trabalho podem ter várias afiliações e financiamento).
fonte