digitalmars.D - Standard third party imports
- Adam D. Ruppe (28/28) Nov 13 2010 I'm wondering, would be be a good idea to add some .di files to the stan...
- dsimcha (6/34) Nov 13 2010 One question here is, what's the copyright status of header files and th...
- Adam D. Ruppe (13/13) Nov 13 2010 Worst case with the copyright is to just include a copy of the license w...
- jfd (21/29) Nov 13 2010 licensed");
- Adam Ruppe (19/21) Nov 13 2010 Yes, since it is a derivative work. Same for questions
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (40/75) Nov 14 2010 from
- Stanislav Blinov (10/45) Nov 13 2010 AFAIK, licenses mostly cover implementation code. This is where, e.g.
- Jacob Carlborg (6/34) Nov 14 2010 Derelict contains bindings to SDL and various other libraries like
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
== Quote from Adam D. Ruppe (destructionator gmail.com)'s articleI'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
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
== Quote from Adam D. Ruppe (destructionator gmail.com)'s articleThe 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 GPLlicensed"); 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
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
jfd wrote:=3D=3D Quote from Adam D. Ruppe (destructionator gmail.com)'s articlelink withThe problem with BSD/GPL code in the main Phobos is any D program will=fromit, and thus the license goes viral to all D programs. But since this is just interface files, separate from the stdlib aside=s proper,sharing a distribution zip, no compiled code will be shoved into Phobo=ally usingthe copyright restrictions shouldn't affect anyone who is not specific=GPLthat 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=licensed"); =20 Question 1. Nearly-Verbatim Translation: Make nearly one-to-one transl=ation, forexample, use a D function for a .h macro, and a D const for a .h #defin=e of aconstant. That looks close to the original .h, in visual form and styl=e. Doesthat fall under the .h license? =20 And that is the example on the D web site! One doesn't usually conside=r thatsubject to the .h license terms. Or is that assumption wrong? =20 Question 2. Preprocessing .h: If one preprocesses the .h, instead of ve=rbatimone-to-one translation, would that be still subject to the .h license? =It doesn'tlook very much like the original .h, in terms of visual style and form,=certainlyless than the "verbatim" way above. =20 Question 3. Automation: If a program produces a .di file that is identi=cal to whatwould write by hand, then does automation make any difference in licens=e termsthan a hand-written one? =20 I'm not a lawyer, but I tend to think that a translation of .h is not s=ubject tothe original license. If I'm not mistaken, I seem to recall that some =libcheaders on some platforms (Mac?) are pretty much re-written glibc heade=rs, and thenew 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
dsimcha wrote:== Quote from Adam D. Ruppe (destructionator gmail.com)'s articleAFAIK, 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 :)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
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