From: Jim S. <ja...@ne...> - 2004-07-20 21:20:19
|
Firebird needs a suitable vector template it can call its own. Not counting various ad hoc structures, there are currently two vector templates floating around Firebird. Vector (vector.h) has its size fixed at declaration and isn't suitable. It's referenced in btr.cpp but actually used only in alloc.cpp, which is being replaced in Vulcan anyway. Firebird::vector is an extension of std::vector. Std::vector is not very portable, particularly in the form used by firebird::vector, does many, many things we don't need and don't want to pay for, and in the cases where I've looked at the code generated, a grotesque pig. I'd like to spec out the requirements for a suitable Vector template (probably called something exotic like "Vector"). Here are the things I know we need: 1. A default constructor that doesn't allocate anything 2. A constructor to set an initial capacity 3. A method to change the capacity 4. A method to access an element 5. A method to set an element (out of bounds is an error -- no automatic extension) 6. A method to get capacity Things that I don't think we need include: 1. Automatic extension (this should be an error) 2. A mechanism to squish in a new element (not needed) 3. A mechanism to sort the vector 4. Any sort of iterator (all vectors start with zero) 5. Copy constructors 6. An auto-insert (assign to next unused slot) Things I consider up in the air: 1. A method to get a const vector pointer (yes, Virginia, a const vector pointer) 2. An index operator 3. A high water mark (static? dynamic?) We probably want to make a subclass to handle RefObjects to increment use count on insertion, decrement on overwriting and deletion. Please keep in mind that the purpose is simplify and streamline the code, not try to use very C++ feature known or imagined, and not to try to solve the crisis in the middle east with a single template definition. The template should do exactly what we need it to do, do it efficiently, and do it conveniently. Please consider this an exercise in minimalist design. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
From: James K. L. <jkl...@sc...> - 2004-07-21 04:38:09
|
On Tue, 20 Jul 2004 <ja...@ne...> wrote: > Firebird needs a suitable vector template it can call its own. ... > Std::vector > is not very portable, particularly in the form used by firebird::vector, > > does many, many things we don't need and don't want to pay for, and in > the cases where I've looked at the code generated, a grotesque pig. I disagree with you about std::vector. It's portable. And things you don't use in a vector class don't get instantiated. Nevertheless, you say FB needs a lighter vector, so here you go: http://www.schemamania.org/projects/firebird/vector/ Except for the pointer() method and the Exception class, it's a drop in replacement for std::vector, in that it uses the same names. (The at() function is taken from std::string.) I didn't address threads, because I don't know how. Is this anything like what you had in mind? --jkl |
From: Jim S. <ja...@ne...> - 2004-07-21 15:54:30
|
James K. Lowden wrote: >Nevertheless, you say FB needs a lighter vector, so here you go: > >http://www.schemamania.org/projects/firebird/vector/ > >Except for the pointer() method and the Exception class, it's a drop in >replacement for std::vector, in that it uses the same names. (The at() >function is taken from std::string.) > >I didn't address threads, because I don't know how. > >Is this anything like what you had in mind? > > > Yeah, that is exactly, precisely what I had in mind. If you would so kind as to slap an IPL license on the front I'd be happy to put it in Vulcan. Why couldn't other things be this easy. You might, however, zero out the internal vector pointer after setting the size to zero. Deleting the vector again from the destructor is going to upset the memory manager. It would also be easier to use if it threw OSRIBugcheck when it stumbled onto an error. Could the bounds check be conditional on the symbol DEBUG? And perhaps "inline" for the accessor functions? I've probably missed something, but I don't understand how elements are set? -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
From: James K. L. <jkl...@sc...> - 2004-07-22 02:53:23
|
On Wed, 21 Jul 2004, Jim Starkey <ja...@ne...> wrote: > Why couldn't other things be this easy. Um, some things are harder? > You might, however, zero out the internal vector pointer after setting > the size to zero. Oversight. Done. > It would also be easier to use if it > threw OSRIBugcheck when it stumbled onto an error. I'll look into it. > Could the bounds > check be conditional on the symbol DEBUG? Are you absolutely sure you want to do that? I read your compute-bound indictment, and I'm sympathetic. But "if( n < length )" is only a machine instruction or two. On a production machine, I would *much* rather learn of a weird exception being thrown than worry about the consequences of a fetch from (or write to) invalid memory. It seems to me that almost the only advantage of our Vector over the built-in C++ array is that it knows how big it is and can thus prevent misuse. If you find an area that, safety be damned, absolutely must have the most efficient access, you can get the buffer address with pointer() and index into directly. > And perhaps "inline" for the > accessor functions? I don't have my ARM handy, but IIRC functions defined in the declaration are inline. > I've probably missed something, but I don't > understand how elements are set? You can fetch elements with operator[]() or at(). Both return references that can be assigned to: Vector<int> b(9); b[3] = 8; or b.at(3) += 7; It's the natural way to use a vector. (You asked for a fetch method. I can't see anything except operator[] being used, in practice.) The unnatural way would be to have at() take two parameters: b.at(3,7); Among other things, the user would always have to remember whether the index came first or second. Especially important for Vector<int>. ;-) > If you would so kind as to slap an IPL license on the front I'd be happy > to put it in Vulcan. Happy to be of service. I don't have a problem with IPL, but is there no way to contribute code with more liberal terms? For something as simple as this that can probably be found in half a dozen textbooks, I'm tempted to put it in the public domain. --jkl |
From: James K. L. <jkl...@sc...> - 2004-07-22 03:24:22
|
On Wed, 21 Jul 2004 22:53:19 -0400, "James K. Lowden" <jkl...@sc...> wrote: > b[3] = 8; Regarding two points of efficiency: boundary checking, and assigning to a reference (instead of passing the value to a function). With: $ c++ -g -O3 -o vector_test vector_test.C the above quoted line is 3 instructions: 0x804912c <main+776>: movl $0x8,(%eax) 0x8049132 <main+782>: mov 0xffffffe0(%ebp),%eax 0x8049135 <main+785>: addl $0x7,0xc(%eax) Apparently, the boundary check is optimized out if the compiler has enough information. Unoptimized: 0x8048ec3 <main+79>: add $0xfffffff8,%esp 0x8048ec6 <main+82>: push $0x3 0x8048ec8 <main+84>: lea 0xffffffe0(%ebp),%eax 0x8048ecb <main+87>: push %eax 0x8048ecc <main+88>: call 0x80495a4 <__vc__Q28Firebirdt6Vector1ZiUl> note call to operator[] 0x8048ed1 <main+93>: add $0x10,%esp 0x8048ed4 <main+96>: mov %eax,%eax 0x8048ed6 <main+98>: mov %eax,%ebx 0x8048ed8 <main+100>: movl $0x8,(%ebx) 0x8048ede <main+106>: add $0xfffffff8,%esp Ten instructions, excluding fetching the reference. After even primitive inlining, it's not clear that a function like: b.at(3,7) would save even one instruction. --jkl |
From: Jim S. <ja...@ne...> - 2004-07-22 20:47:48
|
James K. Lowden wrote: >>Could the bounds >>check be conditional on the symbol DEBUG? >> >> > >Are you absolutely sure you want to do that? I read your compute-bound >indictment, and I'm sympathetic. But "if( n < length )" is only a machine >instruction or two. On a production machine, I would *much* rather learn >of a weird exception being thrown than worry about the consequences of a >fetch from (or write to) invalid memory. > >It seems to me that almost the only advantage of our Vector over the >built-in C++ array is that it knows how big it is and can thus prevent >misuse. > >If you find an area that, safety be damned, absolutely must have the most >efficient access, you can get the buffer address with pointer() and index >into directly. > I have a lot of sympathy with that situation. There is an old two part maxim, 1) debugging code stays until the system is known to be debugged and 2) no system is known to be debugged. You're right about the optimization. The count is going into a register anyway and the compare and branch not taken isn't much more than a memory reference. The argument against is that this is a slippery slope -- there are zillions of potention runtime checks and a zillion times a pico-second adds up to real time. In most cases, the code will already have checked the size anyway to be able to give a proper error diagnostic, so a second check is superfluous. Ah, you say, that makes the first check unnecessary code! Yes, but developers should check this stuff, and relying on the infrastructure to handle behind your back leads to bad habits. So I'm inclined to leave out the test except for debugging (maybe the miscreants will learn something). But this is open source. It's your call. If somebody else wants to change it, take it up later. I won't. >You can fetch elements with operator[]() or at(). Both return references >that can be assigned to: > > Vector<int> b(9); > > b[3] = 8; >or > b.at(3) += 7; > >It's the natural way to use a vector. (You asked for a fetch method. I >can't see anything except operator[] being used, in practice.) > To be sure. I just missed it. >>If you would so kind as to slap an IPL license on the front I'd be happy >>to put it in Vulcan. >> >> > >Happy to be of service. I don't have a problem with IPL, but is there no >way to contribute code with more liberal terms? For something as simple >as this that can probably be found in half a dozen textbooks, I'm tempted >to put it in the public domain. > > > I'm sorry. That was a typo. I meant an IDPL. Please don't give credit to Borland for something they didn't do. The current Firebird policy is that all code must be under either IDPL or IPL. We don't want to have potential customer legal department to have to perform due diligence on every module in the system to avoid be gored by a Gnu. As long as the IDPL boilerplate is there I don't think anyone is going to object if you tack on a "or anything else you want to do with it." But you might want to check with a friendly local admin. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
From: James K. L. <jkl...@sc...> - 2004-07-27 05:44:44
|
On Thu, 22 Jul 2004 16:49:18 -0400, Jim Starkey <ja...@ne...> wrote: > The current Firebird policy is that all code must be under either IDPL > or IPL. I was away. I'll fix it up as soon as I get a chance. Meanwhile, if you're waiting, please just take it for now and trust me to fix the license (at least) in the next couple of days. --jkl |
From: James K. L. <jkl...@sc...> - 2004-07-29 03:26:51
|
On Thu, 22 Jul 2004 16:49:18 -0400, Jim Starkey <ja...@ne...> wrote: > The current Firebird policy is that all code must be under either IDPL > or IPL. We don't want to have potential customer legal department to > have to perform due diligence on every module in the system to avoid be > gored by a Gnu. As long as the IDPL boilerplate is there I don't think > anyone is going to object if you tack on a "or anything else you want to > > do with it." So as not to unduly worry anyone, I changed the license to IDPL, using vulcan/src/dsql/SQLSyntaxError.cpp as a template. That's more restrictive than the BSD license that was there before. FWIW, there is already some BSD licensed stuff in the tree, and no one disputes that it's OK to include BSD-licensed code in GPL/LGPL, so I wouldn't expect any problem with IDPL. The language is clear and brief, after all. I substituted in OSRIException and OSRIBugcheck, although I'm not sure how the latter is meant to be constructed. It's used in only two places; I'm sure you'll quickly adjust it to taste. I left the boundary check. I understand the slippery slope argument, but I think Dennis Ritchie himself would include bounds checking if he were writing C today, and I know Bjarne would have dropped C-style arrays if he hadn't made C compatibility a priority for C++. Besides, as shown, the check is extremely cheap and is optimized out under favorable circumstances. http://www.schemamania.org/projects/firebird/vector/vector.h Use it in good health. --jkl |
From: Claudio V. C. <cv...@us...> - 2004-07-29 04:39:18
|
James K. Lowden wrote: > > That's more restrictive than the BSD license that was there before. > FWIW, there is already some BSD licensed stuff in the tree, and no > one disputes that it's OK to include BSD-licensed code in GPL/LGPL, > so I wouldn't expect any problem with IDPL. The language is clear > and brief, after all. We're trying to fix the licensing mess and have all contributed code (except external code in the src/extern subdir) under a single license, the IDPL. C. |
From: Brad P. <br...@li...> - 2004-07-29 07:07:15
|
Claudio Valderrama C. wrote: > James K. Lowden wrote: > >>That's more restrictive than the BSD license that was there before. >>FWIW, there is already some BSD licensed stuff in the tree, and no >>one disputes that it's OK to include BSD-licensed code in GPL/LGPL, >>so I wouldn't expect any problem with IDPL. The language is clear >>and brief, after all. > > > We're trying to fix the licensing mess and have all contributed code (except > external code in the src/extern subdir) under a single license, the IDPL. I would think that the IDPL *or* some of the less restrictive licenses like perhaps the BSD license and completely public domain should be allowed since I can't see them causing a problem and asking someone who has already released their software as public domain to change it to the IDPL for Firebird seems excessive. -- Brad Pepers br...@li... |
From: Jim S. <ja...@ne...> - 2004-07-29 11:34:00
|
Brad Pepers wrote: >> >> We're trying to fix the licensing mess and have all contributed code >> (except >> external code in the src/extern subdir) under a single license, the >> IDPL. > > > I would think that the IDPL *or* some of the less restrictive licenses > like perhaps the BSD license and completely public domain should be > allowed since I can't see them causing a problem and asking someone > who has already released their software as public domain to change it > to the IDPL for Firebird seems excessive. The whole point of a uniform license is that an organization doesn't need its legal department to do due diligence on every one of 10,000 modules. I don't care if it's dual, triple, or quadruple licensed as long as a mere mortal can read and understand the IDPL/IPL and know what their rights and obligations re source code are. I know everyone has strong feeling about licenses. I'm using a straight IDPL for new generation code with a note that says nobody has the right to release under anything else to defeat the FSF's habit of slapping their poisonous license on other people less encumbered code. |
From: Roman R. <rro...@ac...> - 2004-07-29 11:58:39
|
Jim, > I know everyone has strong feeling about licenses. I'm using a > straight IDPL for new generation code with a note that says nobody > has the right to release under anything else to defeat the FSF's > habit of slapping their poisonous license on other people less > encumbered code. What's the point of this note? You are the only person able to change the license of the code, so even FSF would like to release portions of your code under GPL, you're the only one that can allow this. Or do I miss something and we can change the license without contacting the copyright holder? (Which might not be too bad, this would guarantee that even contributor is mo more participating in the development, project can still use his previous contributions when the license of the project changes without the need to look for him over the globe). Roman |
From: Jim S. <ja...@ne...> - 2004-07-29 14:29:58
|
Roman Rokytskyy wrote: >Jim, > > > >>I know everyone has strong feeling about licenses. I'm using a >>straight IDPL for new generation code with a note that says nobody >>has the right to release under anything else to defeat the FSF's >>habit of slapping their poisonous license on other people less >>encumbered code. >> >> > >What's the point of this note? You are the only person able to change the >license of the code, so even FSF would like to release portions of your code >under GPL, you're the only one that can allow this. > > > You should be right. And if you were, I would have no problem. FSF, in fact, has a history of slapping GPL on other people's code even over their loud objections. The post child is cryptlib, a industrial strength crypto library. The primary header file of cryptlib contains the very clear line: // cryptlib.h - written and placed in the public domain by Wei Dai Stallman, et all, took this excellent library, slapped a GPL on it, and re-released it. I needed commercially acceptable crypto library. Cryptlib was what wanted, but I had to hunt down the original distribution to get an unencumbered copy. My understanding is that the cryptlib guys had to threaten suit to get FSF to force them to remove their header and license. I suppose someone could interpret "placed in the public domain" has meaning anything goes, including adding a more restrictive license, but that's not my interpretation. Stallman believes that open source is a vehicle to establish an alternate economy. I believe that open source is a means to make foundational software available to everyone so we can concentrate on new problems. In a better world, these shouldn't be incompatible. This this one, they are. I, like Mr. Wei Dai, would like to make my contributions to Firebird available for use by everyone for any purpose they deem worthy. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
From: Tom C. <tco...@au...> - 2004-07-29 14:46:04
|
> > Stallman believes that open source is a vehicle to establish an > alternate economy. > I thought that Stallman's motivation was to prevent commercial entities from using open source code as the framework for their products with no requirement that they contribute improvements to the code. Seems fair and reasonable to me. |
From: Jim S. <ja...@ne...> - 2004-07-29 15:15:55
|
Tom Coleman wrote: >>Stallman believes that open source is a vehicle to establish an >>alternate economy. >> >> >> > > I thought that Stallman's motivation was to prevent commercial entities > from using open source code as the framework for their products with no > requirement that they contribute improvements to the code. > > > That's the idea behind the Mozilla Public License, IPL, and IDPL. GPL requires that not only improvements to the code, but everything else in the same distribution also be GPL-ed. Here's the big difference. A large software company is paying for Vulcan development. All of those improvement go straight into Firebird and any other project that wants to use them. The company is willing to do this so they can bundle Firebird with their product. A clear win-win. Under GPL, they'd be obligated to give away their entire product line, which I serious doubt they'd be willing to do. No software company is willing to underwrite pure GPL code. MySQL does get funding, but they dual license GPL and MGPrL (money-grubbers private license). The guys who fund their development get special non-GPL licenses on terms unavailable to anyone else. Is that a good way to run the world? In any deal situation good businessmen look at what they're paying and what're getting and whether the deal makes sense. The really bad ones look at what the other guy is getting and paying and worry whether the other guy is getting a steal. The fact that somebody else might be making a buck should not be an argument against doing something generally useful and good. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
From: Roman R. <rro...@ac...> - 2004-07-29 15:32:31
|
Jim, > That's the idea behind the Mozilla Public License, IPL, and IDPL. > GPL requires that not only improvements to the code, but everything > else in the same distribution also be GPL-ed. Sorry for continuing this discussion here, but I would like also to hear your opinion on LGPL. It solves one uneasy situation with MPL-like licenses - nobody is allowed to release a software whose sole purpose is to work with the library. Theoretically it prevents any commercial entity from releasing JayBird as JDBC driver for InterBase (though the reality is tougher). Roman |
From: Jim S. <ja...@ne...> - 2004-07-29 16:14:21
|
Roman Rokytskyy wrote: >Sorry for continuing this discussion here, but I would like also to hear >your opinion on LGPL. It solves one uneasy situation with MPL-like >licenses - nobody is allowed to release a software whose sole purpose is to >work with the library. Theoretically it prevents any commercial entity from >releasing JayBird as JDBC driver for InterBase (though the reality is >tougher). > > > In general I don't worry about how other people release their code. If somebody writes something and makes it generally available with restrictions, I'll look at the restrictions and decide whether to use it or not. Worst case, I reimplement it with at least an existence proof handy. Netfrastructure uses the aforementioned crypto code (RSA, DES, and SHA), zip encoding, and jpeg handling, none of which I would ever want to implement. I have my own proprietary code to handle Word and I do have a problem understanding exactly how the critical LGPL distinction between "works with" and "uses" applies to Java. I don't think I'd ever distribute LGPL Java code with Netfrastructure, for example. I haven't clue how a court might interpret a subclass of an LGPLed class, though I do know that the FSF has a great deal more money to spend on lawyers than I do, and a great deal more interest in litigating than I think warranted for an ostensible public service organization. If it were my code, I'd rather it be available to Interbase customers to ease the transition to Firebird. If Borland wants to ship lifeboats to their customers, more power to them. But, of course, it isn't my code. -- Jim Starkey Netfrastructure, Inc. 978 526-1376 |
From: David J. <da...@co...> - 2004-07-29 17:06:56
|
After several years of enthusiastically supporting LGPL, I have basically come to agree with Jim on this. When I read LPGL my opinion (not being a lawyer) is that for java lgpl is equivalent to gpl. I have not found any FSF statements to the contrary that I can understand. I would prefer that my code be more widely accepted and used by, for instance, other people who can't understand exactly what LGPL means, than that I prevent some company from profiting from it. thanks david jencks On Jul 29, 2004, at 9:16 AM, Jim Starkey wrote: > > > Roman Rokytskyy wrote: > >> Sorry for continuing this discussion here, but I would like also to >> hear >> your opinion on LGPL. It solves one uneasy situation with MPL-like >> licenses - nobody is allowed to release a software whose sole purpose >> is to >> work with the library. Theoretically it prevents any commercial >> entity from >> releasing JayBird as JDBC driver for InterBase (though the reality is >> tougher). >> >> > In general I don't worry about how other people release their code. > If somebody writes something and makes it generally available with > restrictions, I'll look at the restrictions and decide whether to use > it or not. Worst case, I reimplement it with at least an existence > proof handy. Netfrastructure uses the aforementioned crypto code > (RSA, DES, and SHA), zip encoding, and jpeg handling, none of which I > would ever want to implement. I have my own proprietary code to > handle Word and > > I do have a problem understanding exactly how the critical LGPL > distinction between "works with" and "uses" applies to Java. I don't > think I'd ever distribute LGPL Java code with Netfrastructure, for > example. I haven't clue how a court might interpret a subclass of an > LGPLed class, though I do know that the FSF has a great deal more > money to spend on lawyers than I do, and a great deal more interest in > litigating than I think warranted for an ostensible public service > organization. > > If it were my code, I'd rather it be available to Interbase customers > to ease the transition to Firebird. If Borland wants to ship > lifeboats to their customers, more power to them. But, of course, it > isn't my code. > > -- > > Jim Starkey > Netfrastructure, Inc. > 978 526-1376 > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source > Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > |
From: Roman R. <rro...@ac...> - 2004-07-29 17:26:08
|
> After several years of enthusiastically supporting LGPL, I have > basically come to agree with Jim on this. When I read LPGL my > opinion (not being a lawyer) is that for java lgpl is equivalent to > gpl. For JayBird this is true only in limited cases. What if we release so-called "Firebir JDBC extensions" - interfaces that extend JDBC with Firebird features under the most unrestrictive license (I think modified BSD license is ok for this) and provide an implementation of these interfaces (namely JayBird). Something similar to XML DOM and SAX APIs and Crimson and Xerces as implementations. Maybe it complicates things, but is relatively painless in Java. For Java applications that would mean that they "link" against BSD interfaces and use JayBird as the implementation of those interfaces. > I have not found any FSF statements to the contrary that I can > understand. I would prefer that my code be more widely accepted > and used by, for instance, other people who can't understand > exactly what LGPL means, than that I prevent some company from > profiting from it. I think we should contact FSF on this topic and see their arguments. Maybe they have some. Roman |
From: Mark O'D. <mar...@fi...> - 2004-07-30 04:00:45
|
Roman Rokytskyy wrote: >David Jencks wrote: >> for instance, other people who can't understand >>exactly what LGPL means, > I wasn't going to post, but then I stumbled across this timely link :-). http://www.groklaw.net/article.php?story=20040727140948715 Now we can all go and find out about anti-gpl fud, what it all means etc. Opensource licences, are evolving, and I think GPL has played a big part in good software not disapearing into private versions. MPL/IPL... are, in my opinion also experiments, but given mozilla had to eventually go to a now tripple MPL/GPL/LGPL licencing scheme, I wonder. Opensource projects are also an amalgam of code, often containing many licences think what licences your loading up in running linux, even in just linking using gcc, borland cpp, microsoft cpp etc... so some tollerance to "compatible" licences is needed. For instance, it could be argued, that Jim in insisting on IDPL for the vector code, is doing a very similar thing to what he complained RMS did to the cryptolib code. But Firebird is very much MPL/IDPL, Some (most) of the participants feel very strongly about that. The issue was discussed (several times), and finally voted on in fb-admin. (I personaly would feel happier if IDPL was endorsed by www.opensource.org - but it costs money). >> When I read LPGL my opinion (not being a lawyer) is that for java lgpl is equivalent to >>gpl. > >>I have not found any FSF statements to the contrary that I can >>understand. There was discussion about "viral" LGPL for java, a seemingly fairly clear statment from the FSF, that it wasn't for java and jar files a while ago, but as usualy it depends upon who you believe. http://developers.slashdot.org/developers/03/07/17/2257224.shtml I think LGPL (and GPL) has it's place, RMS's attitude to LGPL (he don't like it) doesn't help, and maybe eventually a LGPL replacement will be found, the MPL, for instance, does some of the LGPL things. Cheers Mark |
From: Nando D. <na...@de...> - 2004-07-30 06:16:41
|
Mark, M> (I personaly would feel happier if IDPL M> was endorsed by www.opensource.org - but it costs money). that's about the same concern expressed by the FlameRobin developers. Do you think the project or the foundation should take steps to have the IDPL made official? Ciao -- Nando Dessena mailto:na...@de... |
From: Jim S. <ja...@ne...> - 2004-07-30 11:35:07
|
Mark O'Donohue wrote: > > > But Firebird is very much MPL/IDPL, Some (most) of the participants > feel very strongly about that. The issue was discussed (several > times), and finally voted on in fb-admin. (I personaly would feel > happier if IDPL was endorsed by www.opensource.org - but it costs money). > I don't get it. I really don't get it. Why are open source projects so fixated on blessings by external organizations? We can't extend role semantics because that is non-standard. We can't do table filters because they're non-standard. Just about every attempt to innovate is stiffled because to innovate is to be unstandard. Three cheers to Mr. Lowden, but most of the project has been arguing that since the first word of "stl" is standard we have to use it whether it's appropriate or not? But to insist that some silly committee has to bless (at our expense!) whatever license we choose to give away our software is absurd! We can make decisions. We can use our judgement. We can have original thoughts. We don't need every aspect of our lives blessed by official body. |
From: Alan M. <al...@me...> - 2004-07-30 12:15:08
|
> Mark O'Donohue wrote: > > > > > > > But Firebird is very much MPL/IDPL, Some (most) of the participants > > feel very strongly about that. The issue was discussed (several > > times), and finally voted on in fb-admin. (I personaly would feel > > happier if IDPL was endorsed by www.opensource.org - but it > costs money). > > > I don't get it. I really don't get it. Why are open source projects so > fixated on blessings by external organizations? We can't extend role > semantics because that is non-standard. We can't do table filters > because they're non-standard. Just about every attempt to innovate is > stiffled because to innovate is to be unstandard. Three cheers to Mr. > Lowden, but most of the project has been arguing that since the first > word of "stl" is standard we have to use it whether it's appropriate or > not? But to insist that some silly committee has to bless (at our > expense!) whatever license we choose to give away our software is absurd! > > We can make decisions. We can use our judgement. We can have original > thoughts. We don't need every aspect of our lives blessed by > official body. > here here! what nonsense Alan |
From: Jacqui C. <jac...@nt...> - 2004-07-30 12:38:12
|
Jim Starkey wrote: > > > Mark O'Donohue wrote: >> times), and finally voted on in fb-admin. (I personaly would feel >> happier if IDPL was endorsed by www.opensource.org - but it costs money). Hmm - can somoene point me to the charges involved? > I don't get it. I really don't get it. Why are open source projects so > fixated on blessings by external organizations? Ego? :-) > But to insist that some silly committee has to bless (at our > expense!) whatever license we choose to give away our software is absurd! hear hear! > We can make decisions. We can use our judgement. We can have original > thoughts. We don't need every aspect of our lives blessed by official > body. This can be the road to chaos, however I do agree that sticking to (your own interpretation of) standards is highly limiting - do we really want Firebird to follow the herd or lead it? IMHO I would like to see some ground breaking extensions and innovation in FB, driven by user demand. We already have many databases overloaded with bloatware driven by marketing folks or overloaded toys obsessed with speed over stability. One worse case scenario is that someone will require an enhancement which will be rejected as "non standards based" but a majority of users will want/need - often a derived system appears and the original project dies (slowly). As Jim suggests common sense should prevail over dogma. Jacqui FYI: my employer is pushing the firebird envelope with dynamically created tables and triggers, UDFs to decompile documents into elements (a document template) then expand the template (elements) using client context to generate a personalised "issue". I (and others) have already been told by fb-support that this "cannot be done" or "don't do that!" - well I have and it works :-) |
From: Mark O'D. <mar...@fi...> - 2004-08-01 16:13:38
|
Hi Jim Jim Starkey wrote: > > > Mark O'Donohue wrote: > >> > I don't get it. I really don't get it. Why are open source projects so > fixated on blessings by external organizations? For the license, yes I would feel more comfortable with it being OSI approved. For instance, on our website we use the OSI logo, which essentially is claiming we are OSI approved. Also in convincing users and developers we are opensource (as well making it easier for a companies legal team to approve the licence, as you mentioned) it would make sense to have an OSI approved licence. Since it's a fairly straight MPL with minor modifications, as I understand it should be a fairly simple process to get approved. > We don't need every aspect of our lives blessed by official body. Or by specific individuals :-). Cheers Mark |