[Accessibility] AT Device Shared I/O

Mario Lang mlang at debian.org
Wed Sep 10 23:44:09 PDT 2003


I will work on this issue with the BRLTTY Team.

Doug Beattie <dbb at linkexplorer.com> writes:

> In reading through the lsb-futures page on Selection Criteria at:
> "http://www.linuxbase.org/futures/criteria/index.html" under the 
> Phase 1 - Identification section called "License" it says:
>
> The component should have at least one compliant implementation
> available under an Open Source license that also promotes a "No Strings
> Attached" environment for developers. This means that the developer
> would be able to develop and deploy their software however they choose
> using at least one standard implementation. This is interpreted to mean
> that at least one implementation is available under a license that meets
> the Open Source Definition but it does not prohibit propriatry usage.
> The rationale for this criteria is very similar to that of the LGPL.
>
> The "Open Source Definition" is a URL pointing to:
> "http://opensource.org/docs/definition_plain.html"
>
> I believe we should follow the same policy.
>
> Doug
>
> On Wed, Sep 10, 2003 at 08:33:30AM -0600, Doug Beattie wrote:
>> Bill:
>> 
>> Re:
>> 
>> On Wed, Sep 10, 2003 at 11:20:30AM +0100, Bill Haneman wrote:
>> > On Tue, 2003-09-09 at 20:45, Janina Sajka wrote:
>> > > Disadvantage???
>> > > 
>> > > Some would call that an advantage.
>> > 
>> > It's a major disadvantage in a library if you wish to standardize on it,
>> > and no alternate implementations with other licenses exist.  GPL
>> > libraries are the ones that are 'viral' to anything linking to them, and
>> > thus they would not be suitable candidates for standardization.
>> > 
>> > The current legal thinking appears (to my non-expert ears) to be that
>> > GPL libraries on a platform are OK under certain circumstances provided
>> > they use standard APIs which are also available in non-GPL form.  Most
>> > vendors seem to want to bundle both GPL and non-GPL versions with their
>> > platform in this case.
>> > 
>> > This brltty situation has already caused some issues with other braille
>> > packages and is something we'd like to see changed for that reason; it
>> > limits the usefulness of brltty.
>> > 
>> > I do think we need to keep these things in mind insofar as we make
>> > reference to existing implementations of APIs which we consider for
>> > adoption.
>> > 
>> > - Bill
>> >  
>> 
>> This is a good point you raise on the licensing of standards libraries.
>> I am going to also pass this along to the folks doing the general LSB
>> work. They too should be thinking about this as well as all groups so
>> we allow both commercial as well as non-commercial to build on what
>> the standards provide without worry of either losing IP rights or
>> having to deal with/provide software that works with proprietary libs.
>> Both sides need to be watched out for.
>> 
>> Doug
>> -- 
>> Doug Beattie
>> dbb at linkexplorer.com
>> 
>> _______________________________________________
>> Accessibility mailing list
>> Accessibility at freestandards.org
>> http://www.freestandards.org/cgi-bin/mailman/listinfo/accessibility
>
> -- 
> Doug Beattie
> dbb at linkexplorer.com
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at freestandards.org
> http://www.freestandards.org/cgi-bin/mailman/listinfo/accessibility
>

-- 
CYa,
  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