[Accessibility] AT Device Shared I/O

Bill Haneman Bill.Haneman at Sun.COM
Thu Dec 4 14:29:52 PST 2003

Mario Lang wrote:

>Bill Haneman <Bill.Haneman at sun.com> writes:
>>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' :-)
>I think we've had a bit of a miscommuniccation issue here.
glad we broke the logjam :-)

>>My only question is whether relicensing only the 'client' part of
>>brltty would meet our needs.
>That was actually the question I was asking myself.  I assumed
>that relicensing BRLTTY as a whole under the LGPL would solve all
>issues, however, that is not very likely to happen in any foreseeable future.

>>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.
>BRLTTY consists of about 17 or 18 different server side drivers
>for different braille display vendors and models.  Most of them were written
>by completely unrelated people, and it would be a major
>effort to collect agreement from all of them.  The client part
>of brlapi was written by two persons who can still easily be tracked
>down, and who have to my knowledge already indirectly agreed to
>relicensing under the LGPL if necessary.
IANAL, but here's my current and probably flawed, oversimplified take on 
this: as long as we have a couple of LGPL server implementations, the 
LGPL client code can use the "standard interface" for talking to the 
server-side implementations.  From that point on, the user/configurator 
can choose to plug in any service, including GPL services, and the 
argument more-or-less is that the client can't be held responsible, 
license-wise, for this fact.  IOW, 'linkage' via a 'standard' API which 
is available in non-GPL versions ( LGPL is OK ) does not 'virally' 
affect the LGPL client license.  'Linkage' via either a hard connection, 
compile or runtime dependency, does have the 'viral' GPL effect.

So as long as a few LGPL server drivers are available, my understanding 
is that the brltty client code is insulated from claims of being GPL-ified.

Legal experts may have differing opinions on this, AFAIK it's never been 
tested in the courts, but I think the above is a common interpretation.  
I do know that similar arguments have been made regarding, say, things 
like systems that 'link' to GNU tools via APIs and ABIs that are 
'standard' and therefore available (in theory at least) in non-GPL 
versions.  As long as the API/ABI itself is not GPL (i.e. LGPL is OK), 
then using that API/ABI doesn't constitute linkage.  However if the API 
is theoretically non-GPL, but the only implementations available are 
GPL, that argument can easily be contested.

- Bill

>OTOH, providing multiple server side implementations sounds quite
>silly anyway, since this would mean that yet again, drivers
>for obscure hardware would need to be written from scratch.  And
>the quality of the different driver implementations would naturally
>differ from code-base to code-base, which doesn't sound very attractive
>to me.

More information about the Accessibility mailing list