[racket] Clarification on licensing of Racket code?...

Maybe someone should make a tool that strips the newlines out of macro
definitions so they all meet the "10 lines or less" requirement. After all,
isn't law mainly about finding loopholes?

On Fri, Apr 6, 2012 at 1:22 PM, Brian Mastenbrook <brian at mastenbrook.net>wrote:

> On 04/06/2012 03:06 AM, Eli Barzilay wrote:
>
>> No, that's a roughly description of GPL.  With the LGPL you're free to
>> do whatever you want to do -- you're only required to make public any
>> patches you did to the code you're using (ie, fixes and extensions to
>> racket itself), but your own code is yours.  (And Racket is using the
>> LGPL to *encourage* such uses.)
>>
>
> No; the straightforward license you just described is the MPL, not the
> LGPL. This is a very common and frustrating misconception. The LGPL says a
> lot of very complicated things which require a lawyer to interpret
> correctly.
>
> (Disclaimer: I'm not a lawyer, but in a previous life I worked with
> lawyers to set company-wide processes and create training on how to comply
> with open source licenses for a Fortune 100 technology company.)
>
> In the case of a Racket-generated executable, you must follow the
> requirements of section 6 of the LGPL 2.1, which says that the user must be
> able to relink the executable to a modified version of Racket. This is
> because the exception in section 5 only applies if you use "numerical
> parameters, data structure layouts and accessors, and small macros and
> small inline functions (ten lines or less in length)" from the LGPL'ed
> library, and any Racket of nontrivial complexity will probably involve a
> macro whose implementation happens to be longer than 10 lines of source
> code.
>
> Section six says that you need to provide either object files which can be
> linked with a modified library, or use a "suitable shared library
> mechanism" which allows "interface-compatible" versions of the library to
> be linked. The difficulty in my mind comes in interpreting what
> "interface-compatible" means, and how to separate out the portions of the
> object file that are actually portions of the library (since they are the
> result of expanding a Racket macro). Other projects have either added a
> blanket exception for these kinds of cases [*], but adding such an
> exception for Racket would be tantamount to relicensing it.
>
> You're in the clear if you include the source to your proprietary program
> with the binary, and the source can still be licensed under the terms of
> your choice. If you don't want to do so, talk to a lawyer.
>
> [*]: The "LLGPL", a preamble to the LGPL used by a number of CL projects,
> is an example of this: http://opensource.franz.com/**preamble.html<http://opensource.franz.com/preamble.html>. But instead of adding a preamble that contains additional conditions or
> terms, I'd recommend using the MPL instead. MPL v2.0 when used without the
> "incompatible with secondary licenses" option is an extensively reviewed,
> well-recognized and very straightforward license which is also compatible
> with the LGPL and the GPL via an explicit conversion clause.
> --
> Brian Mastenbrook
> brian at mastenbrook.net
> http://brian.mastenbrook.net/
>
>
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/**users <http://lists.racket-lang.org/users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120406/b439a9ff/attachment.html>