digitalmars.D - std.algorithm for images
- Adam D. Ruppe (85/85) Apr 10 2011 I'm pretty happy with how simpledisplay.d is turning out, and want to
- bearophile (16/21) Apr 10 2011 I suggest you to always compile your D code with -w, in imagedraft.d the...
- Adam D. Ruppe (22/28) Apr 10 2011 OK, I'll try it on Windows next time I have my laptop out. I've
- Cliff Hudson (7/93) Apr 10 2011 You are on a tear with this image stuff :)
- Adam D. Ruppe (10/11) Apr 10 2011 I actually didn't consider it; since I already have decent homegrown
- Cliff Hudson (3/14) Apr 10 2011 Ahh, good point, I didn't look too closely at the licensing.
- spir (11/22) Apr 11 2011 There is a point I don't understand: if I'm right, LGPL as well as all o...
- Kagamin (2/7) Apr 11 2011 They can be used, but they can't become proprietary or Boost licensed.
- Francisco Almeida (5/12) Apr 11 2011 I'm sorry, but I don't understand this last statement. AFAIK, LGPL sourc...
- Adam D. Ruppe (12/15) Apr 11 2011 If the user already had the library installed, I *think* we'd be
- Russel Winder (19/21) Apr 11 2011 I would have to check but as far as I remember the (L)GPL does not
- Steven Schveighoffer (12/22) Apr 11 2011 IIUC, the LGPL is like applying the GPL to the library, but does not
- Jonas Drewsen (8/32) Apr 11 2011 Actually, if you haven't made any changes to the LGPL library that you
- Nick Sabalausky (12/45) Apr 11 2011 Sounds like a pain for the users of Phobos (and maybe the users of
- Russel Winder (33/42) Apr 11 2011 ty=20
- Nick Sabalausky (17/20) Apr 12 2011 I've never seen that as a realistic concern. Here's the basic scenario:
- Daniel Gibson (13/43) Apr 12 2011 What difference does it make? You don't have the money to reach
- Nick Sabalausky (15/61) Apr 12 2011 Sending out a press release is dirt-cheap. If EvilSoftwareCo is actually...
- Daniel Gibson (6/76) Apr 12 2011 What's left on that market when EvilSoftwareCo is already in it?
- Nick Sabalausky (18/53) Apr 12 2011 If I had actually created Office Suite and owned the rights to it, I do
- spir (9/12) Apr 12 2011 Isn't BSD license also unwelcome into Phobos? (/That/ issue was the orig...
- spir (13/34) Apr 12 2011 That's true. And I'm all for EvilSoftwareCo to get money for *their* wor...
- Andrew Wiley (17/43) Apr 12 2011 ity
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (7/9) Apr 12 2011 Note that both GPL and LGPL allow you to sell the software...
- Andrej Mitrovic (3/7) Apr 12 2011 Practically this means you can sell services. And not everyone is in
- spir (12/60) Apr 12 2011 Have not had a look at the Boost license, but a priori I doubt it to be ...
- Nick Sabalausky (10/14) Apr 12 2011 I don't trust any legal document that actually has any need for a separa...
- Steven Schveighoffer (20/72) Apr 12 2011 The requirement of the *end user* of phobos (i.e. the developer) to have...
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (10/13) Apr 12 2011 Have you looked at the license agreement for most Microsoft
- Steven Schveighoffer (15/23) Apr 12 2011 Right, but not because they used C, C++, Java, or whatever, to develop
- Nick Sabalausky (3/9) Apr 12 2011 FWIW, zlib is very similar to BSD, but doesn't have that problem.
- spir (10/49) Apr 12 2011 This is an empty assertion. Can you point to any study logically demonst...
- Daniel Gibson (15/73) Apr 12 2011 I don't have a study at hand, but companies often prefer BSD-style
- Daniel Gibson (27/65) Apr 12 2011 What I'd like to add: The GPL is an ideological license. Most companies
- Nick Sabalausky (19/20) Apr 12 2011 Technically, yes. Realistically, no. If there's software that's
- Daniel Gibson (24/50) Apr 12 2011 Even though the GPL isn't easy to read I think it's not too hard to
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (13/22) Apr 12 2011 for=20
- Daniel Gibson (4/21) Apr 12 2011 If you don't change the source a link to the project homepage should
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (11/32) Apr 13 2011 er for=20
- spir (13/15) Apr 12 2011 GPL is just one sample.
- Nick Sabalausky (14/26) Apr 12 2011 Clickwrap agreements are known to difficult to enforce even when the com...
- Steven Schveighoffer (7/42) Apr 12 2011 But why require it just for using the language? If I use a language, I ...
- Daniel Gibson (15/28) Apr 11 2011 The thing is: when someone develops a D application he would have to
- Jonas Drewsen (3/31) Apr 12 2011 OK. So it is an executive decision. Very nice to know and fine with me.
- Jacob Carlborg (5/33) Apr 12 2011 If Phobos dynamically link to a LGPL licensed library and doesn't
- Daniel Gibson (2/39) Apr 12 2011 Yeah but that's against the idea of Phobos being self-contained.
- spir (8/43) Apr 12 2011 Why care about the that readme file? Guess all software I have ever used...
- Daniel Gibson (11/54) Apr 12 2011 D is not a Linux/FOSS-only language, but also to be used on Windows and
- spir (8/12) Apr 12 2011 Windows apps have a menu entry just perfect for that kind of attribution...
- Steven Schveighoffer (9/16) Apr 12 2011 Any requirements placed on the end user are unacceptable. D is not mean...
- Kagamin (2/11) Apr 11 2011 I also wander, what people plan to do with libmysql? It's GPL.
- Daniel Gibson (17/30) Apr 11 2011 Doesn't mysql even have some retarded restriction like "it's GPL but may
- Nick Sabalausky (3/26) Apr 11 2011 PostgreSQL? ;)
- Daniel Gibson (8/40) Apr 11 2011 Well I'd always use PostgreSQL instead of MySQL when having the choice, ...
- spir (15/22) Apr 12 2011 I don't understand this story of shipping, neither. It seems to me D's s...
- Daniel Gibson (8/32) Apr 12 2011 Yeah this is all fine when you use a third-party lib, but IMHO for a
- spir (9/41) Apr 12 2011 Right, I now understand the point. But still find it an extremely light
- Fawzi Mohamed (24/79) Apr 12 2011 For my personal libs/programs I fully agree with spir:
- spir (12/33) Apr 12 2011 Thanks to everyone, I know understand the point and the choice made for ...
- dsimcha (4/7) Apr 11 2011 According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual
- Daniel Gibson (14/23) Apr 11 2011 Hmm.. seems like I've mixed up stuff, I only got my information via hear...
- spir (11/19) Apr 12 2011 There is a misconseption (or rather rethorical playing on words) in the
- Nick Sabalausky (7/24) Apr 12 2011 Except such software is more likely to have just simply used some other
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (12/31) Apr 12 2011 to
- spir (7/31) Apr 12 2011 True.
- Piotr Szturmaj (11/22) Apr 12 2011 There's a FOSS license exception for MySQL client library:
- Kagamin (2/8) Apr 12 2011 I believe, phobos is boost licensed in order to be corporations-friendly...
- Kagamin (3/4) Apr 12 2011 LOL, take a look at this:
- Piotr Szturmaj (9/13) Apr 12 2011 That's ridiculous. I've just googled for "The MySQL Protocol is
- Kagamin (2/5) Apr 12 2011 GPL is pretty simple: write GPL soft and there will be no problem.
- Adam D. Ruppe (87/87) Apr 10 2011 I spent a little more time on it and implemented simple PNG writing
- Walter Bright (2/6) Apr 10 2011 I don't know much about graphics, but your approach sounds awesome.
- Adam D. Ruppe (4/5) Apr 11 2011 The irony is neither do I! But, an algorithm is an algorithm
- spir (7/12) Apr 11 2011 Yes, that's definitely the great thing about generics, IMO.
- spir (21/107) Apr 11 2011 Works fine by me :-) Thank you very much again for this nice job.
- Adam D. Ruppe (23/30) Apr 11 2011 The main reason I went this way was to be like the rest of Phobos.
- Nick Sabalausky (11/20) Apr 11 2011 Boy, I just can't keep up with you!
I'm pretty happy with how simpledisplay.d is turning out, and want to spend some time thinking about the client side images now. I think a nice way to do it would be to go with ranges and templates, like std.algorithm, so things will work across many different image formats with the best efficiency and minimal coupling. But, we need to think about some specifics before going too far. Here's a first draft module to show the idea while doing some useful work. It's dependency free so you can download and play with ease. http://arsdnet.net/dcode/imagedraft.d If you also grab simpledisplay.d http://arsdnet.net/dcode/simpledisplay.d You can compile this little png display program: ======= import imagedraft; import std.stdio; import simpledisplay; void main(string[] args) { auto png = pngFromBytes(File(args[1]).byChunk(4096)); auto image = new Image(png.header.width, png.header.height); int y; foreach(line; png.byRgbaScanline) { foreach(x, color; line.pixels) image.putPixel(cast(int) x, cast(int) y, simpledisplay.Color(color.r, color.g, color.b, color.a)); y++; } displayImage(image); } ==== And use it as a base to play around and see your algorithm's results right in the window. (btw, that displayImage() function is what used to be image.display() in simpledisplay. A standalone function will let me separate dependencies better. It works the same way - just show it and wait for the user to hit any key to continue.) The foreach there is ugly. I was going to write up a demo of some actual algorithms for images, but I ended up spending most the day getting my BufferedInputRange and LazyPngFile to work correctly... But, you can see one of the big ideas: providing ranges on images of various formats that present the data to you in a requested standard format (any PNG image is lazily converted to an rgba list of lines here). It also shows how I plan to write other image format loaders - they take arbitrary input ranges, and lazily load and decode the file. (While I had a png loader before, it was in C style.... I'm hoping that it will be easier to port my bmp code now that I have a working foundation...) I'll write an image saver too. It will take an rgbaScanLine range and save it to the correct format - png, bmp, whatever. Now, back to the main idea here. I wish I had more time. If I fleshed out this existing range a little more, we could do fun things like call std.algorithm.levenshteinDistance on it.. but right now, it's just an input range, which is fairly limited. I figure the best thing to do is offer whatever facilities the source range offers, so if you give it an array, you can save(), back(), etc. too. Still, we can run a few functions on it. foreach(line; filter!"a.pixels[0].r > 200"(png.byRgbaScanline)) { } Only keeps lines with a lot of red in the first pixel. So that's pretty cool. Aaaanyway, I want to have a bunch of algorithms written in here that can work on these ranges, capable of doing both in-place and lazy changes to your image. Since I messed up the time, I only wrote one (and it sucks, hard), but it's the idea I have in mind: the convertToGreyscale function. Any image that provides a range it can use will work for it. What kind of ranges would be useful? A by line surely is, which is why I started with it. A byPixel perhaps? Maybe a byBlock? Though, it for byPixel, it seems like opApply is the way to do it. Maybe it can even shove it off to the GPU to do the work. That's beyond my knowledge, but David Simcha has done some cool stuff with foreach and parallelism, and this is basically the same concept, so I'm sure it can be done. Then, of course, you'll surely still want opIndex into the pixels too. I was hoping to have time to write a gaussian blur function to put the idea to the test... The other thing is drawing. I don't think ranges will help much there. Drawing algorithms will probably be ok with opIndexAssign into the pixels. But, it's time for me to get to the work I was supposed to do today. If nothing else, hopefully that PNG loader in there will be useful, but I really do think there's a lot of potential in the idea of a std.algorithm for images and would like any input you have. Thanks for all the feedback this weekend, everyone!
Apr 10 2011
Adam D. Ruppe:I'm pretty happy with how simpledisplay.d is turning out,I have tried the fractal tree program, the window doesn't close if you click on the button on the top right.http://arsdnet.net/dcode/imagedraft.dI suggest you to always compile your D code with -w, in imagedraft.d there is a switch (line 328) without default. foreach(line; filter!"a.pixels[0].r > 200"(png.byRgbaScanline)) { I suggest ==> foreach(line; filter!"a.pixels[0].r > 200"(png.byRGBAline())) { Or even: foreach(line; filter!"a.pixels[0].r > 200"(png.byRGBAScanline())) {What kind of ranges would be useful?Several basic image processing algorithms use a 3x3 (or bigger) neighbourhood to process images.A byPixel perhaps?Of course :-) For few ideas look at Python PIL docs: http://www.pythonware.com/library/pil/handbook/index.htm http://www.pythonware.com/library/pil/handbook/image.htmThanks for all the feedback this weekend, everyone!You are welcome :-) Bye, bearophile
Apr 10 2011
bearophile wrote:I have tried the fractal tree program, the window doesn't close if you click on the button on the top right.OK, I'll try it on Windows next time I have my laptop out. I've been doing everything on Linux and Wine so far, so there's probably a few little differences that need some attention. There's still a lot of little things that need to be done to finish it. Probably still several full day's work to cross the t's and dot the i's.I suggest you to always compile your D code with -w, in imagedraft.d there is a switch (line 328) without default.Changed. It's supposed to throw there (all values allowed in the spec are handled), but I guess it would be better to shut the compiler up and maybe use a more specific exception at the same time.foreach(line; byRGBAScanline)Annoyingly, this seems to be the prevailing Phobos style, so I'll probably change to that. I personally dislike the string of capitals, but best to be consistent with the rest of the lib.For few ideas look at Python PIL docs:Hmm, it doesn't seem to have the interfaces required. While we could make some monster classes that do all the work in a black box, I'm hoping to take an STL approach here, where the actual data structures are as de-coupled as possible from the algorithms. For that, an API listing doesn't help much.... we'll have to study the requirements of the algorithms themselves. There is a good list of things to look up there, though.
Apr 10 2011
You are on a tear with this image stuff :) Have you considered wrapping something like DevIL? http://openil.sourceforge.net/features.php Probably has all the features you could ever want and is cross-platform. <http://openil.sourceforge.net/features.php> - Cliff On Sun, Apr 10, 2011 at 5:10 PM, Adam D. Ruppe <destructionator gmail.com>wrote:I'm pretty happy with how simpledisplay.d is turning out, and want to spend some time thinking about the client side images now. I think a nice way to do it would be to go with ranges and templates, like std.algorithm, so things will work across many different image formats with the best efficiency and minimal coupling. But, we need to think about some specifics before going too far. Here's a first draft module to show the idea while doing some useful work. It's dependency free so you can download and play with ease. http://arsdnet.net/dcode/imagedraft.d If you also grab simpledisplay.d http://arsdnet.net/dcode/simpledisplay.d You can compile this little png display program: ======= import imagedraft; import std.stdio; import simpledisplay; void main(string[] args) { auto png = pngFromBytes(File(args[1]).byChunk(4096)); auto image = new Image(png.header.width, png.header.height); int y; foreach(line; png.byRgbaScanline) { foreach(x, color; line.pixels) image.putPixel(cast(int) x, cast(int) y, simpledisplay.Color(color.r, color.g, color.b, color.a)); y++; } displayImage(image); } ==== And use it as a base to play around and see your algorithm's results right in the window. (btw, that displayImage() function is what used to be image.display() in simpledisplay. A standalone function will let me separate dependencies better. It works the same way - just show it and wait for the user to hit any key to continue.) The foreach there is ugly. I was going to write up a demo of some actual algorithms for images, but I ended up spending most the day getting my BufferedInputRange and LazyPngFile to work correctly... But, you can see one of the big ideas: providing ranges on images of various formats that present the data to you in a requested standard format (any PNG image is lazily converted to an rgba list of lines here). It also shows how I plan to write other image format loaders - they take arbitrary input ranges, and lazily load and decode the file. (While I had a png loader before, it was in C style.... I'm hoping that it will be easier to port my bmp code now that I have a working foundation...) I'll write an image saver too. It will take an rgbaScanLine range and save it to the correct format - png, bmp, whatever. Now, back to the main idea here. I wish I had more time. If I fleshed out this existing range a little more, we could do fun things like call std.algorithm.levenshteinDistance on it.. but right now, it's just an input range, which is fairly limited. I figure the best thing to do is offer whatever facilities the source range offers, so if you give it an array, you can save(), back(), etc. too. Still, we can run a few functions on it. foreach(line; filter!"a.pixels[0].r > 200"(png.byRgbaScanline)) { } Only keeps lines with a lot of red in the first pixel. So that's pretty cool. Aaaanyway, I want to have a bunch of algorithms written in here that can work on these ranges, capable of doing both in-place and lazy changes to your image. Since I messed up the time, I only wrote one (and it sucks, hard), but it's the idea I have in mind: the convertToGreyscale function. Any image that provides a range it can use will work for it. What kind of ranges would be useful? A by line surely is, which is why I started with it. A byPixel perhaps? Maybe a byBlock? Though, it for byPixel, it seems like opApply is the way to do it. Maybe it can even shove it off to the GPU to do the work. That's beyond my knowledge, but David Simcha has done some cool stuff with foreach and parallelism, and this is basically the same concept, so I'm sure it can be done. Then, of course, you'll surely still want opIndex into the pixels too. I was hoping to have time to write a gaussian blur function to put the idea to the test... The other thing is drawing. I don't think ranges will help much there. Drawing algorithms will probably be ok with opIndexAssign into the pixels. But, it's time for me to get to the work I was supposed to do today. If nothing else, hopefully that PNG loader in there will be useful, but I really do think there's a lot of potential in the idea of a std.algorithm for images and would like any input you have. Thanks for all the feedback this weekend, everyone!
Apr 10 2011
Cliff Hudson wrote:Have you considered wrapping something like DevIL?I actually didn't consider it; since I already have decent homegrown loaders for a few formats I figured that'd be good enough, for now at least. But, looking now, DevIL is LGPL. As I'm hoping to get into Phobos, that will mean licensing problems. Phobos should Just Work for endusers, meaning it ought to package everything it needs with it, with the exception of operating system libraries. Packaging the source for a big library to satisfy the LGPL won't really work there :-(
Apr 10 2011
Ahh, good point, I didn't look too closely at the licensing. - Cliff On Sun, Apr 10, 2011 at 5:45 PM, Adam D. Ruppe <destructionator gmail.com>wrote:Cliff Hudson wrote:Have you considered wrapping something like DevIL?I actually didn't consider it; since I already have decent homegrown loaders for a few formats I figured that'd be good enough, for now at least. But, looking now, DevIL is LGPL. As I'm hoping to get into Phobos, that will mean licensing problems. Phobos should Just Work for endusers, meaning it ought to package everything it needs with it, with the exception of operating system libraries. Packaging the source for a big library to satisfy the LGPL won't really work there :-(
Apr 10 2011
On 04/11/2011 02:45 AM, Adam D. Ruppe wrote:Cliff Hudson wrote:There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the Boost license? Where's the bug? Denis -- _________________ vita es estrany spir.wikidot.comI actually didn't consider it; since I already have decent homegrown loaders for a few formats I figured that'd be good enough, for now at least. But, looking now, DevIL is LGPL. As I'm hoping to get into Phobos, that will mean licensing problems. Phobos should Just Work for endusers, meaning it ought to package everything it needs with it, with the exception of operating system libraries. Packaging the source for a big library to satisfy the LGPL won't really work there :-(Have you considered wrapping something like DevIL?
Apr 11 2011
spir Wrote:There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the Boost license? Where's the bug?They can be used, but they can't become proprietary or Boost licensed.
Apr 11 2011
== Quote from Kagamin (spam here.lot)'s articlespir Wrote:license?There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the BoostI'm sorry, but I don't understand this last statement. AFAIK, LGPL source code may be used for licensed software, as long as it is compiled so as to keep the binaries separate (DLL or shared object).Where's the bug?They can be used, but they can't become proprietary or Boost licensed.
Apr 11 2011
spir wrote:There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work.If the user already had the library installed, I *think* we'd be fine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library. We want to keep distributing programs as easy as possible. I'm not against using lgpl things, but it should be an extra step so the programmer realizes he has another hurdle to deal with (either packaging the source with his app or adding instructions to the installer/readme file so the user can install the library themselves). In short, it will work, but it won't *Just Work*, and Phobos definitely should Just Work.
Apr 11 2011
On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]fine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight. [ . . . ] --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 11 2011
On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk> wrote:On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]IIUC, the LGPL is like applying the GPL to the library, but does not restrict proprietary software from linking to it. I think this means you can distribute your proprietary software without providing source code. However, if you supply the library (which is covered under the same rules as the GPL), then you must provide or provide upon request the source code to the LGPL-covered library. If you don't ship the library, then you don't have to supply the source code, but then you are shipping a binary that doesn't work unless they also download the LGPL library separately. It all adds up to "not going to be in druntime/Phobos" :) -Stevefine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight.
Apr 11 2011
On 11/04/11 22.01, Steven Schveighoffer wrote:On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk> wrote:Actually, if you haven't made any changes to the LGPL library that you are distribution then you can just refer to the projects homepage for the source code. This also means that putting the list of URLs for the used LGPL libraries in the Phobos packages would suffice. Can't get much easier than that. /JonasOn Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]IIUC, the LGPL is like applying the GPL to the library, but does not restrict proprietary software from linking to it. I think this means you can distribute your proprietary software without providing source code. However, if you supply the library (which is covered under the same rules as the GPL), then you must provide or provide upon request the source code to the LGPL-covered library. If you don't ship the library, then you don't have to supply the source code, but then you are shipping a binary that doesn't work unless they also download the LGPL library separately. It all adds up to "not going to be in druntime/Phobos" :) -Stevefine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight.
Apr 11 2011
"Jonas Drewsen" <jdrewsen nospam.com> wrote in message news:invnrn$2pgf$1 digitalmars.com...On 11/04/11 22.01, Steven Schveighoffer wrote:Sounds like a pain for the users of Phobos (and maybe the users of Phobos-developed software?). Regardless, I think we've clearly demonstrated the complete impenetrability of (L)GPL. I've long since given up trying to understand it, and I seriously doubt that anyone really truly understands it (it's the C++ of the legal world). Even if you do miraculously understand one form of it, there still probably about 10 other versions and half of them are even incompatible with each other (in poorly-understood ways). The whole thing's just a damn mess. I've always found it best to just avoid any (L)GPL source or library outright. Not worth the trouble.On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk> wrote:Actually, if you haven't made any changes to the LGPL library that you are distribution then you can just refer to the projects homepage for the source code. This also means that putting the list of URLs for the used LGPL libraries in the Phobos packages would suffice. Can't get much easier than that.On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]IIUC, the LGPL is like applying the GPL to the library, but does not restrict proprietary software from linking to it. I think this means you can distribute your proprietary software without providing source code. However, if you supply the library (which is covered under the same rules as the GPL), then you must provide or provide upon request the source code to the LGPL-covered library. If you don't ship the library, then you don't have to supply the source code, but then you are shipping a binary that doesn't work unless they also download the LGPL library separately. It all adds up to "not going to be in druntime/Phobos" :)fine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight.
Apr 11 2011
On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote: [ . . . ]=20 Regardless, I think we've clearly demonstrated the complete impenetrabili=ty=20of (L)GPL. I've long since given up trying to understand it, and I seriou=sly=20doubt that anyone really truly understands it (it's the C++ of the legal==20world). Even if you do miraculously understand one form of it, there stil=l=20probably about 10 other versions and half of them are even incompatible w=ith=20each other (in poorly-understood ways). The whole thing's just a damn mes=s.=20I've always found it best to just avoid any (L)GPL source or library=20 outright. Not worth the trouble.GPL and LGPL are fine licences. They only appear impenetrable because there is no case law in the USA or UK to define the accepted meaning as opposed to the intended meaning. It may be that in countries that do not rely on case law to give meaning to statutes, contracts and licence, things are different. Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community. I think LGPL is the preferred licence for all non-proprietary software and am very glad to find libraries that use it. Sadly the Java world seems to have slipped from using LGPL to being obsessed with using ASL 2.0 and professing hatred of LGPL. ASL 2.0 claims to have a patent clause unlike all the other non (L)GPL licences, but until this is tested in court so that there is case law no-one, not even lawyers, actually know what the licences mean or entail. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 11 2011
"Russel Winder" <russel russel.org.uk> wrote in message news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community.I've never seen that as a realistic concern. Here's the basic scenario: 1. I make program Foo and release it under BSD/MIT/etc. 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing. That's what's seen as the problem, right? I'm not concerned because the obvious next steps are: 3. I go around spreading the fact that EvilSoftwareCo's Foo is available for free (both meanings of the term) from my site. 4. There isn't a fucking thing EvilSoftwareCo can do about it. "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as FooPlus? Your Foo doesn't get any of those extras!" Don't care. If they put in the time and effort to add value to something, then they *should* be allowed to ask for compensation for their work under whatever business model they choose. And if the value they've added is merely trivial, then A. My version of Foo can still compete and B. I can just add it to my Foo myself (or anyone else can).
Apr 12 2011
Am 12.04.2011 12:24, schrieb Nick Sabalausky:"Russel Winder" <russel russel.org.uk> wrote in message news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...What difference does it make? You don't have the money to reach EvilSoftwareCo's (potential) costumers. Ranting in your blogs and some mailinglists or whatever won't change anything. They do big marketing to sell your software (with their small additions), they claim its stable and certified etcpp. So they still make big money with your code without giving anything (neither code nor money) back.Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community.I've never seen that as a realistic concern. Here's the basic scenario: 1. I make program Foo and release it under BSD/MIT/etc. 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing. That's what's seen as the problem, right? I'm not concerned because the obvious next steps are: 3. I go around spreading the fact that EvilSoftwareCo's Foo is available for free (both meanings of the term) from my site.4. There isn't a fucking thing EvilSoftwareCo can do about it. "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as FooPlus? Your Foo doesn't get any of those extras!" Don't care. If they put in the time and effort to add value to something, then they *should* be allowed to ask for compensation for their work under whatever business model they choose. And if the value they've added is merely trivial, then A. My version of Foo can still compete and B. I can just add it to my Foo myself (or anyone else can).The problem is not only that they get money for your code (+their extras), it's also that suddenly there's an incompatible version of your program. Maybe it's incompatible with your file formats etc. If their FooPlus is successful your Foo may become obsolete.
Apr 12 2011
"Daniel Gibson" <metalcaedes gmail.com> wrote in message news:io1als$jsc$15 digitalmars.com...Am 12.04.2011 12:24, schrieb Nick Sabalausky:Sending out a press release is dirt-cheap. If EvilSoftwareCo is actually making significant money, then it's very likely that some news outlets would jump at a story like "Big company charging people for a free program." Or even better yet: EvilSoftwareCo would have done the hard work of proving that there's a viable commercial market for Foo. Since I already have the same product, I either de-OSS the next version of Foo or cave and make it GPL, go get the world's easiest VC or business loan (again, EvilSoftwareCo did the hard work of proving the viable market), use those funds to advertise/market about being "The real creator of Foo", undercut EvilSoftwareCo, and then laugh all the way to the bank as EvilSoftwareCo goes under."Russel Winder" <russel russel.org.uk> wrote in message news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...What difference does it make? You don't have the money to reach EvilSoftwareCo's (potential) costumers. Ranting in your blogs and some mailinglists or whatever won't change anything. They do big marketing to sell your software (with their small additions), they claim its stable and certified etcpp. So they still make big money with your code without giving anything (neither code nor money) back.Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community.I've never seen that as a realistic concern. Here's the basic scenario: 1. I make program Foo and release it under BSD/MIT/etc. 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing. That's what's seen as the problem, right? I'm not concerned because the obvious next steps are: 3. I go around spreading the fact that EvilSoftwareCo's Foo is available for free (both meanings of the term) from my site.That would still be equally possible even if FooPlus were a completely open project.4. There isn't a fucking thing EvilSoftwareCo can do about it. "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as FooPlus? Your Foo doesn't get any of those extras!" Don't care. If they put in the time and effort to add value to something, then they *should* be allowed to ask for compensation for their work under whatever business model they choose. And if the value they've added is merely trivial, then A. My version of Foo can still compete and B. I can just add it to my Foo myself (or anyone else can).The problem is not only that they get money for your code (+their extras), it's also that suddenly there's an incompatible version of your program. Maybe it's incompatible with your file formats etc. If their FooPlus is successful your Foo may become obsolete.
Apr 12 2011
Am 12.04.2011 13:02, schrieb Nick Sabalausky:"Daniel Gibson" <metalcaedes gmail.com> wrote in message news:io1als$jsc$15 digitalmars.com...What's left on that market when EvilSoftwareCo is already in it? "I wanna sell a Office Suite, Microsoft makes millions with it so it's a viable market"Am 12.04.2011 12:24, schrieb Nick Sabalausky:Sending out a press release is dirt-cheap. If EvilSoftwareCo is actually making significant money, then it's very likely that some news outlets would jump at a story like "Big company charging people for a free program." Or even better yet: EvilSoftwareCo would have done the hard work of proving that there's a viable commercial market for Foo. Since I already have the same product, I either de-OSS the next version of Foo or cave and make it GPL, go get the world's easiest VC or business loan (again, EvilSoftwareCo did the hard work of proving the viable market), use those funds to advertise/market about being "The real creator of Foo", undercut EvilSoftwareCo, and then laugh all the way to the bank as EvilSoftwareCo goes under."Russel Winder" <russel russel.org.uk> wrote in message news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...What difference does it make? You don't have the money to reach EvilSoftwareCo's (potential) costumers. Ranting in your blogs and some mailinglists or whatever won't change anything. They do big marketing to sell your software (with their small additions), they claim its stable and certified etcpp. So they still make big money with your code without giving anything (neither code nor money) back.Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community.I've never seen that as a realistic concern. Here's the basic scenario: 1. I make program Foo and release it under BSD/MIT/etc. 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing. That's what's seen as the problem, right? I'm not concerned because the obvious next steps are: 3. I go around spreading the fact that EvilSoftwareCo's Foo is available for free (both meanings of the term) from my site.But than you could at least integrate their changes into your version to support their file format etcThat would still be equally possible even if FooPlus were a completely open project.4. There isn't a fucking thing EvilSoftwareCo can do about it. "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as FooPlus? Your Foo doesn't get any of those extras!" Don't care. If they put in the time and effort to add value to something, then they *should* be allowed to ask for compensation for their work under whatever business model they choose. And if the value they've added is merely trivial, then A. My version of Foo can still compete and B. I can just add it to my Foo myself (or anyone else can).The problem is not only that they get money for your code (+their extras), it's also that suddenly there's an incompatible version of your program. Maybe it's incompatible with your file formats etc. If their FooPlus is successful your Foo may become obsolete.
Apr 12 2011
"Daniel Gibson" <metalcaedes gmail.com> wrote in message news:io1c0b$jsc$18 digitalmars.com...Am 12.04.2011 13:02, schrieb Nick Sabalausky:If I had actually created Office Suite and owned the rights to it, I do think I would have a good shot at making some inroads with the combination of "I made it and own it" and undercutting. And even if not, at least lots of people would be using my software. If I had actually been giving it away in the first place, then clearly that would have been my larger goal anyway. Being "creator of MS Office" would look pretty good on a resume', and that would be something they they would have actually *helped* you with - something you wouldn't likely have had otherwise. And most of all, I really think the chances of getting irreprably screwed over like that by putting a program out as BSD instead of GPL are small enough to just not be worth worrying about. Heck, you'd probably have a better chance of getting killed by another car on the way to the grocery store.Sending out a press release is dirt-cheap. If EvilSoftwareCo is actually making significant money, then it's very likely that some news outlets would jump at a story like "Big company charging people for a free program." Or even better yet: EvilSoftwareCo would have done the hard work of proving that there's a viable commercial market for Foo. Since I already have the same product, I either de-OSS the next version of Foo or cave and make it GPL, go get the world's easiest VC or business loan (again, EvilSoftwareCo did the hard work of proving the viable market), use those funds to advertise/market about being "The real creator of Foo", undercut EvilSoftwareCo, and then laugh all the way to the bank as EvilSoftwareCo goes under.What's left on that market when EvilSoftwareCo is already in it? "I wanna sell a Office Suite, Microsoft makes millions with it so it's a viable market"Yea, but now the whole argument has been whittled down to quite a lot of "if"s.But than you could at least integrate their changes into your version to support their file format etcThe problem is not only that they get money for your code (+their extras), it's also that suddenly there's an incompatible version of your program. Maybe it's incompatible with your file formats etc. If their FooPlus is successful your Foo may become obsolete.That would still be equally possible even if FooPlus were a completely open project.
Apr 12 2011
On 04/12/2011 01:31 PM, Nick Sabalausky wrote:And most of all, I really think the chances of getting irreprably screwed over like that by putting a program out as BSD instead of GPL are small enough to just not be worth worrying about.Isn't BSD license also unwelcome into Phobos? (/That/ issue was the original point of the thread.) And what about the creative commons attribution-share alike (which I like)? Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
On 04/12/2011 12:24 PM, Nick Sabalausky wrote:"Russel Winder"<russel russel.org.uk> wrote in message news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...That's true. And I'm all for EvilSoftwareCo to get money for *their* work; rather than for theirs *and* yours ;-) (where 'you' may also be a whole community -- that would not even have the opportunity to reuse EvilSoftwareCo's advances) Just like I'm all for music editors to get money for their work: edition, or rather distribution. But in reality, they used to get a de facto tax on listening to music (via copyright). Denis -- _________________ vita es estrany spir.wikidot.comPersonally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community.I've never seen that as a realistic concern. Here's the basic scenario: 1. I make program Foo and release it under BSD/MIT/etc. 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing. That's what's seen as the problem, right? I'm not concerned because the obvious next steps are: 3. I go around spreading the fact that EvilSoftwareCo's Foo is available for free (both meanings of the term) from my site. 4. There isn't a fucking thing EvilSoftwareCo can do about it. "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as FooPlus? Your Foo doesn't get any of those extras!" Don't care. If they put in the time and effort to add value to something, then they *should* be allowed to ask for compensation for their work under whatever business model they choose. And if the value they've added is merely trivial, then A. My version of Foo can still compete and B. I can just add it to my Foo myself (or anyone else can).
Apr 12 2011
On Tue, Apr 12, 2011 at 1:52 AM, Russel Winder <russel russel.org.uk> wrote= :On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote: [ . . . ]ityRegardless, I think we've clearly demonstrated the complete impenetrabil=uslyof (L)GPL. I've long since given up trying to understand it, and I serio=lldoubt that anyone really truly understands it (it's the C++ of the legal world). Even if you do miraculously understand one form of it, there sti=withprobably about 10 other versions and half of them are even incompatible =ss.each other (in poorly-understood ways). The whole thing's just a damn me=sI've always found it best to just avoid any (L)GPL source or library outright. Not worth the trouble.GPL and LGPL are fine licences. =A0They only appear impenetrable because there is no case law in the USA or UK to define the accepted meaning as opposed to the intended meaning. =A0It may be that in countries that do not rely on case law to give meaning to statutes, contracts and licence, things are different. Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community. =A0I think LGPL i=the preferred licence for all non-proprietary software and am very glad to find libraries that use it. Sadly the Java world seems to have slipped from using LGPL to being obsessed with using ASL 2.0 and professing hatred of LGPL. =A0ASL 2.0 claims to have a patent clause unlike all the other non (L)GPL licences, but until this is tested in court so that there is case law no-one, not even lawyers, actually know what the licences mean or entail.The Java world likes ASL precisely because software licensed under it can be sold. Take a look at the signature lines of the main contributors to large open source Java projects. It's common for large companies to pay programmers to develop open source software that's eventually shipped in products, and at the end of the day, the community benefits. Now yes, it's entirely an honor system, and there's certainly a risk involved, but in general, the ASL has made Java's open source community grow quite a bit.
Apr 12 2011
Andrew Wiley wrote:The Java world likes ASL precisely because software licensed under it can be sold.Note that both GPL and LGPL allow you to sell the software... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
On 4/12/11, "J=E9r=F4me M. Berger" <jeberger free.fr> wrote:Andrew Wiley wrote:Practically this means you can sell services. And not everyone is in the business of services.The Java world likes ASL precisely because software licensed under it can be sold.Note that both GPL and LGPL allow you to sell the software...
Apr 12 2011
On 04/12/2011 01:47 AM, Nick Sabalausky wrote:"Jonas Drewsen"<jdrewsen nospam.com> wrote in message news:invnrn$2pgf$1 digitalmars.com...I don't understand where the pain lies, here.On 11/04/11 22.01, Steven Schveighoffer wrote:Sounds like a pain for the users of Phobos (and maybe the users of Phobos-developed software?).On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder<russel russel.org.uk> wrote:Actually, if you haven't made any changes to the LGPL library that you are distribution then you can just refer to the projects homepage for the source code. This also means that putting the list of URLs for the used LGPL libraries in the Phobos packages would suffice. Can't get much easier than that.On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]IIUC, the LGPL is like applying the GPL to the library, but does not restrict proprietary software from linking to it. I think this means you can distribute your proprietary software without providing source code. However, if you supply the library (which is covered under the same rules as the GPL), then you must provide or provide upon request the source code to the LGPL-covered library. If you don't ship the library, then you don't have to supply the source code, but then you are shipping a binary that doesn't work unless they also download the LGPL library separately. It all adds up to "not going to be in druntime/Phobos" :)fine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight.Regardless, I think we've clearly demonstrated the complete impenetrability of (L)GPL. I've long since given up trying to understand it, and I seriously doubt that anyone really truly understands it (it's the C++ of the legal world). Even if you do miraculously understand one form of it, there still probably about 10 other versions and half of them are even incompatible with each other (in poorly-understood ways). The whole thing's just a damn mess.Have not had a look at the Boost license, but a priori I doubt it to be more "penetrable" than any other open-source one. They all are somewhat convoluted because they use a right-privating legal tool (a license) to /provide/ rights to the user.I've always found it best to just avoid any (L)GPL source or library outright. Not worth the trouble.What about other ones, like Creative Commons licenses? Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
"spir" <denis.spir gmail.com> wrote in message news:mailman.3420.1302596459.4748.digitalmars-d puremagic.com...On 04/12/2011 01:47 AM, Nick Sabalausky wrote:I don't trust any legal document that actually has any need for a separate "plain English" version. The one thing that will change my mind on that is if I hear from a reliable source that "plain English" versions can be legally binding and take precedence over the legalese version when there's a discrepancy. I am a big fan of zlib/libpng though. And I like MIT/new-BSD, too. Not exactly thrilled about Boost, but I am ok with it. It's far more understandable than (L)GPL, at least.I've always found it best to just avoid any (L)GPL source or library outright. Not worth the trouble.What about other ones, like Creative Commons licenses?
Apr 12 2011
On Tue, 12 Apr 2011 04:20:44 -0400, spir <denis.spir gmail.com> wrote:On 04/12/2011 01:47 AM, Nick Sabalausky wrote:The requirement of the *end user* of phobos (i.e. the developer) to have to provide means to download/access the library. For instance, if I make a boxed game written in D, I also have to worry about LGPL and making sure the end user (who likely cares not at all about the LGPL'd library) can access the source. This means putting their license and either source code or link to the source code in my documentation. It might be worth it if I want that library badly enough, but it shouldn't be *required* just for writing code in the D language. A language should be free of such encumbrances. A language is a tool, and should not require special licensing for the end user to pass on to their clients. The *tools* to use the language can be whatever license you want, but the user's resulting product should be able to be licensed however they want. This, BTW, is why BSD is not acceptable for Phobos. The requirement to put the license in the documentation (even if you distribute binary-only) is no good. Yes, people have said that you can embed the license in the binary via a string, but the stigma is still there. There are some companies that will balk at that requirement. D should be available to anyone who wants to use it. -Steve"Jonas Drewsen"<jdrewsen nospam.com> wrote in message news:invnrn$2pgf$1 digitalmars.com...I don't understand where the pain lies, here.On 11/04/11 22.01, Steven Schveighoffer wrote:Sounds like a pain for the users of Phobos (and maybe the users of Phobos-developed software?).On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder<russel russel.org.uk> wrote:Actually, if you haven't made any changes to the LGPL library that you are distribution then you can just refer to the projects homepage for the source code. This also means that putting the list of URLs for the used LGPL libraries in the Phobos packages would suffice. Can't get much easier than that.On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]IIUC, the LGPL is like applying the GPL to the library, but does not restrict proprietary software from linking to it. I think this means you can distribute your proprietary software without providing source code. However, if you supply the library (which is covered under the same rules as the GPL), then you must provide or provide upon request the source code to the LGPL-covered library. If you don't ship the library, then you don't have to supply the source code, but then you are shipping a binary that doesn't work unless they also download the LGPL library separately. It all adds up to "not going to be in druntime/Phobos" :)fine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight.
Apr 12 2011
Steven Schveighoffer wrote:This, BTW, is why BSD is not acceptable for Phobos.=20 The requirement to put the license in the documentation (even if you distribute binary-only) is no good.Have you looked at the license agreement for most Microsoft products? or most major video games? They all have some line saying that "this product uses software developed by such and such", which is no less than the BSD requires... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
On Tue, 12 Apr 2011 13:54:19 -0400, Jérôme M. Berger <jeberger free.fr> wrote:Steven Schveighoffer wrote:Right, but not because they used C, C++, Java, or whatever, to develop it. It's because they *chose* to include that BSD-licensed library. If that library is a part of Phobos, *any* D-developed program will require that attribution, which means if you don't want to have that attribution requirement, you will choose another language. I'm not saying BSD is bad, or (L)GPL is bad, they are fine licenses to choose for any OSS project you want, but they are not appropriate for the core standard library. Of course, there are exceptions. For example glibc is practically guaranteed to be on any Linux system, so having it be LGPL works perfectly fine -- there is no need to redistribute it. On the other hand, having to use the client's libc can run into bad compatibility issues in some cases. -SteveThis, BTW, is why BSD is not acceptable for Phobos. The requirement to put the license in the documentation (even if you distribute binary-only) is no good.Have you looked at the license agreement for most Microsoft products? or most major video games? They all have some line saying that "this product uses software developed by such and such", which is no less than the BSD requires...
Apr 12 2011
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message news:op.vttw2bybeav7ka steve-laptop...This, BTW, is why BSD is not acceptable for Phobos. The requirement to put the license in the documentation (even if you distribute binary-only) is no good. Yes, people have said that you can embed the license in the binary via a string, but the stigma is still there. There are some companies that will balk at that requirement. D should be available to anyone who wants to use it.FWIW, zlib is very similar to BSD, but doesn't have that problem.
Apr 12 2011
On 04/12/2011 09:05 AM, Andrew Wiley wrote:On Tue, Apr 12, 2011 at 1:52 AM, Russel Winder<russel russel.org.uk> wrote:This is complete misinterpretation. *All* free software can be sold.On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote: [ . . . ]The Java world likes ASL precisely because software licensed under it can be sold. Take a look at the signature lines of the main contributors to large open source Java projects. It's common for large companies to pay programmers to develop open source software that's eventually shipped in products, and at the end of the day, the community benefits.Regardless, I think we've clearly demonstrated the complete impenetrability of (L)GPL. I've long since given up trying to understand it, and I seriously doubt that anyone really truly understands it (it's the C++ of the legal world). Even if you do miraculously understand one form of it, there still probably about 10 other versions and half of them are even incompatible with each other (in poorly-understood ways). The whole thing's just a damn mess. I've always found it best to just avoid any (L)GPL source or library outright. Not worth the trouble.GPL and LGPL are fine licences. They only appear impenetrable because there is no case law in the USA or UK to define the accepted meaning as opposed to the intended meaning. It may be that in countries that do not rely on case law to give meaning to statutes, contracts and licence, things are different. Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community. I think LGPL is the preferred licence for all non-proprietary software and am very glad to find libraries that use it. Sadly the Java world seems to have slipped from using LGPL to being obsessed with using ASL 2.0 and professing hatred of LGPL. ASL 2.0 claims to have a patent clause unlike all the other non (L)GPL licences, but until this is tested in court so that there is case law no-one, not even lawyers, actually know what the licences mean or entail.Now yes, it's entirely an honor system, and there's certainly a risk involved, but in general, the ASL has made Java's open source community grow quite a bit.This is an empty assertion. Can you point to any study logically demonstrating any relation between Java's preferred license and "Java's open source community grow[ing] quite a bit"? Or even to a theoretical reason for this? Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
Am 12.04.2011 10:29, schrieb spir:On 04/12/2011 09:05 AM, Andrew Wiley wrote:I don't have a study at hand, but companies often prefer BSD-style licenses to the GPL because they want to be able to reuse the code in their proprietary without open-sourcing them as well. Example: Apple reimplements the samba-service (SMB - Windows file sharing) because they don't like the GPLv3. And they push LLVM because they don't want to use GCC anymore. (But maybe this is because of the GPLv3 and not the GPL in general.) Furthermore many (most?) Open Source Java projects are mainly developed by companies and they chose this kind of license, so I think it's reasonable to assume that they prefer this kind of license to the GPL and wouldn't invest so much into these projects if they had a license they disliked. Cheers, - DanielOn Tue, Apr 12, 2011 at 1:52 AM, Russel Winder<russel russel.org.uk> wrote:This is complete misinterpretation. *All* free software can be sold.On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote: [ . . . ]The Java world likes ASL precisely because software licensed under it can be sold. Take a look at the signature lines of the main contributors to large open source Java projects. It's common for large companies to pay programmers to develop open source software that's eventually shipped in products, and at the end of the day, the community benefits.Regardless, I think we've clearly demonstrated the complete impenetrability of (L)GPL. I've long since given up trying to understand it, and I seriously doubt that anyone really truly understands it (it's the C++ of the legal world). Even if you do miraculously understand one form of it, there still probably about 10 other versions and half of them are even incompatible with each other (in poorly-understood ways). The whole thing's just a damn mess. I've always found it best to just avoid any (L)GPL source or library outright. Not worth the trouble.GPL and LGPL are fine licences. They only appear impenetrable because there is no case law in the USA or UK to define the accepted meaning as opposed to the intended meaning. It may be that in countries that do not rely on case law to give meaning to statutes, contracts and licence, things are different. Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid since they allow organizations to take software, sell it for profit and return absolutely nothing to the development community. I think LGPL is the preferred licence for all non-proprietary software and am very glad to find libraries that use it. Sadly the Java world seems to have slipped from using LGPL to being obsessed with using ASL 2.0 and professing hatred of LGPL. ASL 2.0 claims to have a patent clause unlike all the other non (L)GPL licences, but until this is tested in court so that there is case law no-one, not even lawyers, actually know what the licences mean or entail.Now yes, it's entirely an honor system, and there's certainly a risk involved, but in general, the ASL has made Java's open source community grow quite a bit.This is an empty assertion. Can you point to any study logically demonstrating any relation between Java's preferred license and "Java's open source community grow[ing] quite a bit"? Or even to a theoretical reason for this? Denis
Apr 12 2011
Am 12.04.2011 10:41, schrieb Daniel Gibson:Am 12.04.2011 10:29, schrieb spir:What I'd like to add: The GPL is an ideological license. Most companies aren't ideological, at least not when it comes to software licenses. They don't use and develop FOSS because they think that the idea of free software is great and all software should be free (because the products they sell aren't). Companies support Open Source for practical reasons (i.e. to save money and effort): Some components of their software is pretty generic and a lot of other companies need the same components, so they collaborate and everybody saves money. But other components of software is pretty specific and they make money of it so they don't want to release it as Open Source. So they can't use the GPL for this kind of stuff and even the LGPL isn't too useful if you want to integrate the source directly and not put it in a DLL. Of course they could do that without Open Source, but I guess it's a huge pain in the ass because of all the legal mumbo jumbo involved when collaborating with a competitor on closed source software. They need NDAs, they have to specify who may do what with the software and the source (maybe sell the source to a 3rd party etc), what happens if both companies suddenly start suing each other because of some reason, what happens if one of the companies is bought (possibly by the other companies arch enemy), .... With Open Source there's just the project, possibly organized in a democratic way, and everybody can use it and can contribute - even if they're competitors that would *never* work together otherwise. Cheers, - DanielOn 04/12/2011 09:05 AM, Andrew Wiley wrote:I don't have a study at hand, but companies often prefer BSD-style licenses to the GPL because they want to be able to reuse the code in their proprietary without open-sourcing them as well. Example: Apple reimplements the samba-service (SMB - Windows file sharing) because they don't like the GPLv3. And they push LLVM because they don't want to use GCC anymore. (But maybe this is because of the GPLv3 and not the GPL in general.) Furthermore many (most?) Open Source Java projects are mainly developed by companies and they chose this kind of license, so I think it's reasonable to assume that they prefer this kind of license to the GPL and wouldn't invest so much into these projects if they had a license they disliked. Cheers, - DanielThe Java world likes ASL precisely because software licensed under it can be sold. Take a look at the signature lines of the main contributors to large open source Java projects. It's common for large companies to pay programmers to develop open source software that's eventually shipped in products, and at the end of the day, the community benefits.This is complete misinterpretation. *All* free software can be sold.Now yes, it's entirely an honor system, and there's certainly a risk involved, but in general, the ASL has made Java's open source community grow quite a bit.This is an empty assertion. Can you point to any study logically demonstrating any relation between Java's preferred license and "Java's open source community grow[ing] quite a bit"? Or even to a theoretical reason for this? Denis
Apr 12 2011
"spir" <denis.spir gmail.com> wrote in message news:mailman.3421.1302596976.4748.digitalmars-d puremagic.com...This is complete misinterpretation. *All* free software can be sold.Technically, yes. Realistically, no. If there's software that's free-as-in-freedom, then it's inevitably free-as-in-beer as well. If it's free-as-in-beer, then who the hell is going to buy it, and what the heck for? That said, there is at least *one* thing I like about GPL: From what (incredibly little) I understand of it, it seems that it's actually realistic to have a dual-license between GPL and commercial/proprietary. I've seen software out there that allows the user to choose between getting it under GPL for free, or getting it non-GPL for a fee. I can see how that can work out (depending, of course, on the incomprehensible details of the GPL). But if you changed it from "GPL or commercial" to, say, "BSD or commercial", then the "commercial" choice would seem to loose all its value. You'd have to charge for something else, like support or merchandice or something. Actually, because of that, I could likely be enticed by an (L)GPL-like license if it was actually readable like zlib, BSD, or MIT, and easier for users/developers to comply with.
Apr 12 2011
Am 12.04.2011 12:45, schrieb Nick Sabalausky:"spir" <denis.spir gmail.com> wrote in message news:mailman.3421.1302596976.4748.digitalmars-d puremagic.com...You can also sell support for/with GPL software.This is complete misinterpretation. *All* free software can be sold.Technically, yes. Realistically, no. If there's software that's free-as-in-freedom, then it's inevitably free-as-in-beer as well. If it's free-as-in-beer, then who the hell is going to buy it, and what the heck for? That said, there is at least *one* thing I like about GPL: From what (incredibly little) I understand of it, it seems that it's actually realistic to have a dual-license between GPL and commercial/proprietary. I've seen software out there that allows the user to choose between getting it under GPL for free, or getting it non-GPL for a fee. I can see how that can work out (depending, of course, on the incomprehensible details of the GPL). But if you changed it from "GPL or commercial" to, say, "BSD or commercial", then the "commercial" choice would seem to loose all its value. You'd have to charge for something else, like support or merchandice or something.Actually, because of that, I could likely be enticed by an (L)GPL-like license if it was actually readable like zlib, BSD, or MIT, and easier for users/developers to comply with.Even though the GPL isn't easy to read I think it's not too hard to comply with (at least v2). Basically it's "release the source of your changes, don't mix in source from incompatible licenses and don't delete the original authors from the GPL headers" - the second part may not be so easy but you also have to comply with it when using any other license (e.g. don't paste BSD licensed code into boost licensed code) and the third part is also the same with most licenses: the original author/copyright holder is mentioned somewhere (mostly in a comment at the top of source files) and you may not delete that and claim you wrote everything yourself. The GPLv3 has some additional restrictions, e.g. * "TiVo clause": It isn't sufficient to release the source, the user has to be able to actually use self compiled versions of that source on the device you shipped the code with. Named after TiVo devices that ship with Linux and standard Linux tools but doesn't allow the user to flash his own system (or modified tools etc) onto the device. * Something with patents, I think it was something like "if you hold a patent that applies to this software and contribute to it you may not sue people who use this software for violating your patent". Corporations seem to be unhappy with that but I think it's a legit demand. Cheers, - Daniel
Apr 12 2011
Daniel Gibson wrote:Am 12.04.2011 12:45, schrieb Nick Sabalausky:=20Actually, because of that, I could likely be enticed by an (L)GPL-like=for=20license if it was actually readable like zlib, BSD, or MIT, and easier=e the original authors from the GPL headers" Not quite: you not only have to release the source of *your* changes, but you also have to distribute the *whole* source (whether you made any changes or not). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.frusers/developers to comply with.=20 Even though the GPL isn't easy to read I think it's not too hard to comply with (at least v2). Basically it's "release the source of your changes, don't mix in source from incompatible licenses and don't delet=
Apr 12 2011
Am 12.04.2011 20:11, schrieb "Jérôme M. Berger":Daniel Gibson wrote:If you don't change the source a link to the project homepage should suffice. And a link to the original source + your patch should be ok as well.Am 12.04.2011 12:45, schrieb Nick Sabalausky:the original authors from the GPL headers" Not quite: you not only have to release the source of *your* changes, but you also have to distribute the *whole* source (whether you made any changes or not). JeromeActually, because of that, I could likely be enticed by an (L)GPL-like license if it was actually readable like zlib, BSD, or MIT, and easier for users/developers to comply with.Even though the GPL isn't easy to read I think it's not too hard to comply with (at least v2). Basically it's "release the source of your changes, don't mix in source from incompatible licenses and don't delete
Apr 12 2011
Daniel Gibson wrote:Am 12.04.2011 20:11, schrieb "J=C3=A9r=C3=B4me M. Berger":ke=20Daniel Gibson wrote:Am 12.04.2011 12:45, schrieb Nick Sabalausky:Actually, because of that, I could likely be enticed by an (L)GPL-li=er for=20license if it was actually readable like zlib, BSD, or MIT, and easi=users/developers to comply with.Even though the GPL isn't easy to read I think it's not too hard to comply with (at least v2). Basically it's "release the source of your=etechanges, don't mix in source from incompatible licenses and don't del=Only as a tolerance for free projects, commercial projects must redistribute the whole source. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.frthe original authors from the GPL headers" Not quite: you not only have to release the source of *your* changes, but you also have to distribute the *whole* source (whether you made any changes or not). Jerome=20 If you don't change the source a link to the project homepage should suffice. And a link to the original source + your patch should be ok as well.
Apr 13 2011
On 04/12/2011 12:45 PM, Nick Sabalausky wrote:(depending, of course, on the incomprehensible details of the GPL)GPL is just one sample. And I don't get your insistance on "incomprehensible details": as if you did not know *all* devices and all commercial software you have ever bought come with a contract and/or license full of incomprehensible details; not only that, but they are designed by professionnal legists to deceive you. Free software license hairy legalist details are instead made, precisely, to avoid such deceiptions (by first users of the software, against end users). Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
"spir" <denis.spir gmail.com> wrote in message news:mailman.3438.1302612984.4748.digitalmars-d puremagic.com...On 04/12/2011 12:45 PM, Nick Sabalausky wrote:Clickwrap agreements are known to difficult to enforce even when the company tries to enforce it. Plus it's pretty easy to just violate those licenses without anyone ever even knowing. And as far as putting out derivative works, the need to reverse-engineer (since they don't come with source) makes the whole idea of doing a derivative work fairly unrealistic anyway, so it doesn't really even enter into the picture. Of course, if I'm merely going to *use* some program as an end-user, then I have no problem with GPL. And overall, yes, I do prefer GPL to closed-source proprietary. But if I'm interested in creating a derivative work, or using some library in software I plan to release, or just simply choosing a license for my own software, then I'm not happy with GPL *or* typical clickwrap licenses.(depending, of course, on the incomprehensible details of the GPL)GPL is just one sample. And I don't get your insistance on "incomprehensible details": as if you did not know *all* devices and all commercial software you have ever bought come with a contract and/or license full of incomprehensible details; not only that, but they are designed by professionnal legists to deceive you. Free software license hairy legalist details are instead made, precisely, to avoid such deceiptions (by first users of the software, against end users).
Apr 12 2011
On Mon, 11 Apr 2011 16:17:29 -0400, Jonas Drewsen <jdrewsen nospam.com> wrote:On 11/04/11 22.01, Steven Schveighoffer wrote:But why require it just for using the language? If I use a language, I want complete control over my license. I do not want to be forced into printing/including anything. If I want to use a LGPL'd library, then that should be my choice. Putting it in Phobos takes away the choice. -SteveOn Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk> wrote:Actually, if you haven't made any changes to the LGPL library that you are distribution then you can just refer to the projects homepage for the source code. This also means that putting the list of URLs for the used LGPL libraries in the Phobos packages would suffice. Can't get much easier than that.On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]IIUC, the LGPL is like applying the GPL to the library, but does not restrict proprietary software from linking to it. I think this means you can distribute your proprietary software without providing source code. However, if you supply the library (which is covered under the same rules as the GPL), then you must provide or provide upon request the source code to the LGPL-covered library. If you don't ship the library, then you don't have to supply the source code, but then you are shipping a binary that doesn't work unless they also download the LGPL library separately. It all adds up to "not going to be in druntime/Phobos" :) -Stevefine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight.
Apr 12 2011
Am 11.04.2011 19:05, schrieb Russel Winder:On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]The thing is: when someone develops a D application he would have to ship a README with it that states "contains a LGPLed library, you can get its source at blah.org". For more or less the same reason BSD-licensed code (like from Tango) isn't allowed in Phobos: Everybody shipping a D application would have to write "Contains BSD licensed Code from the Blah project" in a README that is distributed with the application (or into some Help->about box or whatever). Walter thinks (and I agree) that programs using the standard library of a programming language shouldn't need to contain any copyright-notes or similar because of license restrictions in the language or its standard library. Cheers, - Danielfine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight. [ . . . ]
Apr 11 2011
On 12/04/11 03.45, Daniel Gibson wrote:Am 11.04.2011 19:05, schrieb Russel Winder:OK. So it is an executive decision. Very nice to know and fine with me. /JonasOn Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]The thing is: when someone develops a D application he would have to ship a README with it that states "contains a LGPLed library, you can get its source at blah.org". For more or less the same reason BSD-licensed code (like from Tango) isn't allowed in Phobos: Everybody shipping a D application would have to write "Contains BSD licensed Code from the Blah project" in a README that is distributed with the application (or into some Help->about box or whatever). Walter thinks (and I agree) that programs using the standard library of a programming language shouldn't need to contain any copyright-notes or similar because of license restrictions in the language or its standard library. Cheers, - Danielfine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight. [ . . . ]
Apr 12 2011
On 2011-04-12 03:45, Daniel Gibson wrote:Am 11.04.2011 19:05, schrieb Russel Winder:If Phobos dynamically link to a LGPL licensed library and doesn't distrbute it, Phobos doesn't have to include a README file like that. -- /Jacob CarlborgOn Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]The thing is: when someone develops a D application he would have to ship a README with it that states "contains a LGPLed library, you can get its source at blah.org". For more or less the same reason BSD-licensed code (like from Tango) isn't allowed in Phobos: Everybody shipping a D application would have to write "Contains BSD licensed Code from the Blah project" in a README that is distributed with the application (or into some Help->about box or whatever). Walter thinks (and I agree) that programs using the standard library of a programming language shouldn't need to contain any copyright-notes or similar because of license restrictions in the language or its standard library. Cheers, - Danielfine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight. [ . . . ]
Apr 12 2011
Am 12.04.2011 10:43, schrieb Jacob Carlborg:On 2011-04-12 03:45, Daniel Gibson wrote:Yeah but that's against the idea of Phobos being self-contained.Am 11.04.2011 19:05, schrieb Russel Winder:If Phobos dynamically link to a LGPL licensed library and doesn't distrbute it, Phobos doesn't have to include a README file like that.On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]The thing is: when someone develops a D application he would have to ship a README with it that states "contains a LGPLed library, you can get its source at blah.org". For more or less the same reason BSD-licensed code (like from Tango) isn't allowed in Phobos: Everybody shipping a D application would have to write "Contains BSD licensed Code from the Blah project" in a README that is distributed with the application (or into some Help->about box or whatever). Walter thinks (and I agree) that programs using the standard library of a programming language shouldn't need to contain any copyright-notes or similar because of license restrictions in the language or its standard library. Cheers, - Danielfine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight. [ . . . ]
Apr 12 2011
On 04/12/2011 10:43 AM, Jacob Carlborg wrote:On 2011-04-12 03:45, Daniel Gibson wrote:Why care about the that readme file? Guess all software I have ever used under linux have such readmes. Who cares? Denis -- _________________ vita es estrany spir.wikidot.comAm 11.04.2011 19:05, schrieb Russel Winder:If Phobos dynamically link to a LGPL licensed library and doesn't distrbute it, Phobos doesn't have to include a README file like that.On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]The thing is: when someone develops a D application he would have to ship a README with it that states "contains a LGPLed library, you can get its source at blah.org". For more or less the same reason BSD-licensed code (like from Tango) isn't allowed in Phobos: Everybody shipping a D application would have to write "Contains BSD licensed Code from the Blah project" in a README that is distributed with the application (or into some Help->about box or whatever). Walter thinks (and I agree) that programs using the standard library of a programming language shouldn't need to contain any copyright-notes or similar because of license restrictions in the language or its standard library. Cheers, - Danielfine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight. [ . . . ]
Apr 12 2011
Am 12.04.2011 14:49, schrieb spir:On 04/12/2011 10:43 AM, Jacob Carlborg wrote:D is not a Linux/FOSS-only language, but also to be used on Windows and for proprietary software. And especially for Windows it's common to distribute software (especially freeware and shareware ) just as the self-contained binary. Also people using D have to know that they'll have to include this readme - and this alone is deterrent. "What, I can't distribute my D programs how I want but have to ship this license stuff with it? This Cheers, - DanielOn 2011-04-12 03:45, Daniel Gibson wrote:Why care about the that readme file? Guess all software I have ever used under linux have such readmes. Who cares? DenisAm 11.04.2011 19:05, schrieb Russel Winder:If Phobos dynamically link to a LGPL licensed library and doesn't distrbute it, Phobos doesn't have to include a README file like that.On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote: [ . . . ]The thing is: when someone develops a D application he would have to ship a README with it that states "contains a LGPLed library, you can get its source at blah.org". For more or less the same reason BSD-licensed code (like from Tango) isn't allowed in Phobos: Everybody shipping a D application would have to write "Contains BSD licensed Code from the Blah project" in a README that is distributed with the application (or into some Help->about box or whatever). Walter thinks (and I agree) that programs using the standard library of a programming language shouldn't need to contain any copyright-notes or similar because of license restrictions in the language or its standard library. Cheers, - Danielfine, but a standard library is distributed with D programs. LGPL requires you to send source when distributing the library.I would have to check but as far as I remember the (L)GPL does not require you to distribute the source with the compiled form if that is what is distributed, it requires that the end user can get the source for the compiled form. From a distribution perspective these are very different things. cf. The Maven Repository, which distributes masses of compiled jar files and no source in sight. [ . . . ]
Apr 12 2011
On 04/12/2011 03:02 PM, Daniel Gibson wrote:D is not a Linux/FOSS-only language, but also to be used on Windows and for proprietary software. And especially for Windows it's common to distribute software (especially freeware and shareware ) just as the self-contained binary.Windows apps have a menu entry just perfect for that kind of attribution stuff; used to be called "about". Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
On Tue, 12 Apr 2011 09:46:24 -0400, spir <denis.spir gmail.com> wrote:On 04/12/2011 03:02 PM, Daniel Gibson wrote:Any requirements placed on the end user are unacceptable. D is not meant to be egotistical. It does not need attribution. The less restrictions we enforce on the users of D, the more people will be willing to use it. I personally think the Boost license is perfect for D -- gives rights to the authors when the source is distributed so we don't have any question as to who wrote things, and gives full control to the end user when he just wants to build a product. -SteveD is not a Linux/FOSS-only language, but also to be used on Windows and for proprietary software. And especially for Windows it's common to distribute software (especially freeware and shareware ) just as the self-contained binary.Windows apps have a menu entry just perfect for that kind of attribution stuff; used to be called "about".
Apr 12 2011
Kagamin Wrote:spir Wrote:I also wander, what people plan to do with libmysql? It's GPL.There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the Boost license? Where's the bug?They can be used, but they can't become proprietary or Boost licensed.
Apr 11 2011
Am 11.04.2011 17:40, schrieb Kagamin:Kagamin Wrote:Doesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"? Maybe someone has already reimplemented a mysql-client under a more free license? Also: I think most databases (and their libs) are under a license that is not free enough for Phobos (SQLite is an exception - it's Public domain - and thus can and should be shipped with Phobos). So I guess Phobos' DB support should be written in a way that allows plugging in a DB driver that is distributed independently and under a different license (this makes sense anyway, because maintaining drivers for dozens of databases in Phobos is too much work). Maybe we'd need proper DLL support for that? This model is used by ODBC and JDBC as well. Cheers, - Danielspir Wrote:I also wander, what people plan to do with libmysql? It's GPL.There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the Boost license? Where's the bug?They can be used, but they can't become proprietary or Boost licensed.
Apr 11 2011
"Daniel Gibson" <metalcaedes gmail.com> wrote in message news:io0blg$jsc$5 digitalmars.com...Am 11.04.2011 17:40, schrieb Kagamin:PostgreSQL? ;)Kagamin Wrote:Doesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"? Maybe someone has already reimplemented a mysql-client under a more free license?spir Wrote:I also wander, what people plan to do with libmysql? It's GPL.There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the Boost license? Where's the bug?They can be used, but they can't become proprietary or Boost licensed.
Apr 11 2011
Am 12.04.2011 04:00, schrieb Nick Sabalausky:"Daniel Gibson" <metalcaedes gmail.com> wrote in message news:io0blg$jsc$5 digitalmars.com...Well I'd always use PostgreSQL instead of MySQL when having the choice, but 1. often MySQL needs to be used because it's already there 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos. BTW: I think PHP has a native SQL driver (under their BSD-style PHP license) - maybe that could be adapted to be used with D, if it's written in C. This still couldn't be shipped with Phobos, but at least there are no stupid restrictions on using it for commercial software.Am 11.04.2011 17:40, schrieb Kagamin:PostgreSQL? ;)Kagamin Wrote:Doesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"? Maybe someone has already reimplemented a mysql-client under a more free license?spir Wrote:I also wander, what people plan to do with libmysql? It's GPL.There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the Boost license? Where's the bug?They can be used, but they can't become proprietary or Boost licensed.
Apr 11 2011
On 04/12/2011 04:06 AM, Daniel Gibson wrote:Well I'd always use PostgreSQL instead of MySQL when having the choice, but 1. often MySQL needs to be used because it's already there 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos. BTW: I think PHP has a native SQL driver (under their BSD-style PHP license) - maybe that could be adapted to be used with D, if it's written in C. This still couldn't be shipped with Phobos, but at least there are no stupid restrictions on using it for commercial software.I don't understand this story of shipping, neither. It seems to me D's style rather pushes to reuse libs (esp written in C), that users (both programmer & end-user) are forced to install anyway. Licenses that allow reuse (and shipping) provided a copyright note is properly inserted do not change anything for me. Instead, I find this copyright note, not only *extremely* light, but also fair, and even nice. In my views, people who do not agree with that are the kinds who want to freely take from a community and give nothing back in exchange (rather corporations in fact); not even attribute their work to authors. Bad and sad :-( Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
Am 12.04.2011 11:34, schrieb spir:On 04/12/2011 04:06 AM, Daniel Gibson wrote:Yeah this is all fine when you use a third-party lib, but IMHO for a standard-lib of a language such a copyright-note shouldn't be necessary. It's not like you have to know that phobos uses zlib, for example. Sure it's nice if you add to your README "I used the D programming language and it's standardlib Phobos, which includes the zlib I used for compression and SQLite for simple database stuff to create this", but it shouldn't be necessary.Well I'd always use PostgreSQL instead of MySQL when having the choice, but 1. often MySQL needs to be used because it's already there 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos. BTW: I think PHP has a native SQL driver (under their BSD-style PHP license) - maybe that could be adapted to be used with D, if it's written in C. This still couldn't be shipped with Phobos, but at least there are no stupid restrictions on using it for commercial software.I don't understand this story of shipping, neither. It seems to me D's style rather pushes to reuse libs (esp written in C), that users (both programmer & end-user) are forced to install anyway. Licenses that allow reuse (and shipping) provided a copyright note is properly inserted do not change anything for me. Instead, I find this copyright note, not only *extremely* light, but also fair, and even nice. In my views, people who do not agree with that are the kinds who want to freely take from a community and give nothing back in exchange (rather corporations in fact); not even attribute their work to authors. Bad and sad :-( Denis
Apr 12 2011
On 04/12/2011 11:55 AM, Daniel Gibson wrote:Am 12.04.2011 11:34, schrieb spir:Right, I now understand the point. But still find it an extremely light constraint: just put an "attributions.txt" into your package. Compare this constraint eg with makefile issues ;-) Denis -- _________________ vita es estrany spir.wikidot.comOn 04/12/2011 04:06 AM, Daniel Gibson wrote:Yeah this is all fine when you use a third-party lib, but IMHO for a standard-lib of a language such a copyright-note shouldn't be necessary. It's not like you have to know that phobos uses zlib, for example. Sure it's nice if you add to your README "I used the D programming language and it's standardlib Phobos, which includes the zlib I used for compression and SQLite for simple database stuff to create this", but it shouldn't be necessary.Well I'd always use PostgreSQL instead of MySQL when having the choice, but 1. often MySQL needs to be used because it's already there 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos. BTW: I think PHP has a native SQL driver (under their BSD-style PHP license) - maybe that could be adapted to be used with D, if it's written in C. This still couldn't be shipped with Phobos, but at least there are no stupid restrictions on using it for commercial software.I don't understand this story of shipping, neither. It seems to me D's style rather pushes to reuse libs (esp written in C), that users (both programmer& end-user) are forced to install anyway. Licenses that allow reuse (and shipping) provided a copyright note is properly inserted do not change anything for me. Instead, I find this copyright note, not only *extremely* light, but also fair, and even nice. In my views, people who do not agree with that are the kinds who want to freely take from a community and give nothing back in exchange (rather corporations in fact); not even attribute their work to authors. Bad and sad :-( Denis
Apr 12 2011
For my personal libs/programs I fully agree with spir: 1) attribution is a very light burden 2) it is nice, and somehow the right thing to do 3) it gives back at least a bit of advertisement to the stuff *you can use freely* For those reasons I did release blip with an apache 2.0 license, by using it I can also easily integrate/use all kinds of free libraries, but it stays free, and usable also in commercial contexts. That said I think that having phobos using the Boost license, aside form "being nice for the user" it other subtle effects: yes it makes "standing on the shoulders of giants" more difficult, because you cannot as easily use other libraries, but exactly for that reason it forces one to rebuild things from scratch (or almost). For a *base* library, this is not necessarily a bad thing, it reduces dependencies, and might even give code that is more optimized. I think that there is space in D for other libraries, libraries that use licenses like apache 2.0 or BSD. Still I understand that the base library is boost licensed, it might not be my first choice for my own projects (I don't want to always develop everything from scratch), but it is a clear choice, and a choice that has its own merits. Fawzi On 12-apr-11, at 15:34, spir wrote:On 04/12/2011 11:55 AM, Daniel Gibson wrote:Am 12.04.2011 11:34, schrieb spir:Right, I now understand the point. But still find it an extremely light constraint: just put an "attributions.txt" into your package. Compare this constraint eg with makefile issues ;-) Denis -- _________________ vita es estrany spir.wikidot.comOn 04/12/2011 04:06 AM, Daniel Gibson wrote:Yeah this is all fine when you use a third-party lib, but IMHO for a standard-lib of a language such a copyright-note shouldn't be necessary. It's not like you have to know that phobos uses zlib, for example. Sure it's nice if you add to your README "I used the D programming language and it's standardlib Phobos, which includes the zlib I used for compression and SQLite for simple database stuff to create this", but it shouldn't be necessary.Well I'd always use PostgreSQL instead of MySQL when having the choice, but 1. often MySQL needs to be used because it's already there 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos. BTW: I think PHP has a native SQL driver (under their BSD-style PHP license) - maybe that could be adapted to be used with D, if it's written in C. This still couldn't be shipped with Phobos, but at least there are no stupid restrictions on using it for commercial software.I don't understand this story of shipping, neither. It seems to me D's style rather pushes to reuse libs (esp written in C), that users (both programmer& end-user) are forced to install anyway. Licenses that allow reuse (and shipping) provided a copyright note is properly inserted do not change anything for me. Instead, I find this copyright note, not only *extremely* light, but also fair, and even nice. In my views, people who do not agree with that are the kinds who want to freely take from a community and give nothing back in exchange (rather corporations in fact); not even attribute their work to authors. Bad and sad :-( Denis
Apr 12 2011
On 04/12/2011 04:01 PM, Fawzi Mohamed wrote:For my personal libs/programs I fully agree with spir: 1) attribution is a very light burden 2) it is nice, and somehow the right thing to do 3) it gives back at least a bit of advertisement to the stuff *you can use freely* For those reasons I did release blip with an apache 2.0 license, by using it I can also easily integrate/use all kinds of free libraries, but it stays free, and usable also in commercial contexts. That said I think that having phobos using the Boost license, aside form "being nice for the user" it other subtle effects: yes it makes "standing on the shoulders of giants" more difficult, because you cannot as easily use other libraries, but exactly for that reason it forces one to rebuild things from scratch (or almost). For a *base* library, this is not necessarily a bad thing, it reduces dependencies, and might even give code that is more optimized. I think that there is space in D for other libraries, libraries that use licenses like apache 2.0 or BSD. Still I understand that the base library is boost licensed, it might not be my first choice for my own projects (I don't want to always develop everything from scratch), but it is a clear choice, and a choice that has its own merits.Thanks to everyone, I know understand the point and the choice made for D, or rather Phobos. I still do not share the underlying opinion and would not do do that choice myself (find properly crediting someone for their work just a Good Thing, and no burden at all). But at least, as Fawzi says, it's a clear choice; and I would not mind licensing under Boost potential contributions to Phobos. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
On 4/11/2011 9:55 PM, Daniel Gibson wrote:Doesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"?According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual licensed GPL or proprietary. (Actually it's a slightly modified GPL that's **less** restrictive than the vanilla one.)
Apr 11 2011
Am 12.04.2011 04:18, schrieb dsimcha:On 4/11/2011 9:55 PM, Daniel Gibson wrote:Hmm.. seems like I've mixed up stuff, I only got my information via hearsay. However I've looked it up: You can only use MySQL with closed source software, when you buy a license. Even if you don't touch MySQL's code itself, because the client library is also under GPL. I *think* this could be fixed by a custom client library under another license because then you wouldn't use or link any of MySQLs source but just communicate with it via TCP or something. MySQL's license is a bit less restrictive than the GPL, because you may link it with *any* source using an OSI-Approved (Open Source) license and not just GPL. That doesn't help with proprietary software, though. See also: http://www.mysql.com/about/legal/licensing/index.html Cheers, - DanielDoesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"?According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual licensed GPL or proprietary. (Actually it's a slightly modified GPL that's **less** restrictive than the vanilla one.)
Apr 11 2011
On 04/12/2011 04:18 AM, dsimcha wrote:On 4/11/2011 9:55 PM, Daniel Gibson wrote:There is a misconseption (or rather rethorical playing on words) in the open-source argumentation versus free software: a license like BSD is said to be less restrictive. But in fact it is more privative to (end-)users, in that it allows direct users of the software to deprive them from rights that would have been guaranted by a free software license. Denis -- _________________ vita es estrany spir.wikidot.comDoesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"?According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual licensed GPL or proprietary. (Actually it's a slightly modified GPL that's **less** restrictive than the vanilla one.)
Apr 12 2011
"spir" <denis.spir gmail.com> wrote in message news:mailman.3427.1302601308.4748.digitalmars-d puremagic.com...On 04/12/2011 04:18 AM, dsimcha wrote:Except such software is more likely to have just simply used some other library instead, something either more BSD-like or in-house proprietary. In other words, in actual practice, (L)GPL tends to discoruage people from actually making derivative works. So that still works against users gaining benefit from the software anyway.On 4/11/2011 9:55 PM, Daniel Gibson wrote:There is a misconseption (or rather rethorical playing on words) in the open-source argumentation versus free software: a license like BSD is said to be less restrictive. But in fact it is more privative to (end-)users, in that it allows direct users of the software to deprive them from rights that would have been guaranted by a free software license.Doesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"?According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual licensed GPL or proprietary. (Actually it's a slightly modified GPL that's **less** restrictive than the vanilla one.)
Apr 12 2011
spir wrote:On 04/12/2011 04:18 AM, dsimcha wrote:mayOn 4/11/2011 9:55 PM, Daniel Gibson wrote:Doesn't mysql even have some retarded restriction like "it's GPL but =tonot be used for commercial purposes so buy mysql if you wanna use it ==20 There is a misconseption (or rather rethorical playing on words) in the=make money"?According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual licensed GPL or proprietary. (Actually it's a slightly modified GPL that's **less** restrictive than the vanilla one.)open-source argumentation versus free software: a license like BSD is said to be less restrictive. But in fact it is more privative to (end-)users, in that it allows direct users of the software to deprive them from rights that would have been guaranted by a free software lice=nse.=20OTOH, the GPL is a lot more restrictive for direct users since it deprives them of the right to license *their own* code any way they want (at least, LGPL does not have that restriction). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
On 04/12/2011 08:19 PM, "Jérôme M. Berger" wrote:spir wrote:True. Denis -- _________________ vita es estrany spir.wikidot.comOn 04/12/2011 04:18 AM, dsimcha wrote:OTOH, the GPL is a lot more restrictive for direct users since it deprives them of the right to license *their own* code any way they want (at least, LGPL does not have that restriction). JeromeOn 4/11/2011 9:55 PM, Daniel Gibson wrote:There is a misconseption (or rather rethorical playing on words) in the open-source argumentation versus free software: a license like BSD is said to be less restrictive. But in fact it is more privative to (end-)users, in that it allows direct users of the software to deprive them from rights that would have been guaranted by a free software license.Doesn't mysql even have some retarded restriction like "it's GPL but may not be used for commercial purposes so buy mysql if you wanna use it to make money"?According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual licensed GPL or proprietary. (Actually it's a slightly modified GPL that's **less** restrictive than the vanilla one.)
Apr 12 2011
Kagamin wrote:Kagamin Wrote:There's a FOSS license exception for MySQL client library: http://www.mysql.com/about/legal/licensing/foss-exception/ Boost license is not on the list, but we may ask them to include it. Anyway, I'm writing my PostgreSQL client without using libpq: http://github.com/pszturmaj/ddb It's licensed under Boost 1.0 so it could be included into Phobos. I planned to write MySQL client without using client lib as well. However I'm not sure about stability of their protocol (in contrast to PostgreSQL's): http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocolspir Wrote:I also wander, what people plan to do with libmysql? It's GPL.There is a point I don't understand: if I'm right, LGPL as well as all other "open source", not strictly free-software, licenses allow using licensed software even for "privative" (proprietary) work. But they wouldn't allow using software for work licensed under other open-source licenses like the Boost license? Where's the bug?They can be used, but they can't become proprietary or Boost licensed.
Apr 12 2011
Piotr Szturmaj Wrote:I believe, phobos is boost licensed in order to be corporations-friendly, which will be impossible with inclusion of libmysql.I also wander, what people plan to do with libmysql? It's GPL.There's a FOSS license exception for MySQL client library: http://www.mysql.com/about/legal/licensing/foss-exception/ Boost license is not on the list, but we may ask them to include it.
Apr 12 2011
Piotr Szturmaj Wrote:http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_ProtocolLOL, take a look at this: http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374
Apr 12 2011
Kagamin wrote:Piotr Szturmaj Wrote:That's ridiculous. I've just googled for "The MySQL Protocol is proprietary" and I've got this: http://krow.livejournal.com/684068.html Also take a look at comments... I fully agree with this one: "MySQL's position on the protocol issue is pure, unadulterated BS. It is legal to reverse engineer protocols and file formats without the permission of the originator. See Open Office and Samba for two particularly widely known examples of this."http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_ProtocolLOL, take a look at this: http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374
Apr 12 2011
Nick Sabalausky Wrote:The whole thing's just a damn mess. I've always found it best to just avoid any (L)GPL source or library outright. Not worth the trouble.GPL is pretty simple: write GPL soft and there will be no problem.
Apr 12 2011
I spent a little more time on it and implemented simple PNG writing from the lines range and fixed a few bugs. What I really want to see with the ranges is things like using std.algorithm to make an image diff in just a few lines, and also being able to use image functions as generic algorithms; they should be fairly interchangeable. While that's still a long way off (if we'll ever get there), the range approach can do some pretty cool things. Check this out: (first get the new file: http://arsdnet.net/dcode/imagedraft.d ) === import imagedraft; import std.stdio; import std.random; // Why the hell isn't something like this in Phobos? struct BinaryFileWriter { File f; this(string filename) { f = File(filename, "wb"); } void put(in ubyte[] data) { f.rawWrite(data); } } // This is a little range to create an image on the fly struct StaticGenerator { int width; int height; int linesLeft; this(int width, int height) { this.width = width; this.height = height; linesLeft = height; assert(linesLeft); } bool empty() { return !(linesLeft > 0); } // required by writePng int length() { return height; } void popFront() { assert(linesLeft); linesLeft--; } RgbaScanline front() { assert(linesLeft); RgbaScanline line; line.pixels.length = width; foreach(ref pixel; line.pixels) { ubyte val = cast(ubyte) uniform(0, 255); pixel = Color(val, val, val, 255); } return line; } } void main(string[] args) { // writePng takes an output range and an input range. The // output range should accept the ubyte[]s it generates. // The input range needs to provide length and it's front // should be some RgbaScanlines writePng( BinaryFileWriter("static.png"), StaticGenerator(512, 512)); } === Nothing particularly great, yet, but it's slowly becoming something useful. I also improved the convertToGreyscale function so the results don't suck as much, making it a fun little function to play with too. ======== On a completely unrelated note, I've written basic .wav and fairly decent .mid file functions too. The .wav can read and write simple files to an array and add some simple sounds to it (square wave, etc. I generated my phone's ringtone with a little D program!) Wav is kinda buggy, but I'm sure if I spent a couple hours on it, it'd be whipped into shape. And the .mid functions read them into a series of events, can write back out, and can also play the files on Windows and Linux*, including injecting events as they play. * Linux midi support sucks and requires a lot of code and user setup... but if you have a working ALSA rig, the program will drive it. Just since I'm talking about file formats, if there's any interest, I can see about cleaning these up too for simple sound support in the library.
Apr 10 2011
On 4/10/2011 5:10 PM, Adam D. Ruppe wrote:But, you can see one of the big ideas: providing ranges on images of various formats that present the data to you in a requested standard format (any PNG image is lazily converted to an rgba list of lines here).I don't know much about graphics, but your approach sounds awesome.
Apr 10 2011
Walter Bright wrote:I don't know much about graphics [...]The irony is neither do I! But, an algorithm is an algorithm so I'm hoping if it can work well for the few I know, we'll have an approach that can work for others too, all written independently.
Apr 11 2011
On 04/11/2011 06:09 PM, Adam D. Ruppe wrote:Walter Bright wrote:Yes, that's definitely the great thing about generics, IMO. Denis -- _________________ vita es estrany spir.wikidot.comI don't know much about graphics [...]The irony is neither do I! But, an algorithm is an algorithm so I'm hoping if it can work well for the few I know, we'll have an approach that can work for others too, all written independently.
Apr 11 2011
On 04/11/2011 02:10 AM, Adam D. Ruppe wrote:I'm pretty happy with how simpledisplay.d is turning out, and want to spend some time thinking about the client side images now. I think a nice way to do it would be to go with ranges and templates, like std.algorithm, so things will work across many different image formats with the best efficiency and minimal coupling. But, we need to think about some specifics before going too far. Here's a first draft module to show the idea while doing some useful work. It's dependency free so you can download and play with ease. http://arsdnet.net/dcode/imagedraft.d If you also grab simpledisplay.d http://arsdnet.net/dcode/simpledisplay.d You can compile this little png display program: ======= import imagedraft; import std.stdio; import simpledisplay; void main(string[] args) { auto png = pngFromBytes(File(args[1]).byChunk(4096)); auto image = new Image(png.header.width, png.header.height); int y; foreach(line; png.byRgbaScanline) { foreach(x, color; line.pixels) image.putPixel(cast(int) x, cast(int) y, simpledisplay.Color(color.r, color.g, color.b, color.a)); y++; } displayImage(image); } ==== And use it as a base to play around and see your algorithm's results right in the window. (btw, that displayImage() function is what used to be image.display() in simpledisplay. A standalone function will let me separate dependencies better. It works the same way - just show it and wait for the user to hit any key to continue.)Works fine by me :-) Thank you very much again for this nice job. I intend to do some trials with simpledisplay. This could also provide for a few unittests. Are you interested in that?The foreach there is ugly. I was going to write up a demo of some actual algorithms for images, but I ended up spending most the day getting my BufferedInputRange and LazyPngFile to work correctly... But, you can see one of the big ideas: providing ranges on images of various formats that present the data to you in a requested standard format (any PNG image is lazily converted to an rgba list of lines here). It also shows how I plan to write other image format loaders - they take arbitrary input ranges, and lazily load and decode the file. (While I had a png loader before, it was in C style.... I'm hoping that it will be easier to port my bmp code now that I have a working foundation...) I'll write an image saver too. It will take an rgbaScanLine range and save it to the correct format - png, bmp, whatever.What is the advantage of laziness here (both for input and output)? One needs to compute the while pic anyway... Actually simple ranges (aven simple arrays?) would do the job as well, wouldn't they?Now, back to the main idea here. I wish I had more time. If I fleshed out this existing range a little more, we could do fun things like call std.algorithm.levenshteinDistance on it.. but right now, it's just an input range, which is fairly limited. I figure the best thing to do is offer whatever facilities the source range offers, so if you give it an array, you can save(), back(), etc. too. Still, we can run a few functions on it. foreach(line; filter!"a.pixels[0].r> 200"(png.byRgbaScanline)) { } Only keeps lines with a lot of red in the first pixel. So that's pretty cool. Aaaanyway, I want to have a bunch of algorithms written in here that can work on these ranges, capable of doing both in-place and lazy changes to your image. Since I messed up the time, I only wrote one (and it sucks, hard), but it's the idea I have in mind: the convertToGreyscale function. Any image that provides a range it can use will work for it. What kind of ranges would be useful? A by line surely is, which is why I started with it. A byPixel perhaps?Surely: this allows running complicated algorithm on the proper level of abstraction (the pixel=point). For instance, I'd like a fill(shape,fillColor) function working for any (closed) shape defined as a set of pixels of a given color. (Not trivial, by the way, for arbitrary convex shapes, as you probably know.)Maybe a byBlock? Though, it for byPixel, it seems like opApply is the way to do it. Maybe it can even shove it off to the GPU to do the work. That's beyond my knowledge, but David Simcha has done some cool stuff with foreach and parallelism, and this is basically the same concept, so I'm sure it can be done. Then, of course, you'll surely still want opIndex into the pixels too.Yop, i think it's the right level. "Total slice" [] could return, as default range, a range of pixels.I was hoping to have time to write a gaussian blur function to put the idea to the test... The other thing is drawing. I don't think ranges will help much there. Drawing algorithms will probably be ok with opIndexAssign into the pixels.Yop as well.But, it's time for me to get to the work I was supposed to do today. If nothing else, hopefully that PNG loader in there will be useful, but I really do think there's a lot of potential in the idea of a std.algorithm for images and would like any input you have. Thanks for all the feedback this weekend, everyone!Thanks to you! Denis -- _________________ vita es estrany spir.wikidot.com
Apr 11 2011
spir wrote:I intend to do some trials with simpledisplay. This could also provide for a few unittests. Are you interested in that?Yeah, sounds good.What is the advantage of laziness here (both for input and output)? One needs to compute the while pic anyway... Actually simple ranges (aven simple arrays?) would do the job as well, wouldn't they?The main reason I went this way was to be like the rest of Phobos. Why does Phobos use laziness so much? One big reason is you can always go from lazy to eager, but not the other way around. Just call array() on it. Lazy computations can also save on a lot of memory if you don't need the whole thing at once, especially if it's very large. One situation this might be useful is working with video. Hopefully, the lazy algorithms for images will be reusable for a streaming video too. My StaticGenerator there could do any size without taking more than the memory needed for a single line. Finally, there might be a small speed boost, since it lets you mix CPU and disk operations together - load part of the file, then process it while the next part is still coming off the disk, instead of having the processor sit idle while waiting for it to load. It could also cut down on memory allocations by reusing buffers too. (My implementation doesn't realize this very well, but it could be done in theory. However, a part of me isn't sure it's a great idea... mutable buffers in std.stdio.File wasted some time yesterday because I forgot to copy them... but still, it's possible to do more this way.)For instance, I'd like a fill(shape,fillColor) function working for any (closed) shapeYes, indeed.
Apr 11 2011
"Adam D. Ruppe" <destructionator gmail.com> wrote in message news:intgu2$1bhj$1 digitalmars.com...I'm pretty happy with how simpledisplay.d is turning out, and want to spend some time thinking about the client side images now. I think a nice way to do it would be to go with ranges and templates, like std.algorithm, so things will work across many different image formats with the best efficiency and minimal coupling. But, we need to think about some specifics before going too far. Here's a first draft module to show the idea while doing some useful work. It's dependency free so you can download and play with ease. http://arsdnet.net/dcode/imagedraft.dBoy, I just can't keep up with you! I'm still in the process tinkering with my version of Color and Image, benchmarking it, and article-writing (This turned out to be the perfect second example for the contest article I had already been planning to write. I'm not actually presenting any of your orignal code though, I didn't think that would be appropriate anyway, just using some of my versions of Color and Image.) I'll definitely get around to looking at this new version at some point, though! :)
Apr 11 2011