www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Standard third party imports

reply Adam D. Ruppe <destructionator gmail.com> writes:
I'm wondering, would be be a good idea to add some .di files to the standard
distribution, or easily accessible next to it, for some common third party C
libraries?

For example, I used import sdl.SDL in another thread yesterday to quickly port
a C toy, but most people probably can't do that since they don't have the same
collection of interface files I have.

There's other times where I write an extern(C) {} block myself with the
prototypes I use (actually this is common for me) but that's a pain if the C
function needs a lot of #defines, structs, etc. A nice group of common imports
would be, well, nice.


I'm not talking about wrappers, just interfaces. So

import etc.c.sdl.SDL;

Then use it C style: SDL_namehere and manual freeing, etc. You can use that
directly, or if you want to, wrap it in D.


Do that for a handful of common libraries. SDL, curl, mysql, a few others. On
Windows, perhaps provide the .lib files for linking to the DLL as well so
people don't have to track that down. (This doesn't require the inclusion of
any code either. It's just a function list.)



What it will *not* include is the actual libraries themselves. Nothing needs
to actually be compiled into Phobos. It's just a convenient interface to some
common C functions, like we provide to the operating system. Being just
headers, the source is included by definition and no code of it whatsoever is
compiled into Phobos itself, so it wouldn't taint anything else. (indeed,
phobos2.lib shouldn't change /at all/ by the inclusion of these files in the
proposed etc branch).

We'd still have pure Boost/public domain binaries with the standard
distribution while making more libraries a wee bit more accessible.


What do you think?
Nov 13 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Adam D. Ruppe (destructionator gmail.com)'s article
 I'm wondering, would be be a good idea to add some .di files to the standard
 distribution, or easily accessible next to it, for some common third party C
 libraries?
 For example, I used import sdl.SDL in another thread yesterday to quickly port
 a C toy, but most people probably can't do that since they don't have the same
 collection of interface files I have.
 There's other times where I write an extern(C) {} block myself with the
 prototypes I use (actually this is common for me) but that's a pain if the C
 function needs a lot of #defines, structs, etc. A nice group of common imports
 would be, well, nice.
 I'm not talking about wrappers, just interfaces. So
 import etc.c.sdl.SDL;
 Then use it C style: SDL_namehere and manual freeing, etc. You can use that
 directly, or if you want to, wrap it in D.
 Do that for a handful of common libraries. SDL, curl, mysql, a few others. On
 Windows, perhaps provide the .lib files for linking to the DLL as well so
 people don't have to track that down. (This doesn't require the inclusion of
 any code either. It's just a function list.)
 What it will *not* include is the actual libraries themselves. Nothing needs
 to actually be compiled into Phobos. It's just a convenient interface to some
 common C functions, like we provide to the operating system. Being just
 headers, the source is included by definition and no code of it whatsoever is
 compiled into Phobos itself, so it wouldn't taint anything else. (indeed,
 phobos2.lib shouldn't change /at all/ by the inclusion of these files in the
 proposed etc branch).
 We'd still have pure Boost/public domain binaries with the standard
 distribution while making more libraries a wee bit more accessible.
 What do you think?
One question here is, what's the copyright status of header files and their .di translations? I would guess, though IANAL and could easily be wrong, that header declarations (struct layouts, function prototypes, in general things where there's no actual implementation code) aren't sufficiently original to be copyrightable. If anyone knows for sure, please speak up.
Nov 13 2010
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Worst case with the copyright is to just include a copy of the license with the
zip.

The problem with BSD/GPL code in the main Phobos is any D program will link with
it, and thus the license goes viral to all D programs.

But since this is just interface files, separate from the stdlib aside from
sharing a distribution zip, no compiled code will be shoved into Phobos proper,
the copyright restrictions shouldn't affect anyone who is not specifically using
that library anyway.

If we're concerned that merely importing the file may cause license
taint, we could add pragma(msg, "License Taint Warning: etc.c.mylib is GPL
licensed");

It just seems to me that as long as it is separate from Phobos, so it remains
opt-in for each individual program, we shouldn't have anything to worry about.
Somebody setting out to use the C library has to provide the DLLs himself, so
he's
already aware of the license.
Nov 13 2010
parent reply jfd <jfd nospam.com> writes:
== Quote from Adam D. Ruppe (destructionator gmail.com)'s article
 The problem with BSD/GPL code in the main Phobos is any D program will link
with
 it, and thus the license goes viral to all D programs.
 But since this is just interface files, separate from the stdlib aside from
 sharing a distribution zip, no compiled code will be shoved into Phobos proper,
 the copyright restrictions shouldn't affect anyone who is not specifically
using
 that library anyway.
 If we're concerned that merely importing the file may cause license
 taint, we could add pragma(msg, "License Taint Warning: etc.c.mylib is GPL
licensed"); Question 1. Nearly-Verbatim Translation: Make nearly one-to-one translation, for example, use a D function for a .h macro, and a D const for a .h #define of a constant. That looks close to the original .h, in visual form and style. Does that fall under the .h license? And that is the example on the D web site! One doesn't usually consider that subject to the .h license terms. Or is that assumption wrong? Question 2. Preprocessing .h: If one preprocesses the .h, instead of verbatim one-to-one translation, would that be still subject to the .h license? It doesn't look very much like the original .h, in terms of visual style and form, certainly less than the "verbatim" way above. Question 3. Automation: If a program produces a .di file that is identical to what would write by hand, then does automation make any difference in license terms than a hand-written one? I'm not a lawyer, but I tend to think that a translation of .h is not subject to the original license. If I'm not mistaken, I seem to recall that some libc headers on some platforms (Mac?) are pretty much re-written glibc headers, and the new headers are under proprietary license. It's good to clarify that, before I start spending lots of time building headers. Thank you for bringing this up.
Nov 13 2010
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
jdf wrote:
 Question 1. Nearly-Verbatim Translation:
 Does that fall under the .h license?
Yes, since it is a derivative work. Same for questions 2 and 3 - they are all based on the original .h, so they all inherit its license too. The only file currently in the etc.c package is zlib.d, a direct translation of zlib.h. It has the original copyright notice at the top of it. I don't think the license on the .h is terribly important though, since it won't carry over into the D application automatically. Only if you actually use the import would it apply to you. That's unacceptable for regular Phobos, since all D applications get that code compiled into their binary. But for just some bindings, distributed with, but completely separate from druntime and Phobos in the binary, the individual program is under its own thing. It'd be conveniently available, and stuck under its own license, but also independent from the rest of D - you only worry about the license if you actually use it.
Nov 13 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
jfd wrote:
 =3D=3D Quote from Adam D. Ruppe (destructionator gmail.com)'s article
 The problem with BSD/GPL code in the main Phobos is any D program will=
link with
 it, and thus the license goes viral to all D programs.
 But since this is just interface files, separate from the stdlib aside=
from
 sharing a distribution zip, no compiled code will be shoved into Phobo=
s proper,
 the copyright restrictions shouldn't affect anyone who is not specific=
ally using
 that library anyway.
 If we're concerned that merely importing the file may cause license
 taint, we could add pragma(msg, "License Taint Warning: etc.c.mylib is=
GPL
 licensed");
=20
 Question 1. Nearly-Verbatim Translation:  Make nearly one-to-one transl=
ation, for
 example, use a D function for a .h macro, and a D const for a .h #defin=
e of a
 constant.  That looks close to the original .h, in visual form and styl=
e. Does
 that fall under the .h license?
=20
 And that is the example on the D web site!  One doesn't usually conside=
r that
 subject to the .h license terms.  Or is that assumption wrong?
=20
 Question 2. Preprocessing .h: If one preprocesses the .h, instead of ve=
rbatim
 one-to-one translation, would that be still subject to the .h license? =
It doesn't
 look very much like the original .h, in terms of visual style and form,=
certainly
 less than the "verbatim" way above.
=20
 Question 3. Automation: If a program produces a .di file that is identi=
cal to what
 would write by hand, then does automation make any difference in licens=
e terms
 than a hand-written one?
=20
 I'm not a lawyer, but I tend to think that a translation of .h is not s=
ubject to
 the original license.  If I'm not mistaken, I seem to recall that some =
libc
 headers on some platforms (Mac?) are pretty much re-written glibc heade=
rs, and the
 new headers are under proprietary license.
=20
 It's good to clarify that, before I start spending lots of time buildin=
g headers.
  Thank you for bringing this up.
I am not a lawyer either, but I believe that from a strictly legal standpoint, the original license applies in all three cases. From a practical standpoint, there are two possible situations: * The header file contains only interface declarations. In that case, the important license to consider is that of the actual library it is an interface for. Nobody will blame you for translating the header in order to access the library provided you respect the license of the library. Moreover, a good lawyer would probably be able to argue the case convincingly if it came to that (but as I said, IANAL); * The header file contains implementation (for a C++ template-heavy library for example). In that case, the header license definitely applies to any translation. The situation is complicated by the fact that most open source licenses do not take this situation into account (AIUI, it is one of the big differences between LGPLv2 and LGPLv3). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Nov 14 2010
prev sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
dsimcha wrote:
 == Quote from Adam D. Ruppe (destructionator gmail.com)'s article
 I'm wondering, would be be a good idea to add some .di files to the standard
 distribution, or easily accessible next to it, for some common third party C
 libraries?
 For example, I used import sdl.SDL in another thread yesterday to quickly port
 a C toy, but most people probably can't do that since they don't have the same
 collection of interface files I have.
 There's other times where I write an extern(C) {} block myself with the
 prototypes I use (actually this is common for me) but that's a pain if the C
 function needs a lot of #defines, structs, etc. A nice group of common imports
 would be, well, nice.
 I'm not talking about wrappers, just interfaces. So
 import etc.c.sdl.SDL;
 Then use it C style: SDL_namehere and manual freeing, etc. You can use that
 directly, or if you want to, wrap it in D.
 Do that for a handful of common libraries. SDL, curl, mysql, a few others. On
 Windows, perhaps provide the .lib files for linking to the DLL as well so
 people don't have to track that down. (This doesn't require the inclusion of
 any code either. It's just a function list.)
 What it will *not* include is the actual libraries themselves. Nothing needs
 to actually be compiled into Phobos. It's just a convenient interface to some
 common C functions, like we provide to the operating system. Being just
 headers, the source is included by definition and no code of it whatsoever is
 compiled into Phobos itself, so it wouldn't taint anything else. (indeed,
 phobos2.lib shouldn't change /at all/ by the inclusion of these files in the
 proposed etc branch).
 We'd still have pure Boost/public domain binaries with the standard
 distribution while making more libraries a wee bit more accessible.
 What do you think?
One question here is, what's the copyright status of header files and their .di translations? I would guess, though IANAL and could easily be wrong, that header declarations (struct layouts, function prototypes, in general things where there's no actual implementation code) aren't sufficiently original to be copyrightable. If anyone knows for sure, please speak up.
AFAIK, licenses mostly cover implementation code. This is where, e.g. LGPL terms grow from. And if license limits *overall usage*, it is likely to be proprietary anyway. For common open-source libs like SDL, xlib, enet, etc. I see no harm in having *interface* to them adapted for a particular language (D in this case). Otherwise, what right have existing bindings for other language for their, uh, existence? Take Tao as example (it's a bunch of interfaces/wrappers for Mono). BTW, I have some hand-converted (linux) ptrace and xlib declarations, in case it is of interest :)
Nov 13 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-11-13 17:43, Adam D. Ruppe wrote:
 I'm wondering, would be be a good idea to add some .di files to the standard
 distribution, or easily accessible next to it, for some common third party C
 libraries?

 For example, I used import sdl.SDL in another thread yesterday to quickly port
 a C toy, but most people probably can't do that since they don't have the same
 collection of interface files I have.

 There's other times where I write an extern(C) {} block myself with the
 prototypes I use (actually this is common for me) but that's a pain if the C
 function needs a lot of #defines, structs, etc. A nice group of common imports
 would be, well, nice.


 I'm not talking about wrappers, just interfaces. So

 import etc.c.sdl.SDL;

 Then use it C style: SDL_namehere and manual freeing, etc. You can use that
 directly, or if you want to, wrap it in D.


 Do that for a handful of common libraries. SDL, curl, mysql, a few others. On
 Windows, perhaps provide the .lib files for linking to the DLL as well so
 people don't have to track that down. (This doesn't require the inclusion of
 any code either. It's just a function list.)



 What it will *not* include is the actual libraries themselves. Nothing needs
 to actually be compiled into Phobos. It's just a convenient interface to some
 common C functions, like we provide to the operating system. Being just
 headers, the source is included by definition and no code of it whatsoever is
 compiled into Phobos itself, so it wouldn't taint anything else. (indeed,
 phobos2.lib shouldn't change /at all/ by the inclusion of these files in the
 proposed etc branch).

 We'd still have pure Boost/public domain binaries with the standard
 distribution while making more libraries a wee bit more accessible.


 What do you think?
Derelict contains bindings to SDL and various other libraries like OpenGL, OpenAL and other. "bindings" is a project on dsource that, as the name suggests, contains bindings to various libraries. -- /Jacob Carlborg
Nov 14 2010