incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wojciech Meyer <wojciech.me...@googlemail.com>
Subject Re: New committers?
Date Fri, 31 Aug 2012 21:24:44 GMT
Jim Jagielski <jim@jaguNET.com> writes:

> On Aug 31, 2012, at 2:27 PM, "C. Bergström" <cbergstrom@pathscale.com> wrote:
>
>> On 09/ 1/12 01:25 AM, Jim Jagielski wrote:
>>> Are you suggesting that FreeBSD does not allow the inclusion of ANY
>>> ALv2 library under its ports directory?
>> I'll give you the benefit of the a doubt one more time...
>>
>> stdcxx ends up linking against *EVERY* C++ application if it's used
>> in the default compiler setup.  (Which is what I was trying to
>> achieve) That includes *******GPLv2******** software in ports.  Get
>> it?
>>
>
> I notice you did not answer my question... It's a simply question
> and requires a simple yes or no. Are you suggesting that FreeBSD does
> not allow the inclusion of ANY ALv2 library under its ports directory?
>
> Thx.

Hi again,

the point is that the stdcxx is rudimentary for the C++ applications,
and if they are GPL then can't use stdcxx as a standard C++
library. Therefore it means that in this setting stdcxx becomes
useless. The license in this case hinders the purpose of the library,
which is bad in many ways, OTOH if AF used extensively C++ in their
projects it would make sense to stick to have own non GPL library. From
my point of view, there would be absolutely no problem if ALv2 was
relaxed version of LGPL and more over compatible with it, but in this
case it's less permissive than LGPL. which for such library is not
appropriate since there are many GPL projects that do use C++.  Libstc++
is LGPL therefore can link with GPL project, and can link with ALv2
project, but stdcxx is ALv2 and cannot link with GPL project.

That's basically what LGPL was designed for, to solve this problem.

It would be like libc was GPL, who would ever consider using that apart
from GPLed projects? For third party standard library is even worse. One
could blame the combination of unlucky choice of the ALv2 for this sort
of project, or FSF being incompatible with that particular license being
a root problem of stdcxx declining. So I understand that people that
want to use stdcxx are being frustrated - because basically they can't
freely use it.

So I disagree with FSF being not able to accept Apache license, but
accepting BSD license at the same point. I also see a point of relaxing
license, to make the projects more successful, either something or
completely nothing I would say. There is nothing better for the project
to put it under BSD license, if the community fails to deliver what is
needed. What Christopher is proposing is not to close the codebase or
anything like this, he is trying to save the damn useful piece of code.

and BTW: I was unaware about the licensing glitch between GPL vs ALv2
until know, and it appeared to me a broken concept from the Open Source
point view (but it makes sense from the Free Software point of view) now
I know why is this hot discussion etc.

The worst scenario would be to put the project into attic, that would
kill that codebase once for good. Please, don't. Now let's think clearly
what can we do to keep it alive. I am willing to contribute still, but I
see limited sense of all this operations, if we can't link it to C++ GPL
programs.

I'll leave this decision to Jim Jagielski, as he is word is the last
here, but you know my view on that. (even if it matters little in the
end)

--
Wojciech Meyer
http://danmey.org

PS: "Linking exception" or "Dual licensing" would that solve the problem?

Mime
View raw message