[OT] open-source license issues

Steven Schveighoffer schveiguy at yahoo.com
Tue Apr 12 07:26:25 PDT 2011


On Tue, 12 Apr 2011 04:20:44 -0400, spir <denis.spir at gmail.com> wrote:

> On 04/12/2011 01:47 AM, Nick Sabalausky wrote:
>> "Jonas Drewsen"<jdrewsen at nospam.com>  wrote in message
>> news:invnrn$2pgf$1 at digitalmars.com...
>>> On 11/04/11 22.01, Steven Schveighoffer wrote:
>>>> On Mon, 11 Apr 2011 13:05:24 -0400, Russel  
>>>> Winder<russel at russel.org.uk>
>>>> wrote:
>>>>
>>>>> On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
>>>>> [ . . . ]
>>>>>> fine, but a standard library is distributed with D programs. LGPL
>>>>>> requires you to send source when distributing the library.
>>>>>
>>>>> I would have to check but as far as I remember the (L)GPL does not
>>>>> require you to distribute the source with the compiled form if that  
>>>>> is
>>>>> what is distributed, it requires that the end user can get the source
>>>>> for the compiled form. From a distribution perspective these are very
>>>>> different things. cf. The Maven Repository, which distributes masses  
>>>>> of
>>>>> compiled jar files and no source in sight.
>>>>
>>>> IIUC, the LGPL is like applying the GPL to the library, but does not
>>>> restrict proprietary software from linking to it. I think this means  
>>>> you
>>>> can distribute your proprietary software without providing source  
>>>> code.
>>>> However, if you supply the library (which is covered under the same
>>>> rules as the GPL), then you must provide or provide upon request the
>>>> source code to the LGPL-covered library. If you don't ship the  
>>>> library,
>>>> then you don't have to supply the source code, but then you are  
>>>> shipping
>>>> a binary that doesn't work unless they also download the LGPL library
>>>> separately.
>>>>
>>>> It all adds up to "not going to be in druntime/Phobos" :)
>>>>
>>>
>>> Actually, if you haven't made any changes to the LGPL library that you  
>>> are
>>> distribution then you can just refer to the projects homepage for the
>>> source code.
>>>
>>> This also means that putting the list of URLs for the used LGPL  
>>> libraries
>>> in the Phobos packages would suffice. Can't get much easier than that.
>>>
>>
>> Sounds like a pain for the users of Phobos (and maybe the users of
>> Phobos-developed software?).
>
> I don't understand where the pain lies, here.

The requirement of the *end user* of phobos (i.e. the developer) to have  
to provide means to download/access the library.  For instance, if I make  
a boxed game written in D, I also have to worry about LGPL and making sure  
the end user (who likely cares not at all about the LGPL'd library) can  
access the source.  This means putting their license and either source  
code or link to the source code in my documentation.  It might be worth it  
if I want that library badly enough, but it shouldn't be *required* just  
for writing code in the D language.

A language should be free of such encumbrances.  A language is a tool, and  
should not require special licensing for the end user to pass on to their  
clients.  The *tools* to use the language can be whatever license you  
want, but the user's resulting product should be able to be licensed  
however they want.  This, BTW, is why BSD is not acceptable for Phobos.   
The requirement to put the license in the documentation (even if you  
distribute binary-only) is no good.  Yes, people have said that you can  
embed the license in the binary via a string, but the stigma is still  
there.  There are some companies that will balk at that requirement.  D  
should be available to anyone who wants to use it.

-Steve


More information about the Digitalmars-d mailing list