D library projects : adopting Boost license

[Jacob Carlborg]

On 11/13/09 11:11, Yigal Chripun wrote:
> Don wrote:
>> Yigal Chripun wrote:
>>> Robert Jacques wrote:
>>>> On Fri, 13 Nov 2009 01:08:03 -0500, Yigal Chripun
>>>> <yigal100 at gmail.com> wrote:
>>>>
>>>>> Robert Jacques wrote:
>>>>>> The Apache 2.0 license requires attribution. It's therefore
>>>>>> unsuitable for a standard library. From the website FAQ:
>>>>>> "
>>>>>> It forbids you to:
>>>>>> redistribute any piece of Apache-originated software without
>>>>>> proper attribution;
>>>>>> use any marks owned by The Apache Software Foundation in any way
>>>>>> that might state or imply that the Foundation endorses your
>>>>>> distribution;
>>>>>> use any marks owned by The Apache Software Foundation in any way
>>>>>> that might state or imply that you created the Apache software in
>>>>>> question.
>>>>>> It requires you to:
>>>>>> include a copy of the license in any redistribution you may make
>>>>>> that includes Apache software;
>>>>>> provide clear attribution to The Apache Software Foundation for
>>>>>> any distributions that include Apache software.
>>>>>> "
>>>>>
>>>>> excerpts from http://www.apache.org/licenses/LICENSE-2.0.html
>>>>>
>>>>> "Derivative Works" shall mean any work, whether in Source or Object
>>>>> form, that is based on (or derived from) the Work and for which the
>>>>> editorial revisions, annotations, elaborations, or other
>>>>> modifications represent, as a whole, an original work of
>>>>> authorship. For the purposes of this License, Derivative Works
>>>>> shall not include works that remain separable from, or merely link
>>>>> (or bind by name) to the interfaces of, the Work and Derivative
>>>>> Works thereof.
>>>>>
>>>>> 4. Redistribution. You may reproduce and distribute copies of the
>>>>> Work or Derivative Works thereof in any medium, with or without
>>>>> modifications, and in Source or Object form, provided that You meet
>>>>> the following conditions:
>>>>>
>>>>> 1. You must give any other recipients of the Work or Derivative
>>>>> Works a copy of this License; and
>>>>>
>>>>> 2. You must cause any modified files to carry prominent notices
>>>>> stating that You changed the files; and
>>>>>
>>>>> 3. You must retain, in the Source form of any Derivative Works that
>>>>> You distribute, all copyright, patent, trademark, and attribution
>>>>> notices from the Source form of the Work, excluding those notices
>>>>> that do not pertain to any part of the Derivative Works; and
>>>>>
>>>>>
>>>>> /quote
>>>>>
>>>>> my understanding of the above is that using tango in your code
>>>>> doesn't constitute as "Derivative Works". that means that _uesrs_
>>>>> of Tango are not required to provide attribution.
>>>>
>>>> First, according to international copyright law (Berne convention),
>>>> compiling source code creates a derivative work. (See
>>>> http://en.wikipedia.org/wiki/ISC_License for some links)
>>>> Second, 4.1 explicitly require you to provide the license with all
>>>> distributions.
>>>> Third, Apache's FAQ, which was written by lawyers, instruct users to
>>>> include the license/attribution.
>>>> Finally, the linking divide, allows you link together code licensed
>>>> under different licensees. I believe the GPL also has a similar
>>>> clause. It doesn't mean that if you distribute a compiled copy of
>>>> the library (either explicitly as a dll/so or by statically linking
>>>> it in) you don't have to include the Apache license. You just don't
>>>> have to license your application which uses Tango under the Apache
>>>> license.
>>>>
>>>> There was a large discussion a while back about this, and
>>>> essentially there are only 2 licenses suitable for a standard
>>>> library: Boost and zlib/libpng (And technically WTFYW).
>>>>
>>>
>>> Ok, I ain't a layer so let's see if I understood you correctly:
>>>
>>> You're saying that if I write code using Tango, I can license *my*
>>> code with whatever I want. My source will require a tango dll to work
>>> and *that* dll must come with its apache 2.0 license file.
>>>
>>> That sounds completely reasonable to me. I don't get what the problem
>>> with this scheme of things.
>>
>> At the present time, D DLLs don't work with D apps. Only static
>> linking works. And disallowing static linking is utterly ridiculous,
>> anyway.
>>
>> Conditions 2 and 3 above are no problem. I'm a bit scared of 1,
>> though. What does "give" mean? (It's not even "make available").
>> Sounds as though EVERY D app (even "Hello, world" apps) would need to
>> include a license file for the standard library.
>>
>
> I agree, supplying the stdlib license file with a hello, world
> executable would be very bad.
>
> Generally speaking, is static linking of the stdlib the right thing?
> I realize that's the only working option now, but when this is fixed
> (and it really should be fixed) would that still be the correct choice
> for the stdlib?

For C the obvious answer is dynamic linking because the target machine 
will (almost) always have the stdlib/runtime. For D I'm not sure, static 
linking allows stand alone applications.