Work vs. design vs. intellectual property in engineering

Anoth­er dis­cus­sion I had on Linked­In recently showed that intel­lec­tu­al prop­erty law is very dif­fi­cult to assim­il­ate, mainly because – due to its «imma­ter­i­al­ity» – it escapes the intu­it­ive and mater­i­al man­ners of human per­cep­tion of the world. This is over­laid by the coder­’s con­vic­tion that, in prin­ciple, they are autonom­ous cre­at­ors, and unfor­tu­nately, many law­yers also think so. The thing is that the coder is always the cre­at­or, but not always the design­er. When the coder is not a design­er, their works (source code) are depend­ent works on primary works, which are tech­nic­al designs expressed, for example with the help of UML, math­em­at­ic­al for­mu­lae, algorithms. Then we expect coders, as developers, to do their craft brilliantly.Given that I often use pur­pose­ful and sys­tem­ic inter­pret­a­tion of con­tracts and law in the expert reports I write, I have decided to describe here an onto­lo­gic­al ana­lys­is of this area of engin­eer­ing. The aim is to determ­ine the mean­ing and range of defin­i­tions of terms com­monly used in the field of intel­lec­tu­al prop­erty. I also hope to help you with this to make bet­ter soft­ware sup­ply contracts.

Source: Cre­ation vs. design vs. intel­lec­tu­al prop­erty in engin­eer­ing – Jarosław Żeliński IT-Con­sult­ing.