[Accessibility] AT Device Shared I/O

Mario Lang mlang at debian.org
Thu Dec 4 13:09:08 PST 2003

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.

> 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.

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.

  Mario | Debian Developer <URL:http://debian.org/>
        | Get my public key via finger mlang at db.debian.org
        | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

More information about the Accessibility mailing list