On Sat, 28 Jul 2012 02:28:43 -0300
"Jorge Aldo G. de F. Junior" <jagf...@gmail.com> wrote:
> Think about this : Can you think about the relationship of your
> modules versus someone else modules as being intrinsecally the same
> relation between linux and proprietary apps that happen to run in
> linux ? Because (putting informational security concerns besides) the
> userland apps calls kernel routines just like any app would call a
> library routine, the difference is mainly due to security concerns as
> the kernel code must be secured from userland. But as long as this is
> dynamically linked, i dont see "judicial" differences here.
You have to be very carefull here. You are mixing two different
interface concepts here. For the kernel, its syscall-API is available
to all applications, no matter what their license is. And the basic
Unix kernel API has been implemented in various kernels with differnet
licenses. While if you make a library GPL you define that the API is only
available to applications that are compatible with the GPL. Yes, you can
argue that using the library does not make your application a derived work.
But you cannot argue that you are not allowed to use the library itself.
And if you have a good lawyer, you can argue that if your proprietary
application is based on a GPL library for which no other replacement
with the same API is available, the library becomes an integral part
of the application. And even if the application cannot be deemed a
derivative work (which would be hard to argue in this case), the
violation of the libraries license is without doubt. And as your
application does not work without this specific library, it is
quite easy to conclude that you knowingly and willingly violated
the license terms of the library.
Attila Kinali
--
Why does it take years to find the answers to
the questions one should have asked long ago?
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
