Re: [Chicken-users] faster threading

[F. Wittenberger]

Thanks Tobia for the analysis.

Am Sonntag, den 02.11.2008, 12:42 +0100 schrieb Tobia Conforto:
> John Cowan wrote:
> > felix winkelmann scripsit:
> >> Ugh. Sorry, not compatible.
> >
> > Sure it's compatible.  LGPL code can be used as part of a larger  
> > work under any license: it is not viral.
> 
> It's not strictly viral, but some of its terms would place additional  
> burden on Chicken users, that Felix might deem unacceptable.
> 
> Here is my own interpretation, based on the text of the LGPL v3.
> http://www.gnu.org/licenses/lgpl-3.0-standalone.html
> 
> I'm neither advocating the inclusion of rbtree.scm nor its rejection.   
> This mail is meant to save Felix's and others' time, by explaining in  
> a clear way the restrictions posed by including LPGL code in Chicken.
> 
> 
> Notes to section 0.
> 
> "The Library" is rbtree.scm
> "Combined work" are both Chicken itself and any program compiled with  
> Chicken.

Sure?  Any program compiled by chicken?  Within those programs the code
does not even have to be referenced in any compiled binary.

At worst I could understand that any code compiled by any compiler, e.g.
chicken, using the macro could be tainted by the macros license.

But I'm not sure, since, well a compiler is in a way nothing by a rather
involved macro expander. ... 

I would understand that combined work would be the chicken
distributions, if they includes the macro definition and maybe those
libraries, which include the macros output.  But I might be wrong at
that.

If I am correct, than there would have to be an alternative
implementation for inclusion into proprietary programs.  Which could -
at least for the time being - be the old implementation.

> "Applications" means all work put into Chicken and into any program  
> compiled with it, except for the file rbtree.scm
> "Minimal Corresponding Source" is the file rbtree.scm
> 
> Notes to section 2.
> 
> rbtree.scm must not depend on Applications (the rest of Chicken, or  
> programs compiled with it) meaning that interactions between the two  
> parts must be limited to Applications calling rbtree's API.

OK, that one would be fulfilled.

> Notes to section 3.
> 
> Combined works (again, both Chicken and programs compiled with it)  
> cannot be conveyed under a license that restricts modifications to the  
> rbtree.scm part of the work, or that restricts reverse engineering for  
> debugging such modifications.

Hm.  BSD would not restrict modifications to rbtree.scm.

Prohibiting reverse engineering - I don't know.  In Europe it is illegal
to restrict reverse engineering for such reasons anyway.

But it might be a road blocker already.

> Moreover, they must be conveyed in a form suitable for relinking with  
> a modified version of rbtree.scm.  This means that all programs  
> statically linked with Chicken must also be distributed in object  
> code, to allow relinking with a different version of rbtree.scm
> 
> All copyright notices displayed during execution, both in Chicken and  
> programs compiled with it, must state that the work uses rbtree.scm  
> and that it's covered by the LPGL and where to find the license text.
> 
> 
> John, I'd appreciate your input on whether my interpretation is correct.

If that turn out to be correct, we can forget about rbtree.scm.  Though
I recall that LGPL does not include such a display requirement.

Otherwise: could we go with the original MIT file?  Skipping those
improvements, we would at least end up better than before.

/Jörg

BTW: I ran into that wiki page and found a nice presentation:
http://www.cs.princeton.edu/~rs/talks/LLRB/RedBlack.pdf