Re: [fpc-devel] graph module
Evgeniy Ivanov wrote: released under the LGPL. However the relevant LGPL provisions do not address all possible ways in which code released under the MPL and code released under the LGPL could be combined to form a larger work. In particular, when linking Mozilla source files directly into a library released under the LGPL, e.g., to extend the functionality of that This is why we have the exception. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Mon, 12 Mar 2007 11:04:00 +0300, Micha Nelissen [EMAIL PROTECTED] wrote: Evgeniy Ivanov wrote: released under the LGPL. However the relevant LGPL provisions do not address all possible ways in which code released under the MPL and code released under the LGPL could be combined to form a larger work. In particular, when linking Mozilla source files directly into a library released under the LGPL, e.g., to extend the functionality of that This is why we have the exception. Sorry, I don't understand what you mean. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
Evgeniy Ivanov wrote: library released under the LGPL, e.g., to extend the functionality of that This is why we have the exception. Sorry, I don't understand what you mean. For example, look at the RTL license: http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/rtl/COPYING.FPC?rev=1view=markup It specifies the exception. Lazarus' LCL has the same exception in COPYING.modifiedLGPL IIRC. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Mon, 12 Mar 2007 19:42:36 +0300, Micha Nelissen [EMAIL PROTECTED] wrote: Evgeniy Ivanov wrote: library released under the LGPL, e.g., to extend the functionality of that This is why we have the exception. Sorry, I don't understand what you mean. For example, look at the RTL license: http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/rtl/COPYING.FPC?rev=1view=markup It specifies the exception. Lazarus' LCL has the same exception in COPYING.modifiedLGPL IIRC. Sorry, but we still don't understand each other. I was talking not about first part of sentence (you mark it red), but about ending: the effect of the LGPL terms, and any potential license incompatibilities that might arise, appear to be similar to those associated with the GPL.) And we were talking about linking MPL code to fpc, but not about fpc to some MPL. Daniël have written to Dominique, so we are waiting the answer. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Sat, 10 Mar 2007 23:12:32 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: Are the licensing issues sorted out for it? If not, there may be a problem since standard MPL is incompatible with GPL (so people can't release GPL programs using those bindings). I don't know about the LGPL (and how our static linking exception affects this). As far as I know if somebody uses MPL the product based on MPL must be only MPL. MPL is incompatible with LGPL too. http://www.mozilla.org/MPL/relicensing-faq.html There is a way to use a triple license. But as I understood we need to make all FPC code licenced as MPL/LGPL because one module uses MPL code. It is not the way. So, if we want to have sdlgraph there are 3 ways: - rewrite needed SDL headers - write SDL initialization and few base function for SDL in C and then make headers for pascal - speak with JEDI-SDL developer. But I don't know if he relized it under MPL has he right to give such permission -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
Are the licensing issues sorted out for it? If not, there may be a problem since standard MPL is incompatible with GPL (so people can't release GPL programs using those bindings). I don't know about the LGPL (and how our static linking exception affects this). As far as I know if somebody uses MPL the product based on MPL must be only MPL. MPL is incompatible with LGPL too. http://www.mozilla.org/MPL/relicensing-faq.html Where exactly? I see perceived incompability in the header, but afaik FSF only names GPL. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Mon, 12 Mar 2007 00:11:06 +0300, Marco van de Voort [EMAIL PROTECTED] wrote: Are the licensing issues sorted out for it? If not, there may be a problem since standard MPL is incompatible with GPL (so people can't release GPL programs using those bindings). I don't know about the LGPL (and how our static linking exception affects this). As far as I know if somebody uses MPL the product based on MPL must be only MPL. MPL is incompatible with LGPL too. http://www.mozilla.org/MPL/relicensing-faq.html Where exactly? I see perceived incompability in the header, but afaik FSF only names GPL. http://www.mozilla.org/MPL/relicensing-faq.html#why-relicensing === (The LGPL allows code released under LGPL terms to be combined in certain specified ways with code released under non-LGPL terms, as for example when releasing an application using a library consisting of code released under the LGPL. However the relevant LGPL provisions do not address all possible ways in which code released under the MPL and code released under the LGPL could be combined to form a larger work. In particular, when linking Mozilla source files directly into a library released under the LGPL, e.g., to extend the functionality of that library, the effect of the LGPL terms, and any potential license incompatibilities that might arise, appear to be similar to those associated with the GPL.) === -- Best regards E.I.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Sat, 10 Mar 2007 00:09:32 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: Daniel was talking about staticallu linking the interface, not the libraries themselves. Since we do not distribute the libraries, what license they are distributed under is irrelevant. The interface can be used to both link the dynamic and static library versions of SDL. OK, the conclusion is to implement sdlgraph in pascal on top of JEDI-SDL. So, I will work with it. I will finish my study activities (I was ill 2 weeks so this week (after Sunday) I will clear my debts) and then will implement it. Daniël was talking about 2.2 FPC release, what is date in team's plans? -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
OK, the conclusion is to implement sdlgraph in pascal on top of JEDI-SDL. So, I will work with it. I will finish my study activities (I was ill 2 weeks so this week (after Sunday) I will clear my debts) and then will implement it. Daniël was talking about 2.2 FPC release, what is date in team's plans? Just so you know, I just added modified SDL units from JEDI-SDL into packages/extra but only to trunk (2.3.1). I think it's best you use those and not copy your own, but we might need to merge into 2.2 later then (there's a freeze in effect now I think?) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Sat, 10 Mar 2007 13:40:31 +0300, Aleš Katona [EMAIL PROTECTED] wrote: Just so you know, I just added modified SDL units from JEDI-SDL into packages/extra but only to trunk (2.3.1). I think it's best you use those and not copy your own, but we might need to merge into 2.2 later then (there's a freeze in effect now I think?) Do you mean http://svn.freepascal.org/svn/fpc/trunk/packages/extra/sdl/ ? Yes, I will use this, as team wish. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On 10 Mar 2007, at 11:40, Aleš Katona wrote: Just so you know, I just added modified SDL units from JEDI-SDL into packages/extra but only to trunk (2.3.1). I think it's best you use those and not copy your own, but we might need to merge into 2.2 later then (there's a freeze in effect now I think?) Are the licensing issues sorted out for it? If not, there may be a problem since standard MPL is incompatible with GPL (so people can't release GPL programs using those bindings). I don't know about the LGPL (and how our static linking exception affects this). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov: Hello! I tried to use freepascal' graph module based on svgalib but from my point of view it's not comfortable: I need root prevelege or to remember what to do with *ids (uid and so on). Also I have a problems with konsole after starting programm with graph module: there is an error with input and I get much garbage inside it. I realize a test module with a few graph functions (for my needs) via SDLlib. I wrote it on C, but some code may be written on pascal. It's not bad and fully compotable with traditional graph module code. I have some problems, but I will solve them (SDL don't want to return 'keydowns'). If you like it I may realize a full and normal graph module. Test programm need to be started in the terminal (console). You need to push the key only after setting up the terminal window active. I start in in konsole. If you start it from GUI in will run and then the window will close its self. In the tar there is linux binary. Here the test ptogramm and simple graph module: http://itmo.vingrad.ru/testGraph.tar.bz2 It is in the planning to rewrite Graph on top of PTCPas. I hope to do this before 2.2 it released. In the meantime ggigraph might suit your needs. Implementing graph on top of SDL might also be an idea, but it should then be built on top of JEDI-SDL, and reuse the existing graph code. Implementing graph in C seems like a bad idea to me. Daniël Mantione___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
Daniël Mantione schrieb: It is in the planning to rewrite Graph on top of PTCPas. I hope to do this before 2.2 it released. In the meantime ggigraph might suit your needs. Then you've to hurry ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
Daniël Mantione wrote: Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov: Hi Evgeniy, I tried to use freepascal' graph module based on svgalib but from my point of view it's not comfortable: I need root prevelege or to remember what to do with *ids (uid and so on). Also I have a problems with konsole after starting programm with graph module: there is an error with input and I get much garbage inside it. I realize a test module with a few graph functions (for my needs) via SDLlib. I wrote it on C, but some code may be written on pascal. It's not bad and fully compotable with traditional graph module code. I have some problems, but I will solve them (SDL don't want to return 'keydowns'). If you like it I may realize a full and normal graph module. Test programm need to be started in the terminal (console). You need to push the key only after setting up the terminal window active. I start in in konsole. If you start it from GUI in will run and then the window will close its self. In the tar there is linux binary. Here the test ptogramm and simple graph module: http://itmo.vingrad.ru/testGraph.tar.bz2 It is in the planning to rewrite Graph on top of PTCPas. I hope to do this before 2.2 it released. In the meantime ggigraph might suit your needs. Implementing graph on top of SDL might also be an idea, but it should then be built on top of JEDI-SDL, and reuse the existing graph code. Implementing graph in C seems like a bad idea to me. I'd say that having Graph built on top of SDL would be quite useful. I agree with Daniel that implementation in Pascal would be much better choice - among others, one could use it on various platforms without having to compile C libraries on those platforms (SDL is available on quite a few of them). I believe that Daniel intended to rewrite Graph to use a driver system (similarly to what we use for threading, keyboard/video/mouse units, heap management etc.), which would allow people to use the same Graph functionalities supported by different back-ends and choose either at compile time or possibly even at run time which back-end should be used (as an example, svgalib could be used as backup option for systems not running X11, etc.). I personally wouldn't necessarily wait for PTCPas based implementation - if Daniel wants to use the driver system, it should be enough to agree on the driver interface, anything else can be done completely independently. If you implement Graph as a completely independent implementation, you could add it to contributed units (see our WWW pages), so anybody else can use it. If you do it using the driver system and want to contribute this work to FPC, I can imagine it could even become part of our SVN repository and future official FPC releases under some conditions (however, this last sentence is my personal view, not necessarily shared by the whole FPC core team). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 15:46:34 +0300, Tomas Hajny [EMAIL PROTECTED] wrote: Hi Tomas, Hi Evgeniy, I'd say that having Graph built on top of SDL would be quite useful. I agree with Daniel that implementation in Pascal would be much better choice - among others, one could use it on various platforms without having to compile C libraries on those platforms (SDL is available on quite a few of them). I believe that Daniel intended to rewrite Graph to use a driver system (similarly to what we use for threading, keyboard/video/mouse units, heap management etc.), which would allow people to use the same Graph functionalities supported by different back-ends and choose either at compile time or possibly even at run time which back-end should be used (as an example, svgalib could be used as backup option for systems not running X11, etc.). I personally wouldn't necessarily wait for PTCPas based implementation - if Daniel wants to use the driver system, it should be enough to agree on the driver interface, anything else can be done completely independently. As far as I've understood Daniel is working only on driver system, isn't it? He doesn't touch such things like line and circle for example (It should be based on PutPixel as I thing) but he is implementing only the things that using back-end libs (like PTCPas), in my example such thing is PutPixel. Am I right? If you implement Graph as a completely independent implementation, you could add it to contributed units (see our WWW pages), so anybody else can use it. If you do it using the driver system and want to contribute this work to FPC, I can imagine it could even become part of our SVN repository and future official FPC releases under some conditions (however, this last sentence is my personal view, not necessarily shared by the whole FPC core team). Tomas It would be great for me to realize a small small part of FPC. And I find that it is much more useful to build a piece for something than create own little project. I will do it using driver system with pleasure, but you've written that it is only your own opinion. And there are several questions about libraries and programme languages. I agree that the most part must be in pascal, but I think that such things like SDL initialization, loading images need to be implemented in C (if use native SDL headers). From my point of view usage of C parts is less dangerous then usage converters and other wrappers stuff. I have no experience with JEDI_SDL, but the last release was 2 years ago... And it's only the headers, so it uses native SDL libraries. I'm just beginner in software development so, please, be patient. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On 9 mrt 2007, at 15:59, Evgeniy Ivanov wrote: I personally wouldn't necessarily wait for PTCPas based implementation - if Daniel wants to use the driver system, it should be enough to agree on the driver interface, anything else can be done completely independently. As far as I've understood Daniel is working only on driver system, isn't it? He doesn't touch such things like line and circle for example (It should be based on PutPixel as I thing) but he is implementing only the things that using back-end libs (like PTCPas), in my example such thing is PutPixel. Am I right? The graph unit is pretty generic in this respect. You indeed only need to implement putpixel, getpixel, graphics mode detection, setting a graphic mode, setting and getting colour palette entries for indexed modes, and closing down the graphic system again. But it's perfectly possible to also intercept line, elipse, rectangle etc and to implement them directly in the driver. I will do it using driver system with pleasure, but you've written that it is only your own opinion. It's the way the whole graphics unit is designed to work. Note that driver is just used in the figurative sense here. In practice, you simply write your code and set some procedure variables inside the graph unit so it calls your code. I agree that the most part must be in pascal, but I think that such things like SDL initialization, loading images need to be implemented in C (if use native SDL headers). From my point of view usage of C parts is less dangerous then usage converters and other wrappers stuff. If you write your code in C, then you need to write Pascal headers for your code. In the end, you will always have to convert some headers. I have no experience with JEDI_SDL, but the last release was 2 years ago... And it's only the headers, so it uses native SDL libraries. That's true, and it's the case for most libraries out there. Converting all libraries from C to Pascal rather than the headers would be a huge and never-ending duplication of effort. There's nothing wrong with using Pascal interfaces for libraries which are written in another language. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 18:08:35 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: The graph unit is pretty generic in this respect. You indeed only need to implement putpixel, getpixel, graphics mode detection, setting a graphic mode, setting and getting colour palette entries for indexed modes, and closing down the graphic system again. But it's perfectly possible to also intercept line, elipse, rectangle etc and to implement them directly in the driver. So, I may implement only putpixel and etc, but then if I wish I may implement line and othe stuff inside my part of code (or somewhere)? It's the way the whole graphics unit is designed to work. Note that driver is just used in the figurative sense here. In practice, you simply write your code and set some procedure variables inside the graph unit so it calls your code. So will be there different ways of using different back-ends directly from graph unit like to have some variables like sdlgraph=1? If you write your code in C, then you need to write Pascal headers for your code. In the end, you will always have to convert some headers. That's true, and it's the case for most libraries out there. Converting all libraries from C to Pascal rather than the headers would be a huge and never-ending duplication of effort. There's nothing wrong with using Pascal interfaces for libraries which are written in another language. So if I will implement it in C with pascal headers it have a chance to be a part of freepascal? -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
That's true, and it's the case for most libraries out there. Converting all libraries from C to Pascal rather than the headers would be a huge and never-ending duplication of effort. There's nothing wrong with using Pascal interfaces for libraries which are written in another language. So if I will implement it in C with pascal headers it have a chance to be a part of freepascal? No, since it would increase the requirements of FPC with a C compiler, for something that could also be done in Pascal. Jonas meant that it's no problem to use C libs for SDL using the Pascal headers to interface to Pascal main code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On 9 mrt 2007, at 16:26, Evgeniy Ivanov wrote: On Fri, 09 Mar 2007 18:08:35 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: The graph unit is pretty generic in this respect. You indeed only need to implement putpixel, getpixel, graphics mode detection, setting a graphic mode, setting and getting colour palette entries for indexed modes, and closing down the graphic system again. But it's perfectly possible to also intercept line, elipse, rectangle etc and to implement them directly in the driver. So, I may implement only putpixel and etc, but then if I wish I may implement line and othe stuff inside my part of code (or somewhere)? Yes, inside your code. It's the way the whole graphics unit is designed to work. Note that driver is just used in the figurative sense here. In practice, you simply write your code and set some procedure variables inside the graph unit so it calls your code. So will be there different ways of using different back-ends directly from graph unit like to have some variables like sdlgraph=1? No, this is done by creating differently named graph units. All common graph unit code is in some include files, and to create a new graph unit for a different platform/library, you create a new unit with code needed for this platform library, and which includes all those generic include files. See e.g. the graph.pp and ggigraph.pp files at http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/unix/ The include files are in http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/inc/ That's true, and it's the case for most libraries out there. Converting all libraries from C to Pascal rather than the headers would be a huge and never-ending duplication of effort. There's nothing wrong with using Pascal interfaces for libraries which are written in another language. So if I will implement it in C with pascal headers it have a chance to be a part of freepascal? Very little. We do this to reuse work done and maintained by others, not for new code which we support and maintain (since we ourselves are Pascal programmers, not C programmers). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: See e.g. the graph.pp and ggigraph.pp files at http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/unix/ The include files are in http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/inc/ Thanks, I wanted to ask about it but you prevented my question. Very little. We do this to reuse work done and maintained by others, not for new code which we support and maintain (since we ourselves are Pascal programmers, not C programmers). I meant that I want to implement dangerous parts in C (driver core) and other things in pascal. But other developers are right that it is bad idea to write on C for pascal project. On Fri, 09 Mar 2007 18:39:10 +0300, Daniël Mantione [EMAIL PROTECTED] wrote: Well, Graph maintenance is more than welcome. I will try to work in this way. It is interesting. Many people @ Pascal Game Development. Domique Louis (Savage) is also still maintaining it. Writing all the imports yourself seems a bit like reinventing the wheel. Reinventing the wheel is to write all SDL imports, for graph I need only few. So you think that it is not bad to use JEDI SDL instead writing some initialization code on C and make pascal headers for it? I haven't used JEDI SDL before but it is beta. I need your advise. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
Evgeniy Ivanov wrote: On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: On Fri, 09 Mar 2007 18:39:10 +0300, DaniĂŤl Mantione [EMAIL PROTECTED] wrote: . . Many people @ Pascal Game Development. Domique Louis (Savage) is also still maintaining it. Writing all the imports yourself seems a bit like reinventing the wheel. Reinventing the wheel is to write all SDL imports, for graph I need only few. So you think that it is not bad to use JEDI SDL instead writing some initialization code on C and make pascal headers for it? I haven't used JEDI SDL before but it is beta. I need your advise. I don't know what heder conversions are available for SDL. However, I believe there are basically two options: 1) Have full SDL headers added as another package in repository (either existing like JEDI SDL or possibly a new one, although that would probably make little sense). I don't know what the size and complexity of these headers is and whether there might be somebody who could maintain such a package in our repository. 2) Include highly limited set of imports necessary for SDL purposes directly in the new sdlgraph (or whatever is the name). This might make sense if we don't have somebody who'd maintain the full headers, whereas maintaining just a highly limited set needed for sdlgraph purposes might be still acceptable (possibly just copied from the existing headers if the licence for those headers allows it). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
Op Fri, 9 Mar 2007, schreef Tomas Hajny: Evgeniy Ivanov wrote: On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe [EMAIL PROTECTED] wrote: On Fri, 09 Mar 2007 18:39:10 +0300, Dani??l Mantione [EMAIL PROTECTED] wrote: . . Many people @ Pascal Game Development. Domique Louis (Savage) is also still maintaining it. Writing all the imports yourself seems a bit like reinventing the wheel. Reinventing the wheel is to write all SDL imports, for graph I need only few. So you think that it is not bad to use JEDI SDL instead writing some initialization code on C and make pascal headers for it? I haven't used JEDI SDL before but it is beta. I need your advise. I don't know what heder conversions are available for SDL. However, I believe there are basically two options: 1) Have full SDL headers added as another package in repository (either existing like JEDI SDL or possibly a new one, although that would probably make little sense). I don't know what the size and complexity of these headers is and whether there might be somebody who could maintain such a package in our repository. JEDI-SDL is rather large. It contains import libraries for many SDL sattelite libraries, many examples and documentation. It is under somewhat active development by Dominique Louis. 2) Include highly limited set of imports necessary for SDL purposes directly in the new sdlgraph (or whatever is the name). We could limit ourselves to sdl.pas. This is the main library. All graphics formats stuff, 3D stuff etc. is of less importance to graph. This might make sense if we don't have somebody who'd maintain the full headers, whereas maintaining just a highly limited set needed for sdlgraph purposes might be still acceptable (possibly just copied from the existing headers if the licence for those headers allows it). SDL is LGPL, so is JEDI-SDL. We would need ask Dominique for permission of the FPC static linking exception to just JEDI-SDL (we do not distribute SDL itself). I don't think this will be a problem. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On Fri, 09 Mar 2007 21:07:55 +0300, Daniël Mantione [EMAIL PROTECTED] wrote: This might make sense if we don't have somebody who'd maintain the full headers, whereas maintaining just a highly limited set needed for sdlgraph purposes might be still acceptable (possibly just copied from the existing headers if the licence for those headers allows it). SDL is LGPL, so is JEDI-SDL. We would need ask Dominique for permission of the FPC static linking exception to just JEDI-SDL (we do not distribute SDL itself). I don't think this will be a problem. Sorry, but you are wrong. JEDI-SDL is Mozilla Public License 1.1 (MPL 1.1). I don't know all refinements of licences, but JEDI-SDL is based on SDL libraries and they are LGPL version 2, so if we want to use JEDI-SDL headers they will bring us MPL 1.1 and it's requirements. But linking with SDL library will bring LGPL 2. If you mean static linking (ld job and static libraries) then we need permissions not from Dominique but from Sam Lantinga. As far as I know JEDI-SDL haven't its own libraries. -- Best regards E.I. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graph module
On 9 mrt 2007, at 20:33, Evgeniy Ivanov wrote: Sorry, but you are wrong. JEDI-SDL is Mozilla Public License 1.1 (MPL 1.1). I don't know all refinements of licences, but JEDI-SDL is based on SDL libraries and they are LGPL version 2, so if we want to use JEDI-SDL headers they will bring us MPL 1.1 and it's requirements. But linking with SDL library will bring LGPL 2. If you mean static linking (ld job and static libraries) then we need permissions not from Dominique but from Sam Lantinga. As far as I know JEDI-SDL haven't its own libraries. Daniel was talking about staticallu linking the interface, not the libraries themselves. Since we do not distribute the libraries, what license they are distributed under is irrelevant. The interface can be used to both link the dynamic and static library versions of SDL. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
