piclist 2009\01\30\094616a >
Thread: Embed inc copyright notice on PIC environment source code- was Banksel
www.piclist.com/techref/microchip/memory.htm?key=bank
face picon face BY : Rolf email (remove spam text)



Moved to TECH as it is not off-topic, and copyright affects us all.

Wouter van Ooijen wrote:
{Quote hidden}

Hi Wouter.

I believe your analysis is only partly correct.

Summarizing the terms of the Embed inc implied license: copying, using,
modifying the code (in whole or in part) is fine as long as the
copyright notice is placed at the top of all files containing any code.

There are two aspects to consider, the fulfillment of the license, and
the copyright ownership of derived 'works of art'.

The copyright notice implies a license to copy the embed inc code
(create a derived work) with the term that the same notice is placed at
the top of the derived work. The terms of the license (putting the
copyright notice at the top of the derived file) in effect assign
ownership of the copyright of the derived file to embed inc., and this
new file is now 'recursively' owned by embed-inc. This is the way that
embed inc intends the process to work based on Olin's previous mails,
and my understanding of the actual copyright notice. (*** for the
record, having done as much reading as I now have done, I don't believe
the embed-inc license is valid/binding... see my notes later on).

The legal question is whether the pre-assembly processing (expanding
macros, including include files, etc.) create a copy (for the purposes
of copyright law) of the embed inc code. I believe that it does but I
can't say for sure. I am sure that the simple act of loading a file from
disk to memory constitutes making a copy for copyright purposes.... it
is thus not much of a stretch to believe that taking bits and pieces
from that in-memory copy is also copying.

Let's follow it through based on the two assumptions that the embed-inc
copyright notice is legally binding, and also that the macro processor
does in fact copy (as it applies to copyright law) the macro to the
target code just prior to assembly/compilation...

Your code uses a macro and the macro processor copies the macro content
to your code before assembly. Two things could happen:

1. The macro assembler is 'magic', and also puts the copyright notice at
the top of the resulting file. In this case, the terms of the license
are satisfied, and the entire resulting file is now copyrighted by embed
inc. The assembly process will make a derived work (by 'translating')
the file to object, then perhaps linked to final binary code. Just
because there is no notice on the binary code does not negate the fact
that it is copyrighted. Even as object code, the translated (assembled)
object code has the same license terms as the source code, and thus,
when linked to some other code, would cause the final binary to also be
owned by embed inc. In this case, the logic would clearly flow that the
resulting binary is copyrighted to embed inc. Note that the courts (at
least in the cases and summaries I have seen in the past years, and then
past days of research) are savvy enough to realize that there is the
concept of human readable, and machine readable. Courts have clearly set
precedence that the expectation of maintaining human readable notices in
the binary code is not necessary, though is still helpful.

2. If the macro assembler is 'typical', it will *not* put the copyright
notice on the interim pre-assembly source file (the list file - whether
on disk or in memory). At this point the "macro-merged" source still
contains code copyright owned by embed inc, only it has not been copied
in accordance with the implied license's terms. The same logic as 1.
above holds true, that the copyright code then gets compiled and moved
in to the final binary version, only this time there is an breach of the
copyright license.

In the case of 1. above, because all the code belongs to embed inc. At
some point embed inc may sue you for profiting off their copyrighted
programs, and they will be able to show a clear chain of logic of how
you compiled their work creating derivative works, and then sold them.
Embed inc may seek a number of remedies including injunctions to stop
you from selling/distributing any more of their code, profits that you
have earned on their code, license fees for future sales, legal fees,
and perhaps statutory damages too if they can prove that you knew it was
their copyright work you were distributing. In my estimation the
ownership of the entire code may be argued to belong to embed inc.

In the case of 2. above, the license terms of the copyright were
violated, and that just means that the list file and so on are just
unauthorized copies, but in my estimation the argument that the entire
code base belongs to embed inc is weakened, and another remedy may be to
just remove embed inc's code from your combined version and keep going
(after paying embed inc for legal fees appropriate license fees, some
profits, etc.)

In either case, I can see an uncomfortable time if the embed inc code
gets challenged in court.

In reality, of course, it is unlikely that embed inc will sue because
they claim now that is not their intent. Further, it is likely, that if
they do sue, you will settle with them before getting to court because
your lawyers will advise you to do so...

*** Getting back to the actual copyright notice and it's implied license
terms, and why the license may not be binding....

The copyright law recognizes that a derivative work contains part of
some original work as well as new copyright material. The law recognizes
that the additional material is copyright owned by the new author, and
the copied work is still owned by the original author. In our case, if
we ignore the terms of the implied license, Embed inc owns the original
code, and we copy parts of it to our code. Again, ignoring the license
for the moment, the law will recognize the copied code as belonging to
embed inc, and will recognize the new code copyright as belonging to the
new author. But, the license changes this 'default' recognition (by
requiring the inclusion of the copyright notice), and assigns the
copyright of the entire file (work) to embed inc. As far as I know, this
is not legally permitted because the only way to assign away ownership
is in writing with a signature.
http://www.bitlaw.com/copyright/license.html Based on other research I
imagine that in some instances the court may rule that the license terms
are not enforceable..... not sure what the consequences of that may be.

Licenses like the GPL are not the same in this regard, because the GPL
license does not require that the derived work changes copyright
ownership, only that it is redistributed with the same license...

Fascinating stuff.

Rolf

This link is an essential read, especially the part about licensing:
http://www.bitlaw.com/copyright/
http://www.bitlaw.com/copyright/license.html

Here are some interesting reading links:
http://cyber.eserver.org/breslow.txt - an overview of copyright as it
relates to software in the US.
http://www.geocities.com/lool95/copyright1.htm - a similar overview

This case is fascinating for software.... I highly recommend looking at
it. Veritas sues Microsoft (and wins) because microsoft copied a C-Code
Macro, translated it to a C++ Macro, and distributed it. It constituted
54 lines of code in a 160,000 line program (0.03%).
www.google.ca/search?q=veritas+microsoft+%2206-0703%22
http://rychlicki.net/en/2008/09/17/539/

<49831293.10705@rogers.com> 7bit

In reply to: <4982A0B4.4050900@voti.nl>
See also: www.piclist.com/techref/microchip/memory.htm?key=bank
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Embed inc copyright notice on PIC environment source code- was Banksel

month overview.

new search...