RE: C++ ...

["Wichmann, Mats D" <mats.d.wichmann@intel.com>]

C++ "instability":

> >>May this lacks be solved?  ... Or is a theorical C++ 
> problem without 
> >>solutions ?
> >>
> > 
> > The solution to the C++ problem is for vendors to adopt
> > soon-to-be-released GCC 3.1 as their system compiler.  The 
> LSB will be
> > adopting "The V3 multi-vendor standard C++ ABI" that GCC 3.1
> > implements.
> 
> If it's just blocking for a short time, no problem. So please 
> ignore my previous messages.

We tried to choose the words carefully, "blocked" (maybe the
block can be removed) vs. "rejected", for example.

> > Even once the C++ ABI is included, KDE still has a major blocking
> > issue in the Qt QPL license.  The LSB is designed to provide a
> > platform for software developers to use without restriction or
> > licensing fees for any use whatsoever.  Unfortunately the 
> > QPL does not
> > provide that facility to LSB Applications.
> 
> rpm -qi libqt2-2.3.1-29mdk
> Name        : libqt2                       Relocations: (not 
> relocateable)
> (...)
> License: GPL & QPL

So far, the LSB has not specified anything which has a different
license depending on how you use it.  All libraries have been
of the form that you can link your application with them without
affecting the way you distribute your application.  Many fine
pieces of software, for example Qt, Berkeley DB, MySQL (server
part), are offered under a dual license that says you may choose 
GPL, meaning your application also becomes subject to the terms 
of GPL and you must distribute source, OR you may buy a commercial 
license to bundle it into an application that does not offer
source code.  Or some variant on that theme, this wasn't intended
to be a legal description but a practical one.

We haven't figured out what to do with those; there's been some
significant concern expressed about including such things in a
standard as "required" parts.

Thus the term "blocked" applied to Qt: it's not a complaint
against TrollTech, just that we don't yet know what to do with
technology under such licenses.  Nor have we necessarily
asked them what they would think about being included in
a standard not of their own making, and that should also be
a part of the process.


-- 
To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org