This seems really confusing.<br><br>It would imply that if I write a library that is designed to talk to some part of the linux kernel API (which is GPL&#39;d) then I&#39;d have to release my library under the GPL. And anything that used my libraries API would need to be GPL&#39;d too, etc...<br>
Which would mean that everything run in linux would need to be GPL&#39;d, which is just silly.<br><br>- Job<br><br><div class="gmail_quote">On Fri, Mar 5, 2010 at 12:22 PM, Robert Greayer <span dir="ltr">&lt;<a href="mailto:robgreayer@gmail.com">robgreayer@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Pending an explicit response from the SFLC, I decided to ask the FSF<br>
themselves what they thought of the Hackage/cabal situation.<br>
Specifically, I asked this:<br>
<br>
&gt; There is a website, &#39;Hackage&#39; (<a href="http://hackage.haskell.org" target="_blank">http://hackage.haskell.org</a>) that hosts<br>
&gt; source code packages for Haskell libraries and programs.  The site<br>
&gt; hosts *only* source code, along with (text) descriptions of the<br>
&gt; packages.  Each package hosted by the site is either source code for a<br>
&gt; library, for a program, or for both.<br>
<br>
&gt; In the package description, a package author specifies what license<br>
&gt; applies to the source code, the common choices being LGPL, GPL, or<br>
&gt; BSD3.  The package author also specifies what other packages in the<br>
&gt; repository the package may require to compile successfully.<br>
<br>
&gt; The controversy in the community of users who use Hackage is whether<br>
&gt; or not it is a violation of the GPL for a package to be uploaded to<br>
&gt; Hackage specifying (for example) a BSD3 license for the code in the<br>
&gt; package, but also specifying that another package is a requirement for<br>
&gt; compilation, where that other package has been uploaded specifying (a<br>
&gt; version of) the GPL as its license.<br>
<br>
&gt; The opinion of many in the community is that since Hackage hosts only<br>
&gt; source code, and does not in any way combine packages (any combination<br>
&gt; of packages is created when a user chooses to download and compile and<br>
&gt; link the individual packages) there is no problem: there are no<br>
&gt; &#39;derived works&#39; combining GPL and non-GPL being distributed on the<br>
&gt; site.<br>
<br>
&gt; Others believe that having a non-GPL package have as a dependency a<br>
&gt; GPL package is a problem for both the package author and for Hackage;<br>
&gt; that this in some way violates the GPL.<br>
<br>
&gt; I don&#39;t believe this sort of situation is clearly addressed in your<br>
&gt; FAQ (at least not to the satisfaction of the Hackage user community).<br>
&gt; There&#39;s a certain amount of fear, uncertainty and doubt being spread<br>
&gt; about usage of the GPL on Hackage, which it would be great to dispel<br>
&gt; (or, confirm, as necessary).<br>
<br>
<br>
Someone from the FSF responded as follows:<br>
<br>
&gt; A work which extends or requires a GPL work will generally also need to<br>
&gt; be released under the GPL, unless the GPL work provides a specific<br>
&gt; exception for that case. You are already familiar with the FAQ; however,<br>
&gt; please note <a href="http://www.fsf.org/licensing/licenses/gpl-faq.html#OOPLang" target="_blank">http://www.fsf.org/licensing/licenses/gpl-faq.html#OOPLang</a><br>
&gt; and <a href="http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation" target="_blank">http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation</a> .<br>
&gt; There is no magic to the act of linking, compiling, or a function<br>
&gt; invocation; these are not defining moments. It is the level of<br>
&gt; integration and dependency which will define whether one work is a<br>
&gt; derivative of another.<br>
<br>
&gt; Ultimately, the decision that one work is a derivative of another is a<br>
&gt; legal one which a court may have to decide for a particular case; a<br>
&gt; lawyer can give you a legal opinion. However, a good rule of thumb would<br>
&gt; be: if P is a GPL work, and Q is a work that would not function without<br>
&gt; P, then Q is probably a derivative of P and should only be conveyed to a<br>
&gt; third party or the public under a GPL license, in compliance with the<br>
&gt; license for P.<br>
<br>
&gt; I hope that helps.<br>
<br>
&gt; Thank you for your interest in free software!<br>
&gt; I am not a lawyer and the above is not legal advice.<br>
&gt; The opinions expressed above do not constitute an official position of<br>
&gt; the Free<br>
&gt; Software Foundation.<br>
<br>
&gt; Luigi Bai<br>
&gt; FSF Associate Member<br>
&gt; Volunteer, <a href="mailto:licensing@gnu.org">licensing@gnu.org</a><br>
<br>
Of course, given the disclaimer at the bottom, this opinion is officially no<br>
better than any of our opinions on the matter.  Nevertheless, I would at<br>
least believe based on the above that this is what the FSF *wants* the GPL<br>
to mean, and, by extension, would assume, barring other evidence that<br>
this is what someone who chooses the GPL *wants* it to mean, and in<br>
licensing any software that I write that depends on someone else&#39;s GPL&#39;d<br>
software, I&#39;d respect those desires (without at all suggesting that this has<br>
any bearing on how the GPL would actually be interpreted in court).<br>
<br>
There&#39;s still a lot of gray area here -- the mere existence of a dependency<br>
doesn&#39;t imply that a software package is useless without the dependency,<br>
so there are many situations in which P could depend on Q and not be<br>
a derivative of Q, because the dependency can be disabled in some way<br>
and the software would still function.  As an example -- pandoc can be<br>
built with or without highlighting-kate, and is useful either way.  They&#39;re both<br>
GPL and by the same author, so there&#39;s no issue, but were that not the<br>
case it would seem obvious that pandoc isn&#39;t derivative of -kate, and<br>
thus could (by this reasoning) be released independently under different<br>
terms.  The same may not be true of the hakyll / pandoc situation which<br>
sparked this controversy.<br>
<br>
Cheers,<br>
Rob<br>
<div><div></div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>