| View previous topic :: View next topic |
| Author |
Message |
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
 Posted: Wed May 26, 2004 5:08 am Post subject: SDL & LGPL |
 |
|
I'm not entirely clear on how the LGPL will affect DerelictSDL. My understanding is that DerelictSDL will need to be released under the LGPL since it is a derived work of the SDL. So the big question is, how does this affect projects which use DerelictSDL since it can't be dynamically linked? Or is this all nothing to worry about since it is just a drop-in replacement for the import lib?
At any rate, I won't be cheking in any SDL code until I've gotten this cleared up. I've fired off an email to Sam Lantinga to see what he says. Once I get his view on the matter, I'll post here. I've never been a fan of either GPL or LGPL. BSD/ZLib/MIT and their ilk are all so much easier to deal with.
It looks like, utlimately, each Derelict package will be released under the same license as the library it interfaces with. GPL is out. If LGPL is safe (meaning Derelict users aren't required to go LGPL as well) then great. If not, the that means no LGPLed libraries will have an interface in Derelict. And I need to really review that OSI license for the OpenGL stuff now that I think about it. |
|
| Back to top |
|
 |
andy
Joined: 15 Mar 2004
Posts: 71
|
| Posted: Wed May 26, 2004 10:23 pm Post subject: |
|
|
LGPL is real simple. Basically, it's exactly the same as the GPL, except that you can use the library without relicensing your own code, provided that other folks can update the version of the library used with your software somehow. Dynamic linking satisfies this requirement; the end user merely needs to replace the DLL. A full source release does as well, obviously.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
| Posted: Thu May 27, 2004 1:26 am Post subject: |
|
|
| andy wrote: | | Basically, it's exactly the same as the GPL, except that you can use the library without relicensing your own code, provided that other folks can update the version of the library used with your software somehow. Dynamic linking satisfies this requirement; the end user merely needs to replace the DLL. |
Right, and that's what's throwing me for a loop. I understand the LGPL in the context of SDL itself, but how does it apply to the DerelictSDL module? Derelict users will either link statically with DerelictSDL.lib, or include it in their projects directly. And Derelict must be LGPL since it derived from SDL, correct? |
|
| Back to top |
|
|
Crispy
Joined: 26 Nov 2005
Posts: 67
|
| Posted: Wed Apr 19, 2006 2:15 am Post subject: |
|
|
*casts Raise Thread*
Sorry for the massive necromancy, but I wanted to discuss this issue and it makes sense to me to keep the discussion on the one thread.
Did you get an answer from Sam Lantinga in the end?
This paragraph from another thread (http://www.dsource.org/forums/viewtopic.php?t=1398&highlight=lgpl) is also relevant:
| aldacron wrote: | | Liscensing is also a big concern. I'm well aware that the common interpretation of the LGPL is that one need not release the source of an application when linking dynamically to an LGPLed library. But I do not yet know how that applies to D bindings as no one has given me a definitive answer. The issue is that the D modules themselves are compiled into object files and because they are created from LGPLed headers they must also be under LGPL. So when you use DerelictSDL you are linking directly with LGPLed object files. Many of the C macros have been rewritten as D functions. So how can this be interpreted? Are the D modules equivalent to C headers (which basically get inserted into C source modules, with expanded macros)? Or are the D modules considered statically linked objects? If the latter is true, then any D apps using any SDL bindings will be forced to release their source under the LGPL. Until I get a definitive answer, I want to minimize the amount of LGPLed code in Derelict. |
I've been researching this issue and I've come across a related issue with the Wine project. Their problem was that they wanted to be able to write replacements for Microsoft's libraries; but they weren't able to include Microsoft's header files into their projects directly (thus just having to rewrite the functionality and not the macros and function prototypes), since Microsoft has very a restrictive policy on the redistribution of their header files.
So they simply rewrote the header files. As one post on the mailing list states: (http://www.winehq.com/hypermail/wine-license/2002/09/0001.html)
| Quote: | I'm note sure what you are after. Wine does not use the
Microsoft headers so their license is irrelevant.
Sure we Wine developer READ the Microsoft headers and
then write our own headers based on the facts contained
in the headers.
Note that copyright doesn't protected facts
so the Wine header are not a derived work of the
Microsoft headers. |
In other words: They can rewrite the headers themselves without Microsoft's licence applying. Surely the same logic applies to Derelict and LGPL; the SDL headers are LGPLed, but the Derelict source code doesn't actually contain any code that's been copied from the SDL headers; any #defined macros/constants have been completely rewritten (as functions or as const variables), the function prototypes are gone and replaced with typedefs, etc.
Therefore I would argue that the Derelict source code is not a derivative work of SDL, and so you are not required to apply the LGPL to it. It's irrelevant whether it's considered a header file, because the LGPL does not even apply. It doesn't cross the linkage boundary from the LGPL'd DLL either, since the DLL is linked dynamically; Derelict is merely a "work that uses the Library", which is not a derivative work of the library:
| LGPL wrote: | | 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. |
There's one problem: Several DerelictSDL modules contain the LGPL preamble and state that the copyright over them belongs to Sam Lantinga. However, I think this can be removed, and there are a couple of reasons why:
Firstly, Sam Lantinga didn't write any of them (because of the logic above), so that part can go. Secondly, since you wrote the module yourself, you have the right to licence it to anyone you like under different terms. Therefore you can delete the LGPL preamble and replace it with whatever licence you like. (Or perhaps it would be safer to include an option, since GPLed code can't be "taken back" and the same might apply to LGPL - "You may, at your option, use this library under the terms of either the LGPL or of the [insert other licence here].")
The usual qualifier applies ("I am not a lawyer"), but based on my understanding of the LGPL and legal matters in general I think my interpretation is accurate.
So I would ask that you either point out any flaws in my argument, or remove the LGPL notice (since I would very much like to use Derelict, including DerelictSDL, DerelictSDLImage, DerelictSDLMixer etc. in a commercial product).  |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Wed Apr 19, 2006 6:08 am Post subject: |
|
|
I agree with crispy, Derelict is all about dynamic loading and thus there shouldn't be any real problems to include bindings for any LGPL libraries, although you might want to write the bindings in a "black box" manner rather than regexp'ing them from some original headers.
Note that the MinGW project took a much more masochistic approach to creating the MS headers, compared to the Wine-comments above...
But AFAIK, as long as the bindings in Derelict work without needing any source files from the SDL-packages, that is you only need to download precompiled libraries, it should be ok. It's not as if LGPL-libraries are never used in commercial/closed apps, see Safari that uses khtml, etc. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
| Posted: Wed Apr 19, 2006 2:46 pm Post subject: |
|
|
| Crispy wrote: |
Did you get an answer from Sam Lantinga in the end?
|
Never did.
| Crispy wrote: |
Therefore I would argue that the Derelict source code is not a derivative work of SDL, and so you are not required to apply the LGPL to it. It's irrelevant whether it's considered a header file, because the LGPL does not even apply. It doesn't cross the linkage boundary from the LGPL'd DLL either, since the DLL is linked dynamically; Derelict is merely a "work that uses the Library", which is not a derivative work of the library:
| LGPL wrote: | | 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. |
|
I disagree with you. Derelict doesn't use SDL at all. The DerelictSDL modules are essentially modifications of the SDL headers and therefore must be released under the LGPL. If you look at other SDL bindings for other languages, they are all under the LGPL. I appreciate the Wine example, but that is irrelevant here as the MS License and the LGPL are two different beasts.
Sections 2a and 2c of the LGPL apply here:
| Quote: |
a) The modified work must itself be a software library.
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
|
| Crispy wrote: |
There's one problem: Several DerelictSDL modules contain the LGPL preamble and state that the copyright over them belongs to Sam Lantinga. However, I think this can be removed, and there are a couple of reasons why:Firstly, Sam Lantinga didn't write any of them (because of the logic above), so that part can go. |
There's no explicit requirement in the LGPL that I know of that says the original source copyright must remain, however every project I've ever seen that derives from an LGPLed or GPLed codebase keeps it around in one form or another. I have copied the source headers verbatim because Sam did create the original code. All I did here was translate the headers. What I haven't done yet is comply with section 2b:
| Quote: | | b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. |
I normally do this by putting a statement at the top of the source file that this is a modified version of code originally copyrighted to so-and-so, modified by me starting from such-and-such time. I actually need to do that here.
| Crispy wrote: | | Secondly, since you wrote the module yourself, you have the right to licence it to anyone you like under different terms. Therefore you can delete the LGPL preamble and replace it with whatever licence you like. (Or perhaps it would be safer to include an option, since GPLed code can't be "taken back" and the same might apply to LGPL - "You may, at your option, use this library under the terms of either the LGPL or of the [insert other licence here].") |
If that were true, then the LGPL would be dead in the water. I did not write the module myself. I translated another author's existing C source to D. It is not my creation at all. I am only allowd to license under the LGPL, or (as per section 3) the GPL.
| Quote: | | So I would ask that you either point out any flaws in my argument, or remove the LGPL notice (since I would very much like to use Derelict, including DerelictSDL, DerelictSDLImage, DerelictSDLMixer etc. in a commercial product). |
I have to opted for the former, as I cannot remove the LGPL notices. I have never doubted that the DerelictSDL* must all be subject to the LGPL. That point is not debatable. The real problem lies with section 5 of the LGPL as it applies to D applications that use DerelictSDL:
| Quote: | | When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. |
Now, if we assume that the DerelictSDL* modules are equivalent to header files, then the next paragraph of section 5 can be applied:
| Quote: | | If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) |
If only it were that easy.
There are two obvious flaws with the above:
1) Headers in C are not converted to object files directly. D modules are. From that perspective D modules are not the same as header files.
2) Even if we can treat D modules the same as C headers, there are no macros or inline functions in D. Functions are inlined by the compiler with no input from the programmer. If none of the converted macros are inlined, then the application will be calling into the DerelictSDL object code when those functions are called.
So there's the rub. The object code for the modules is always linked in to any application that uses DerelictSDL. And while it is a nice attempt at a work around to say that the D modules don't really need to be LGPLed, that just isn't the case.
There was a similar issue with Java some time ago. Remembering that, your post inspired me to do a little research and I have discovered that my understanding of the LGPL was wrong on one point. You don't need to release your application under the LGPL when linking with an LGPLed library (not sure why that was stuck in my head), but as per section 6a any license you do use needs to permit users to link new or modified versions of the library by making either the object code or the source available.
For reference, here's section 6a:
| Quote: | | a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) |
In this article about the LGPL and how it applies to Java, Dave Turner says "the LGPL works as intended with all known programming languages". Following through, there is this paragraph:
| Quote: |
If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that -- people who modify the library are responsible for making it work.
When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library. |
If you read the LGPL & Java article in depth, you'll see how he describes that Java's import mechanism creates a link between the Java method signatures and the application that uses the imported classes. With that in mind, I think it's safe to assume now that the D modules are indeed linked into the application and that section 6a applies to any application using DerelictSDL*.
The only way I can see around this is to truly make DerelictSDL* into shared libraries themselves, in which case section 6b of the LGPL would apply as normal.
Rather than the SDL stuff, you might want to go with GLFW, DevIL, and OpenAL instead. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
| Posted: Wed Apr 19, 2006 3:02 pm Post subject: |
|
|
| larsivi wrote: | | I agree with crispy, Derelict is all about dynamic loading and thus there shouldn't be any real problems to include bindings for any LGPL libraries, although you might want to write the bindings in a "black box" manner rather than regexp'ing them from some original headers. |
Yeah, well, I didn't regexp anything I did it all by hand.
| larsivi wrote: | | But AFAIK, as long as the bindings in Derelict work without needing any source files from the SDL-packages, that is you only need to download precompiled libraries, it should be ok. It's not as if LGPL-libraries are never used in commercial/closed apps, see Safari that uses khtml, etc. |
You're coming at it from the wrong perspective. The distinguishing factor is that DerelictSDL is not "a work that uses the library", but is instead a modification of the library. Any application that uses DerelictSDL might then be said to be "a work that uses the library", but the linkage with D object files causes issues. See my above post for the rest. |
|
| Back to top |
|
|
larsivi
Site Admin
Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway
|
| Posted: Wed Apr 19, 2006 3:31 pm Post subject: |
|
|
| So what you are saying is tha SDL don't come as a DLL/SO which you can load functions from using dlopen/LoadLibrary? I can't see how DerelicSDL in any way can be a derived work of SDL, you haven't reimplemented the core functions of that library in any way. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
| Posted: Wed Apr 19, 2006 9:08 pm Post subject: |
|
|
| larsivi wrote: | | So what you are saying is tha SDL don't come as a DLL/SO which you can load functions from using dlopen/LoadLibrary? |
No, that's not what I'm saying.
| Quote: | | I can't see how DerelicSDL in any way can be a derived work of SDL, you haven't reimplemented the core functions of that library in any way. |
You don't have to reimplement the core functions or even touch them to be a derivative work. The headers are just as much under the LGPL as the source modules are. By translating the headers to D I have modified them. Modifications of LGPLed source must be released as a library under the LGPL.
In a nutshell, DerelictSDL is a library which contains modified SDL code. The fact that Derelict loads the DLL dynamically has no bearing on the situation whatsoever. DerelictSDL does not qualify as a work that uses the library. The relevant portions of the LGPL that I quoted above make that perfectly clear. |
|
| Back to top |
|
|
Crispy
Joined: 26 Nov 2005
Posts: 67
|
| Posted: Wed Apr 19, 2006 10:13 pm Post subject: |
|
|
| aldacron wrote: | | Crispy wrote: |
Did you get an answer from Sam Lantinga in the end?
|
Never did. |
That's a shame. It would be nice to have his input on the matter.
| aldacron wrote: | | I disagree with you. Derelict doesn't use SDL at all. |
For the purpose of the licence it does, since (1) it contains no derivative of any portion of the Library (I know you disagree with me on this, but I'll get to that in a moment), and (2) it is designed to work with the Library by being [...] linked with it (partially quoting from the LGPL here, section 5).
| aldacron wrote: | | If you look at other SDL bindings for other languages, they are all under the LGPL. |
I'm afraid not. Take a look at this binding for Pascal, called JEDI-SDL:
http://cvs.sourceforge.net/viewcvs.py/jedi-sdl/JEDI-SDL/SDL/Pas/SDL.pas?view=markup
No LGPL here! They're using the Mozilla Public Licence, which appears to be similar in concept, but it's not the LGPL, and the LGPL does not allow the MPL to be substituted in place of the LGPL. The choice to use MPL was their choice, not one that LGPL forced upon them; they could have used a BSD-style licence, or made it public domain if they'd wanted.
I'm not very good at reading Pascal, but it seems to me that they are linking to the SDL libraries in exactly the same way as Derelict does. Under "requirements" in the comment header it says it requires "The SDL Runtime libraris [sic] on Win32 : SDL.dll on Linux : libSDL.so", just like Derelict does; and there are what appear to be function pointers in the code, just like Derelict.
If JEDI-SDL is not a derivative work of SDL (and those guys certainly appear to think so), then Derelict isn't either. Therefore sections 2a and 2c do not apply.
| aldacron wrote: | | I appreciate the Wine example, but that is irrelevant here as the MS License and the LGPL are two different beasts. |
I think it is relevant if you consider Derelict as not being a derivative work of SDL, as I'm asserting. Obviously if it is a derivative work then you are correct; this is really the bone of contention. If Derelict is a derivative work of SDL, then the rest of your argument follows logically and therefore Derelict needs to be LGPLed; if not, then the rest of my argument follows logically and therefore it doesn't.
| aldacron wrote: | | I did not write the module myself. I translated another author's existing C source to D. |
It is my opinion that this translation created an entirely new work, rather than a derived one. The C headers and the D modules you wrote to replace them are very different beasts. They may have the same purpose, but this is irrelevant, since one cannot copyright a purpose. They have certain key phrases in common, but the entire structure and function is completely changed.
| aldacron wrote: | | I have to opted for the former, as I cannot remove the LGPL notices. I have never doubted that the DerelictSDL* must all be subject to the LGPL. That point is not debatable. |
Evidently I disagree.
| aldacron wrote: | | The real problem lies with section 5 of the LGPL as it applies to D applications that use DerelictSDL: |
I do understand what you mean here, and I don't have an answer as to whether it applies, so I understand your caution. I don't know whether it's possible to arrive at a clear answer to whether section 5 applies without first establishing a legal precedent in court, since the LGPL is so darned woolly on this point. I really wish they had thought more carefully before writing section 5.
This is why I went looking for another way to prevent the LGPL from applying here. I hope we can agree that linking a D application to SDL using Derelict and considering that application as a "work that uses the Library" (as opposed to a "derivative work") does not violate the spirit of the LGPL (assuming for the sake of argument that Derelict does inherit the LGPL), since anyone can compile their own version of the SDL DLL and drop it straight in without having source code access. The point we're disagreeing on is whether it violates the letter of the licence. Unfortunately it is the letter of the licence that applies.
| aldacron wrote: | | There was a similar issue with Java some time ago. [...] The only way I can see around this is to truly make DerelictSDL* into shared libraries themselves, in which case section 6b of the LGPL would apply as normal. |
Okay, so let's pretend for a moment DerelictSDL* has been compiled as a shared library. How do we access the functions inside it?
Well, there are a couple of ways, but we need to know the function signatures, so we either need function declarations or function pointers. Oh, and we need to define the constants and structs as well. Hmm... sound familiar? It serves the same purpose as a C header file. And by your logic, since the function declarations and constants and such are from Sam Lantinga's header files, our application which links to DerelictSDL* is also a derivative work of SDL, and must be LGPLed! If we try to avoid the propagation of the licence by dynamically linking another "buffer" library in between, the entire cycle of logic loops around again. It's infinitely recursive and there's no escape...
My point? If you take your argument to its logical conclusion, then the LGPL essentially reduces to the GPL in this situation. You're trying to find some kind of middle ground where Derelict inherits LGPL but doesn't necessarily pass it on itself, and I don't believe that middle ground exists. Either Derelict and everything that uses it is LGPL, or the LGPL only covers SDL itself and does not propagate to Derelict. One extreme or the other.
| aldacron wrote: | | Rather than the SDL stuff, you might want to go with GLFW, DevIL, and OpenAL instead. |
I would really rather not have to do that. 
(I forgot to mention SDL_ttf - I am using SDL_net as well, but via another library written in C - NET2 - which is thankfully not LGPLed. So I'd have to deal with FreeType as well, which looks painful.)
This is a bad order for me to present my arguments in, so allow me to summarise: The key point here is that I believe DerelictSDL* does not need to be LGPLed. I have backed this up by arguing that the DerelictSDL* modules are sufficiently different from SDL as to not create a derivative work. To support this point of view, I have also pointed out that the JEDI-SDL bindings take a similar approach to Derelict's, and are not licenced under the LGPL, so I am not alone in my interpretation.
I hope we can keep this debate civil, as it was not my intention to start a flame war. I know I can sometimes unintentionally sound hostile, so if I sound like I'm attacking you, please understand that I don't mean to, and I respect you for all of the work you've done. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
| Posted: Thu Apr 20, 2006 8:26 am Post subject: |
|
|
I understand where you're coming from. I went throught the list of language bindings at libsdl.org and found that there are actually a few that are released under less restrictive licenses, though most are either LGPL or GPL. That just muddies the waters more for me.
I've resubscribed to the SDL mailing list (been off of it for a long time) and I'm going to pose the question there. I'm sure I'll get conflicting answers, but it's worth a shot.
If your argument is correct, then I think I can extrapolate and apply the same logic to every Derelict package. That would allow me to release the entire set of packages under a BSD style license, which is much more palatable. But I still can't get past the fact that, in my mind, DerelictSDL is not a new work but a modified version of the original. That's the only thing that makes sense to me.
I'm crossing my fingers that I'm wrong, though. |
|
| Back to top |
|
|
clayasaurus
Joined: 21 May 2004
Posts: 857
|
| Posted: Thu Apr 20, 2006 10:59 am Post subject: |
|
|
| What's the problem with LGPL anyways? You can still use it in commercial applications as long as you load it from the .dll or .so. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
| Posted: Thu Apr 20, 2006 11:45 am Post subject: |
|
|
| clayasaurus wrote: | | What's the problem with LGPL anyways? You can still use it in commercial applications as long as you load it from the .dll or .so. |
Right, but that isn't the issue here. The issue has been - is DerelictSDL a modification of SDL or a "work that uses the library" as described in the LGPL? In the latter case, there's no problem and loading it as a shared library is fine. In the former case, DerelictSDL would also need to be LGPL. And since D modules are statically linked, DerelictSDL would not be dynamically loaded by D applications - so the LGPL would require that such applications release the source or make object files available.
BTW, nothing stops you from using an LGPLed library in a commercial application even if you statically linked. Neither LGPL nor GPL mean "non-commercial". If you were to make a game using the GPLed Quake 3 source and sell it, that would be fine. You'd just have to abide by the terms of the GPL and make your source available to everyone who has a copy of your ececutable. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1066
Location: Seoul, South Korea
|
| Posted: Thu Apr 20, 2006 11:53 am Post subject: |
|
|
We can put this whole matter to bed now. I got a response from Sam to the question I posed on the SDL mailing list:
| Sam Lantinga wrote: | The API is not copyrighted, only the SDL implementation is. I would consider
this a work that uses the library, rather than a derivative work. You'll
notice that using inline functions in LGPL headers, which technically
places code from those headers in your object code, also does not change
your work into a derivative work - it remains a work that uses the library. |
Thanks, Crispy and larsivi for resurrecting this topic and challenging me on it. I still can't wrap my head around the fact that a port to another language is not a modification, but if I twist it so that I view the headers in the same light as a Java interface or API, then things look better (i.e. you can implement your own version of any Java API).
With the new perspective, I'm going to go through and get rid of any other license references (though I need to double check the OpenGL license) and release all of Derelict under a BSD license. Then D applications can use Derelict hassle-free. |
|
| Back to top |
|
|
Crispy
Joined: 26 Nov 2005
Posts: 67
|
| Posted: Thu Apr 20, 2006 8:49 pm Post subject: |
|
|
Awesome! Totally, totally awesome.
This news has made my day.
| Quote: | | Thanks, Crispy and larsivi for resurrecting this topic and challenging me on it. |
My pleasure!  |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
