From: Nicolas C. <war...@fr...> - 2004-07-18 18:29:42
|
Hi list, This weekend I played a little with inflate algorithm, the decompression algorithm described in RFC 1951 and which is used by most file formats (zip, gz, jar, png, swf....). I rewrote it entirely from the RFC in pure OCaml, and I think it could be nice to add it to ExtLib. The current implementation uses IO module and wrap an input : module Unzip val inflate : ?header:bool -> IO.stdinput -> IO.stdinput I also wrote a test program that checks that the algorithm is working well and also compare inflate performances between Unzip module (pure ocaml) and ZLib ( using CamlZip bindings by X.Leroy, available here : http://cristal.inria.fr/~xleroy/software.html ). After some optimizations, and while still having a readable code, my benchmark shows that Unzip is only 2 to 3 times slower than ZLib. I'm quite happy with this kind of performances. Here's the files for peer review / benchmarks / comments. Regards, Nicolas Cannasse |
From: Nicolas C. <war...@fr...> - 2004-07-23 20:09:38
|
> Hi list, > > This weekend I played a little with inflate algorithm, the decompression > algorithm described in RFC 1951 and which is used by most file formats (zip, > gz, jar, png, swf....). I rewrote it entirely from the RFC in pure OCaml, > and I think it could be nice to add it to ExtLib. > > The current implementation uses IO module and wrap an input : > > module Unzip The Unzip module is now part of ExtLib ! You can deflate your TGZ and ZIP with pure OCaml code only ! Enjoy, Nicolas Cannasse |
From: Jesse G. <je...@wi...> - 2004-07-23 20:29:50
|
Nicolas Cannasse wrote: >> Hi list, >> >> This weekend I played a little with inflate algorithm, the decompression >> algorithm described in RFC 1951 and which is used by most file formats > (zip, >> gz, jar, png, swf....). I rewrote it entirely from the RFC in pure OCaml, >> and I think it could be nice to add it to ExtLib. >> >> The current implementation uses IO module and wrap an input : >> >> module Unzip > > The Unzip module is now part of ExtLib ! > You can deflate your TGZ and ZIP with pure OCaml code only ! > Enjoy, > > Nicolas Cannasse Wow, that's cool. That reminds me: Is there any chance you might be interested in Dustin Sallings' pure OCaml CDB module? You can view the docs here: http://bleu.west.spy.net/~dustin/projects/ocaml/doc/Cdb.html And download it (along with some of Dustin's other modules) here: http://bleu.west.spy.net/~dustin/projects/ocaml/index.xtp The patch-71 release doesn't build on 3.08 due to the new Int restrictions, but if you click "Changes" and download and apply patch-72 it will build fine. I use this code in a program I'm writing here at work. It's licensed under a BSD style license, but Dustin might be willing to release it under the LGPL. He's been very flexible with licensing in the past, but you'd have to ask. I've been extremely impressed with this module so far. We had some divide by zero problems which manifested under Linux and FreeBSD ( but not Dustin's primary development platform: OSX ) originally, but Dustin was quick to fix them, and it's really quite fast. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |
From: Nicolas C. <war...@fr...> - 2004-07-23 20:50:01
|
> >> Hi list, > >> > >> This weekend I played a little with inflate algorithm, the decompression > >> algorithm described in RFC 1951 and which is used by most file formats > > (zip, > >> gz, jar, png, swf....). I rewrote it entirely from the RFC in pure OCaml, > >> and I think it could be nice to add it to ExtLib. > >> > >> The current implementation uses IO module and wrap an input : > >> > >> module Unzip > > > > The Unzip module is now part of ExtLib ! > > You can deflate your TGZ and ZIP with pure OCaml code only ! > > Enjoy, > > > > Nicolas Cannasse > > Wow, that's cool. > > That reminds me: Is there any chance you might be interested in Dustin > Sallings' pure OCaml CDB module? > > You can view the docs here: > http://bleu.west.spy.net/~dustin/projects/ocaml/doc/Cdb.html > > And download it (along with some of Dustin's other modules) here: > http://bleu.west.spy.net/~dustin/projects/ocaml/index.xtp > > The patch-71 release doesn't build on 3.08 due to the new Int restrictions, > but if you click "Changes" and download and apply patch-72 it will build > fine. > > I use this code in a program I'm writing here at work. It's licensed > under a BSD style license, but Dustin might be willing to release > it under the LGPL. He's been very flexible with licensing in the past, > but you'd have to ask. > > I've been extremely impressed with this module so far. We had some divide > by zero problems which manifested under Linux and FreeBSD ( but not > Dustin's primary development platform: OSX ) originally, but Dustin was > quick to fix them, and it's really quite fast. Well, we've been talking before about adding a module in order to save config or data informations in a persistent storage (such as a file) but we couldn't agree on which was best. IMHO we need a hierarchical format with some structural semantics and a minimum of typing , all of that storable in an text only user editable format. XML would be enough even if not best before it's widely use and easy to interface with other programming language for data exchanges. I think CDB is not enough powerful - although convenient - so that we reach an agreement on it. Regards, Nicolas Cannasse |
From: Jesse G. <je...@wi...> - 2004-07-23 21:02:23
|
Nicolas Cannasse wrote: >>>>Hi list, >>>> >>>>This weekend I played a little with inflate algorithm, the >>>> >>>> >decompression > > >>>>algorithm described in RFC 1951 and which is used by most file formats >>>> >>>> >>>(zip, >>> >>> >>>>gz, jar, png, swf....). I rewrote it entirely from the RFC in pure >>>> >>>> >OCaml, > > >>>>and I think it could be nice to add it to ExtLib. >>>> >>>>The current implementation uses IO module and wrap an input : >>>> >>>>module Unzip >>>> >>>> >>>The Unzip module is now part of ExtLib ! >>>You can deflate your TGZ and ZIP with pure OCaml code only ! >>>Enjoy, >>> >>>Nicolas Cannasse >>> >>> >>Wow, that's cool. >> >>That reminds me: Is there any chance you might be interested in Dustin >>Sallings' pure OCaml CDB module? >> >>You can view the docs here: >> http://bleu.west.spy.net/~dustin/projects/ocaml/doc/Cdb.html >> >>And download it (along with some of Dustin's other modules) here: >> http://bleu.west.spy.net/~dustin/projects/ocaml/index.xtp >> >>The patch-71 release doesn't build on 3.08 due to the new Int >> >> >restrictions, > > >>but if you click "Changes" and download and apply patch-72 it will build >>fine. >> >>I use this code in a program I'm writing here at work. It's licensed >>under a BSD style license, but Dustin might be willing to release >>it under the LGPL. He's been very flexible with licensing in the past, >>but you'd have to ask. >> >>I've been extremely impressed with this module so far. We had some divide >>by zero problems which manifested under Linux and FreeBSD ( but not >>Dustin's primary development platform: OSX ) originally, but Dustin was >>quick to fix them, and it's really quite fast. >> >> > >Well, we've been talking before about adding a module in order to save >config or data informations in a persistent storage (such as a file) but we >couldn't agree on which was best. IMHO we need a hierarchical format with >some structural semantics and a minimum of typing , all of that storable in >an text only user editable format. XML would be enough even if not best >before it's widely use and easy to interface with other programming language >for data exchanges. I think CDB is not enough powerful - although >convenient - so that we reach an agreement on it. > >Regards, >Nicolas Cannasse > > > :) Well, I didn't suggest it because I think it's the end-all to data storage. I suggested it because it's useful. Python has a CDB module. OCaml normally ships with a DBM module, AFAIK. What's wrong with a little variety? -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |
From: Nicolas C. <war...@fr...> - 2004-07-23 21:05:08
|
> :) Well, I didn't suggest it because I think it's the end-all to data > storage. I suggested it because it's > useful. Python has a CDB module. OCaml normally ships with a DBM module, > AFAIK. What's wrong > with a little variety? Well... I guess Java standard library designers where thinking the same as you :) Look at the results... NC |
From: Jesse G. <je...@wi...> - 2004-07-23 21:13:09
|
Nicolas Cannasse wrote: >>:) Well, I didn't suggest it because I think it's the end-all to data >>storage. I suggested it because it's >>useful. Python has a CDB module. OCaml normally ships with a DBM module, >>AFAIK. What's wrong >>with a little variety? >> >> > >Well... I guess Java standard library designers where thinking the same as >you :) Look at the results... > >NC > > > I don't understand why you'll include an unzip module, but not a cdb module. Thanks anyway. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |
From: Nicolas C. <war...@fr...> - 2004-07-23 21:42:04
|
> >>:) Well, I didn't suggest it because I think it's the end-all to data > >>storage. I suggested it because it's > >>useful. Python has a CDB module. OCaml normally ships with a DBM module, > >>AFAIK. What's wrong > >>with a little variety? > >> > >> > > > >Well... I guess Java standard library designers where thinking the same as > >you :) Look at the results... > > > >NC > > > > > > > I don't understand why you'll include an unzip module, but not a cdb module. > Thanks anyway. Well the deflate algorithm implemented by the unzip module is widely used in a lot of data formats and have become a standard. I have no knowledge about CDB, but it doesn't sound so "widely used" that it becomes a de factor standard (qmail use it, what else ?). I don't say it's not convenient or useful, I just say that we only put in ExtLib widely usable modules. Nicolas Cannasse |
From: Jesse G. <je...@wi...> - 2004-07-23 21:56:28
|
Nicolas Cannasse wrote: >>>>:) Well, I didn't suggest it because I think it's the end-all to data >>>>storage. I suggested it because it's >>>>useful. Python has a CDB module. OCaml normally ships with a DBM module, >>>>AFAIK. What's wrong >>>>with a little variety? >>>> >>>> >>>> >>>> >>>Well... I guess Java standard library designers where thinking the same >>> >>> >as > > >>>you :) Look at the results... >>> >>>NC >>> >>> >>> >>> >>> >>I don't understand why you'll include an unzip module, but not a cdb >> >> >module. > > >>Thanks anyway. >> >> > >Well the deflate algorithm implemented by the unzip module is widely used in >a lot of data formats and have become a standard. I have no knowledge about >CDB, but it doesn't sound so "widely used" that it becomes a de factor >standard (qmail use it, what else ?). I don't say it's not convenient or >useful, I just say that we only put in ExtLib widely usable modules. > >Nicolas Cannasse > > > Lots of programs use CDB. Off the top of my head: Radiator, a commercial RADIUS server written in Perl can use it. TMDA (Tagged Message Delivery Agent), an open source challenge response system, written in Python uses it. There are patches for sendmail to use tinycdb. I believe there are patches for postfix also. Basically, it's great for use in email applications. And it's fairly standard. You can view the spec here: http://cr.yp.to/cdb/cdb.txt There is also tinycdb, a free implementation of DJB's CDB database: http://www.corpit.ru/mjt/tinycdb.html -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |
From: Richard J. <ri...@an...> - 2004-07-24 09:56:18
|
On Fri, Jul 23, 2004 at 10:49:59PM +0200, Nicolas Cannasse wrote: > Well, we've been talking before about adding a module in order to save > config or data informations in a persistent storage (such as a file) but we > couldn't agree on which was best. IMHO we need a hierarchical format with > some structural semantics and a minimum of typing , all of that storable in > an text only user editable format. XML would be enough even if not best > before it's widely use and easy to interface with other programming language > for data exchanges. I think CDB is not enough powerful - although > convenient - so that we reach an agreement on it. I think it's been mentioned before, but just for completeness, YAML (http://www.yaml.org/) is looking like a good choice in this area. Of course, someone would need to step forward and write the parser, which isn't going to be me at the moment ... Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment PTHRLIB is a library for writing small, efficient and fast servers in C. HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/ |
From: Nicolas C. <war...@fr...> - 2004-07-24 10:32:46
|
> > Well, we've been talking before about adding a module in order to save > > config or data informations in a persistent storage (such as a file) but we > > couldn't agree on which was best. IMHO we need a hierarchical format with > > some structural semantics and a minimum of typing , all of that storable in > > an text only user editable format. XML would be enough even if not best > > before it's widely use and easy to interface with other programming language > > for data exchanges. I think CDB is not enough powerful - although > > convenient - so that we reach an agreement on it. > > I think it's been mentioned before, but just for completeness, YAML > (http://www.yaml.org/) is looking like a good choice in this area. Of > course, someone would need to step forward and write the parser, which > isn't going to be me at the moment ... > > Rich. As for me, the best format would be OCaml one. For example if you want to serialize a string option list , you will get : [None;Some "hello";None;Some "world";None;None;Some "\n"] This serialization that can print the correct name of constructors can be done by exploiting data found in CMI files. Same for deserialization , you could do something like : let t = make_type "string option list" in let x = (unserialize str t : string option list) in and this would be entirely safe. Another (full) sample : sample.ml ----------- type point = { x : int; y : int; } let p = { x : 3 ; y : -1 } in let cmi = Type.parse "sample.mli" in let t = Type.get cmi "point" in (* raise an exc if not found *) let str = Type.serialize p t in (* the string returned is "{ x : 3 ; y : -1 }" checking is done when serializing that runtime 'p' data can be correctly serialized using 't' type *) let p2 = (Type.unserialize str t : point) in (* return { x : 3 , y : -1 } runtime information , this is safe *only* if your CMI is up-to-date with currently compiled and running module *) ----------- More than that, we get here some kind of first-class types with interesting properties for reflexion and introspection. Quite difficult to write such a module, but so useful and easy to use when done. Regards, Nicolas Cannasse |
From: Richard J. <ri...@an...> - 2004-07-24 10:54:46
|
On Sat, Jul 24, 2004 at 12:32:43PM +0200, Nicolas Cannasse wrote: > As for me, the best format would be OCaml one. For example if you want to > serialize a string option list , you will get : > > [None;Some "hello";None;Some "world";None;None;Some "\n"] I guess there's two sorts of serialisation here. Using [eg] Yaml, you get interoperability with other languages, which is a worthwhile practical goal. A specialised OCaml-specific serialisation would be useful for reasons of speed. The Marshal module does this already, albeit in C, to a changeable binary-only format, with type safety issues. I've thought hard about whether it would be possible to have a version of Marshal with these three desirable properties: (a) Written in pure OCaml. (b) Uses a sensible text-based format with long-term stability. (c) Type safety - At a minimum, throws a useful exception, rather than segfaulting. Better still if it could "upgrade" data when the type changes. So, (a) seems feasible using Obj. I've examined the source to Marshal (trying to fix an elusive bug once), and there doesn't seem to be anything in particular which requires the use of C. Marshal looks like it could be rewritten in pure OCaml (and if there are any reasons why not then Obj should be extended to support it). (b) is possible, even without hacks like trying to access .cmi files which might not exist. For example, any block with three elements can be written out as: (v1, v2, v3) even though this might represent: a triple; a three-element array of unboxed types; a three-element struct. You'd probably want to special-case things like lists (which would otherwise look like a load of nested pairs). Type safety (c) seems quite hard to achieve. There's not enough information around at runtime to do this, so you'd need to get the compiler to write extra information out, which would go counter to the philosophy of OCaml. Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet |
From: Nicolas C. <war...@fr...> - 2004-07-24 11:12:23
|
> On Sat, Jul 24, 2004 at 12:32:43PM +0200, Nicolas Cannasse wrote: > > As for me, the best format would be OCaml one. For example if you want to > > serialize a string option list , you will get : > > > > [None;Some "hello";None;Some "world";None;None;Some "\n"] > > I guess there's two sorts of serialisation here. > > Using [eg] Yaml, you get interoperability with other languages, which > is a worthwhile practical goal. > > A specialised OCaml-specific serialisation would be useful for reasons > of speed. The Marshal module does this already, albeit in C, to a > changeable binary-only format, with type safety issues. > > I've thought hard about whether it would be possible to have a version > of Marshal with these three desirable properties: > > (a) Written in pure OCaml. > > (b) Uses a sensible text-based format with long-term stability. > > (c) Type safety - At a minimum, throws a useful exception, rather than > segfaulting. Better still if it could "upgrade" data when the type > changes. > > So, (a) seems feasible using Obj. I've examined the source to Marshal > (trying to fix an elusive bug once), and there doesn't seem to be > anything in particular which requires the use of C. Marshal looks > like it could be rewritten in pure OCaml (and if there are any reasons > why not then Obj should be extended to support it). Yes that's true. Scanning runtime values is quite easy to do using only the Obj module. > (b) is possible, even without hacks like trying to access .cmi files > which might not exist. For example, any block with three elements can > be written out as: > > (v1, v2, v3) > > even though this might represent: a triple; a three-element array of > unboxed types; a three-element struct. You'd probably want to > special-case things like lists (which would otherwise look like a load > of nested pairs). > > Type safety (c) seems quite hard to achieve. There's not enough > information around at runtime to do this, so you'd need to get the > compiler to write extra information out, which would go counter to the > philosophy of OCaml. That's also true, but you're loosing a lot of informations. For exemple , you cannot distingish between [] , None and 0 at runtime without any additionnal type information . If you have big data structures such as records and big sets of constant or recursive constructs, maybe you want more information in you text format than just tuples, or the data becomes unreadable. So actually you need some RTTI , which is currently already available in the CMI files without even modifying the compiler. Other way is to generate serialization and deserialization code at compile directly from CMI or dumped compiler type informations. Regards, Nicolas Cannasse |
From: Blair Z. <bl...@or...> - 2004-07-23 21:34:19
|
Jesse Guardiani wrote: > I use this code in a program I'm writing here at work. It's licensed > under a BSD style license, but Dustin might be willing to release > it under the LGPL. He's been very flexible with licensing in the past, > but you'd have to ask. If it's already a BSD style license, why relicense it? It's a perfect license for it to be included in extlib. Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: skaller <sk...@us...> - 2004-07-23 22:35:16
|
On Sat, 2004-07-24 at 07:34, Blair Zajac wrote: > Jesse Guardiani wrote: > > I use this code in a program I'm writing here at work. It's licensed > > under a BSD style license, but Dustin might be willing to release > > it under the LGPL. He's been very flexible with licensing in the past, > > but you'd have to ask. > > If it's already a BSD style license, why relicense it? It's a perfect license > for it to be included in extlib. By agreement, ExtLib has the same licence as the Ocaml standard library, (LGPL + exception). I don't like this licence but I think it was and still is the only logical choice for ExtLib. -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Nicolas C. <war...@fr...> - 2004-07-24 08:29:05
|
> > I use this code in a program I'm writing here at work. It's licensed > > under a BSD style license, but Dustin might be willing to release > > it under the LGPL. He's been very flexible with licensing in the past, > > but you'd have to ask. > > If it's already a BSD style license, why relicense it? It's a perfect license > for it to be included in extlib. When I saw yesterday this message, I was thinking that some kind of licence topic will start off. I almost answer some kind of message "please keep licence talks outside of the list". Reading my emails this morning, I wish I did it. ExtLib licence is OCaml stdlib licence. Final dot. Nicolas Cannasse |
From: skaller <sk...@us...> - 2004-07-23 22:12:50
|
On Sat, 2004-07-24 at 06:29, Jesse Guardiani wrote: > I use this code in a program I'm writing here at work. It's licensed > under a BSD style license, but Dustin might be willing to release > it under the LGPL. He's been very flexible with licensing in the past, > but you'd have to ask. Actually I don't believe so. If it has a BSD licence, you can just add LGPL on as an extra constraint. Basically if the code is BSD you can do what you want with it as long as you don't remove the copyright notice. -- John Skaller, mailto:sk...@us... voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net |
From: Jesse G. <je...@wi...> - 2004-07-23 22:18:58
|
On Friday 23 July 2004 18:12, skaller wrote: > On Sat, 2004-07-24 at 06:29, Jesse Guardiani wrote: > > I use this code in a program I'm writing here at work. It's licensed > > under a BSD style license, but Dustin might be willing to release > > it under the LGPL. He's been very flexible with licensing in the past, > > but you'd have to ask. > > Actually I don't believe so. If it has a BSD licence, > you can just add LGPL on as an extra constraint. > Basically if the code is BSD you can do what you want > with it as long as you don't remove the copyright notice. I didn't know that. :) BSD license is awsome. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |
From: Brian H. <bh...@sp...> - 2004-07-23 22:25:50
|
On 24 Jul 2004, skaller wrote: > On Sat, 2004-07-24 at 06:29, Jesse Guardiani wrote: > > > I use this code in a program I'm writing here at work. It's licensed > > under a BSD style license, but Dustin might be willing to release > > it under the LGPL. He's been very flexible with licensing in the past, > > but you'd have to ask. > > Actually I don't believe so. If it has a BSD licence, > you can just add LGPL on as an extra constraint. > Basically if the code is BSD you can do what you want > with it as long as you don't remove the copyright notice. > Actually, I have a problem with doing this. It's perfectly legal, but that doesn't make it *right*. I've seen BSD proponents (with some justification) complain at this sort of "license theft". There are two ways I could see doing this: - Include it, but keep that particular file BSD copyright - Rewrite it so we can apply whatever license we want to it -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian |
From: Blair Z. <bl...@or...> - 2004-07-23 22:32:00
|
Brian Hurt wrote: > Actually, I have a problem with doing this. It's perfectly legal, but > that doesn't make it *right*. I've seen BSD proponents (with some > justification) complain at this sort of "license theft". There are two > ways I could see doing this: > - Include it, but keep that particular file BSD copyright > - Rewrite it so we can apply whatever license we want to it I don't see the point in rewriting it to put a more restrictive license on it. I suggest just including it and keeping it BSD. Blair -- Blair Zajac <bl...@or...> Plots of your system's performance - http://www.orcaware.com/orca/ |
From: Brian H. <bh...@sp...> - 2004-07-23 22:33:13
|
On Fri, 23 Jul 2004, Blair Zajac wrote: > Brian Hurt wrote: > > - Include it, but keep that particular file BSD copyright > > - Rewrite it so we can apply whatever license we want to it > > I don't see the point in rewriting it to put a more restrictive license on it. > I suggest just including it and keeping it BSD. > That would be my inclination as well- but I'd much rather rewrite it than relicence it. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian |
From: Brian H. <bh...@sp...> - 2004-07-23 22:34:53
|
Thought of a third possibility: - Ask the author's permission to relicense his work -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian |
From: Jesse G. <je...@wi...> - 2004-07-23 22:39:43
|
On Friday 23 July 2004 18:42, Brian Hurt wrote: > Thought of a third possibility: > - Ask the author's permission to relicense his work What a novel concept. :) -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |
From: Blair Z. <bl...@or...> - 2004-07-23 22:47:33
|
Brian Hurt wrote: > Thought of a third possibility: > - Ask the author's permission to relicense his work How about a dual license as Mozilla does it? That way any work done or improvements to it don't cause a fork (would it cause a fork?) Would there be a problem if we come up with a patch to the LGPL version, could that be placed back into the BSD version? Blair |
From: Brian H. <bh...@sp...> - 2004-07-24 01:50:51
|
On Fri, 23 Jul 2004, Blair Zajac wrote: > Brian Hurt wrote: > > > Thought of a third possibility: > > - Ask the author's permission to relicense his work > > How about a dual license as Mozilla does it? That way any work done or > improvements to it don't cause a fork (would it cause a fork?) Would > there be a problem if we come up with a patch to the LGPL version, could > that be placed back into the BSD version? It's much harder to go from GPL to BSD than it is the other direction. And I thought Mozilla only had one license- it was Python that had two. Also, dual licenses worry me. I am not a lawyer, and (probably) neither is anyone else on this list. We don't expect lawyers to be good programs based solely on their skills as a lawyer- but every yahoo who can AC post to Slashdot thinks he can write a contract or license that'd stand up in a court of law. The advantage of the GPL, LGPL, and BSD Licenses is that they have at least been run by lawyers, and the BSD license by a judge. I don't know how a judge or a lawyer would react to a dual license situation. And I don't think anyone else does either- but it's quite probably that the ruling would be that any action permitted by *either* license is acceptable. Which, in the case of GPL + BSD, is basically anything. About the only thing not kosher with the BSD license is changing the copyright. I can change the copyright under GPL, it just has to stay under the GPL. It is perfectly legal for me to grab a copy of Linux, and replace Linus Torvald's name with my own and release "brianux", the brilliant new OS I just wrote. So long as I released it under the GPL, it's perfectly legal (the law doesn't care about the ridicule I'd be subject to on slashdot). So it's quite possible that the dual GPL+BSD license is no license at all. It certainly has created a large amount of uncertainity which makes enforcement harder. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian |