[Celinux-dev] How to protect intellectual property while maximizing open source usage?

Shawn Kwon ksoonson at samsung.com
Wed Sep 6 17:42:59 PDT 2006


Hi Scott, 

 

As I mentioned in my previous email, all of the comments are my

personal opinion, not my employer.

 

Of course no one will want to be a test case for this.

I gradually got to know that companies not only want to keep their
intellectual property

but also want to avoid to infringe someone else’ intellectual property too

because both will be bad of course and I do not want to be a test case
either. :-)

 

Maybe my initial email looks like I want to make some trick against the
spirit of the community

but it is not. What I think a problem is that there are so many
misunderstandings about

the usage of F/OSS code into the proprietary product and it is unlikely to
decrease.

I worry this kind of misunderstanding is only getting bigger and will keep
increasing with GPLv3

and this will not be good to anyone.

 

Anyway, thank you very much for your comment.

 

/Shawn

 

 

  _____  

From: Preece Scott-PREECE [mailto:scott.preece at motorola.com] 
Sent: Wednesday, September 06, 2006 11:03 PM
To: Shawn Kwon; celinux-dev at tree.celinuxforum.org
Subject: RE: [Celinux-dev] How to protect intellectual property while
maximizing open source usage?

 

Hi, Shawn,

 

(1) On kernel modules, several other people have said pretty sensible
things, including pointing to the Greg KH presentation, which is definitely
what the mainstream kernel community believes the rules are.

 

Of course, Greg's not a lawyer, and the question of whether kernel modules
are derivative works has never been addressed in court. It's not clear what
the answer would be. If you go that way, you risk being a test case. I
agree that it might be difficult to find someone who had standing to sue
you - it would probably have to be someone who held copyright on the
specific interfaces you used, not just anyone with code in the kernel. And
interfaces might be judged to be functional, rather than expressive, and
not covered by copyright whether they're marked as "GPL-only" or not. 

 

On the other hand, do you really want to be a test case and have the
community look on your company as one that tries to break the rules and
operates outside the spirit of the community?

 

(2) The only acceptable way to differentiate is to move your special stuff
outside the kernel - either move it to user space or move it out to another
component that communicates with the kernel. Note that you still may be in
the scope of the GPL in the latter case, because the GPL requires that you
use the GPL for anything that is packaged with the kernel and is designed
to work closely with it. You would need to use some kind of really generic
communication mechanism. If your code could be made to work, unchanged,
with some other OS, that would be a good argument against a claim that it
was a derivative work.

 

Moving to user space, however, is probably safe regardless. I think there's
a reasonably strong agreement that stuff running in user space doesn't need
to be GPL.  However, even there you could get into trouble if you modified
the kernel to open up a faster/quicker pipe between the kernel and user
space. You're really safe only as long as you stick to the standard syscall
interfaces; even sysfs interfaces are arguably too intimate with the kernel
to provide the necessary isolation.

 

Running wholly outside Linux, however, is probably safe. If you have a
separate processor, or if you're running on a microkernel that Linux also
runs on (that is, if you've done virtualization outside Linux, rather than
inside it), that external stuff is pretty clearly separate from Linux and
GPL issues.

 

(3) If the library is GPLed, and you intend to release your product as a
whole (already linked), you're basically stuck with releasing your code as
GPL. If you're releasing unlinked object code to be linked with a dynamic
library, you might get away with it if the library happens to implement a
standard API, but if you linked against header files provided by the GPLed
library, which you would probably have to, then you're stuck with releasing
your code under GPL.

 

My best advice is to not try to work around the rules. The whole point of
community development is that sharing the IP allows the whole to improve
much faster than any one participant could.  By exposing your source code,
you allow others to build on it - to improve it and find problems in it.
The kernel community considers that open interaction to be the cost of
using the work that the other members have done in producing the kernel.

 

Note that IANAL and the opinions here are my own and do not represent my
employer.

 

Regards,

scott

 


  _____  


From: celinux-dev-bounces at tree.celinuxforum.org [mailto:celinux-dev-
bounces at tree.celinuxforum.org] On Behalf Of Shawn Kwon
Sent: Tuesday, September 05, 2006 10:09 PM
To: celinux-dev at tree.celinuxforum.org
Subject: [Celinux-dev] How to protect intellectual property while
maximizing open source usage?

How to protect intellectual property while maximizing open source usage?

 

Well, this topic is not a new one but it is an important part when
developing a product.

 

To ease the discussion, here are brief question-style arguments.

 

1. Should linux kernel module be released under GPL? (Simple question. :-))

 

2. If the kernel module should be GPL, then how can I differentiate the
operating system-related part of my product?

 

3. How can I legally develop my application using GPL’d library with
keeping my application code proprietary?

 

I hope many people can share their views and experiences. I will post my
opinion also soon.

 

/Shawn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tree.celinuxforum.org/pipermail/celinux-dev/attachments/20060906/d6573157/attachment-0001.html


More information about the Celinux-dev mailing list