<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Thanks for all the info! after reading through it I'm probbly going to
do what you guys suggested and since Its php (which is an interpreted
language) I don't think the compiling thing is an issue but would being
interpreted instead of compiled would that change things? I also have a
few other questions. First, if I do this licence buffer approach will
this make it so no libraries can be released gpl but would allow lgpl?
Also could I do this with the agpl since it will be displayed on the
web? (by the way thanks for clarifying what the other clause meant, the
way everyone else worded it kind of confused me)<br>
<br>
Ben Tilly wrote:
<blockquote
cite="mid:acc274b30908070644y26a6b8ecu83854aece9cc0263@mail.gmail.com"
type="cite">
<pre wrap="">2009/8/7 Dag-Erling Smørgrav <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:des@des.no"><des@des.no></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Ben Tilly <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:btilly@gmail.com"><btilly@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">It should be noted that while that is the legal opinion of the FSF,
there is no guarantee that a court will rule that way. For an
interesting alternative, the opinions of Linus on binary kernel
modules is interesting. See
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html">http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html</a>.
While his answers to the question of binary kernel modules changes
over time, he consistently holds to several principles:
1. Whether you're bound by the GPL depends on whether you're a
derivative work of the Linux kernel. Which will be true depending on
the facts.
2. When the plugin API was a generic limited subset of standard Unix
interfaces, there was no question that things which went against it
were not derivative of Linux.
3. When the plugin API was later expanded to expose a lot of Linux
specific details, things that use the full API become derivative of
Linux.
</pre>
</blockquote>
<pre wrap="">I call bullshit. You can't say that with one breath, and with the next
rejoice over winning a lawsuit on the grounds that interfaces are not
copyrightable [to oversimplify].
</pre>
</blockquote>
<pre wrap=""><!---->
I don't know what lawsuit you're bringing up. That I've summarized
Linus' stated opinion over the years can be verified by reading his
various statements on the topic over time. It should be obvious that
while Linus is an intelligent and important person, he is not a
lawyer. Salt what he says accordingly.
</pre>
<blockquote type="cite">
<pre wrap="">I would simply publish function prototypes and struct definitions for
the plugin interface under a permissive license (MIT or Simplified BSD).
</pre>
</blockquote>
<pre wrap=""><!---->
Isn't this exactly the approach that I wound up suggesting? I called
it "a separate library", but that is exactly what an independent file
of function prototypes and struct definitions is. However, as I
noted, if you do that then you should be careful about copying random
useful-looking bits from the GPLed code to this file, because once you
start copying things that other people contributed under a GPL, you
don't have a clear right to say that that file is still under a
permissive license.
Ben
Ben
</pre>
</blockquote>
</body>
</html>