[Accessibility] AT Device Shared I/O

Bill Haneman Bill.Haneman at Sun.COM
Thu Dec 4 04:49:33 PST 2003


Mario:

I replied to you some time ago that LGPL licensing for brltty would 
solve our problems nicely.  I am sorry that you seem not to have 
received this email, but I'm glad this has now come to light.  I was 
waiting on a response from you to my 'yes' :-)

My only question is whether relicensing only the 'client' part of brltty 
would meet our needs.  It is quite possible that at least one 
server-side implementation would also need to be available under LGPL in 
order to avoid charges of linkage between the LGPL client-side code and 
the GPL server-side code.  It would be much better IMO if the servers 
were also LGPL.  The conditions under which an LGPL client can connect 
to a GPL server without being 'contaminated' i.e. GPL-ified are a bit 
tricky.  Having at least a few LGPL server-side implementations can 
protect the client code from charges that it is 'linking' explicitly 
with GPL code (whereas this charge can be made more strongly if all 
available server-side implementations are GPL).  If for some reason the 
brltty maintainers feel strongly that a particular server-side driver 
needs to remain GPL, we can manage that.

best regards,

- Bill

Mario Lang wrote:

>Bill said in the december 4 2003 meeting:
>
>Willy- no response from Mario Lang about participating in the I/O area.
>Bill- need him for the Braille API licensing.
>
>Now I quote a mail I sent to this list several weeks ago:
>
>Mario Lang <mlang at debian.org> writes:
>
>  
>
>>Bill Haneman <bill.haneman at sun.com> writes:
>>
>>    
>>
>>>Regarding the AT Device Shared I/O section:
>>>
>>>Note that we have candidate libraries/APIs for this in the 
>>>Linux space already, for instance libbrl and brltty.  Brltty has the
>>>disadvantage that it's GPL and not LGPL, but the libbrl license is
>>>either LGPL or something similar like BSD.
>>>      
>>>
>>The disadvantage of libbrl however is that it does not meet the goals
>>states in this section.
>>A mechanism which is responsible for sharing braille device I/O
>>has to be as independent from any other components on the system
>>as possible.  Especially, to guarantee a good System Administrator
>>support, such a solution should be able to run without needing
>>any components of the /usr filesystem, since that is usually a separate
>>partition on a typical Linux setup, and is mounted later in the
>>boot process than the root partition.
>>    
>>
>
>[...]
>
>  
>
>>That said, I am working on evaluating the fesability of relicensing the
>>libbrlapi code parts of BRLTTY under the LGPL.  Would such a change eliminate
>>the problems you see with BRLTTY, or do you think other changes are necessary?
>>    
>>
>
>Bill, I am since then waiting for any sort of positive
>or negative reply to this question.  Since you were the one who
>raised the concern with BRLTTY's licensing, I think you have
>the expertise to answer above question.
>
>In general, the BRLTTY Team would be willing to relicense the
>client part of libbrlapi.  I do not know if this would
>suffice.  I am quite willing to coordinate this license
>change with BRLTTY upstream, but I rely on feedback from you.
>It does not make much sense to change a license now, and realize later
>on that it didn't have the desired effects.
>
>  
>





More information about the Accessibility mailing list