www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.algorithm for images

reply Adam D. Ruppe <destructionator gmail.com> writes:
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
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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.d
I 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.htm
 Thanks for all the feedback this weekend, everyone!
You are welcome :-) Bye, bearophile
Apr 10 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
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
prev sibling next sibling parent reply Cliff Hudson <cliff.s.hudson gmail.com> writes:
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
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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
next sibling parent Cliff Hudson <cliff.s.hudson gmail.com> writes:
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
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/11/2011 02:45 AM, Adam D. Ruppe 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 :-(
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.com
Apr 11 2011
next sibling parent reply Kagamin <spam here.lot> writes:
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
parent Francisco Almeida <francisco.m.almeida gmail.com> writes:
== Quote from Kagamin (spam here.lot)'s article
 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.
I'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).
Apr 11 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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
parent reply Russel Winder <russel russel.org.uk> writes:
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
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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:
 [ . . . ]
 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.
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" :) -Steve
Apr 11 2011
parent reply Jonas Drewsen <jdrewsen nospam.com> writes:
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:

 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.
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" :) -Steve
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. /Jonas
Apr 11 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonas Drewsen" <jdrewsen nospam.com> wrote in message 
news:invnrn$2pgf$1 digitalmars.com...
 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:

 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.
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" :)
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.
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.
Apr 11 2011
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
[ . . . ]
=20
 Regardless, I think we've clearly demonstrated the complete impenetrabili=
ty=20
 of (L)GPL. I've long since given up trying to understand it, and I seriou=
sly=20
 doubt that anyone really truly understands it (it's the C++ of the legal=
=20
 world). Even if you do miraculously understand one form of it, there stil=
l=20
 probably about 10 other versions and half of them are even incompatible w=
ith=20
 each other (in poorly-understood ways). The whole thing's just a damn mes=
s.=20
 I'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
parent reply "Nick Sabalausky" <a a.a> writes:
"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
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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...
 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.
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.
 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
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:io1als$jsc$15 digitalmars.com...
 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...
 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.
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.
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.
 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.
That would still be equally possible even if FooPlus were a completely open project.
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 13:02, schrieb Nick Sabalausky:
 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:io1als$jsc$15 digitalmars.com...
 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...
 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.
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.
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"
 
 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.
That would still be equally possible even if FooPlus were a completely open project.
But than you could at least integrate their changes into your version to support their file format etc
Apr 12 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:io1c0b$jsc$18 digitalmars.com...
 Am 12.04.2011 13:02, 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.
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"
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.
 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.
That would still be equally possible even if FooPlus were a completely open project.
But than you could at least integrate their changes into your version to support their file format etc
Yea, but now the whole argument has been whittled down to quite a lot of "if"s.
Apr 12 2011
parent spir <denis.spir gmail.com> writes:
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
prev sibling parent spir <denis.spir gmail.com> writes:
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...
 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).
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.com
Apr 12 2011
prev sibling next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
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:
 [ . . . ]
 Regardless, I think we've clearly demonstrated the complete impenetrabil=
ity
 of (L)GPL. I've long since given up trying to understand it, and I serio=
usly
 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 sti=
ll
 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 me=
ss.
 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. =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=
s
 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
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
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
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/12/11, "J=E9r=F4me M. Berger" <jeberger free.fr> wrote:
 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...
Practically this means you can sell services. And not everyone is in the business of services.
Apr 12 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 01:47 AM, Nick Sabalausky wrote:
 "Jonas Drewsen"<jdrewsen nospam.com>  wrote in message
 news:invnrn$2pgf$1 digitalmars.com...
 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:

 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.
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" :)
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.
Sounds like a pain for the users of Phobos (and maybe the users of Phobos-developed software?).
I don't understand where the pain lies, here.
 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
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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'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?
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.
Apr 12 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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:
 "Jonas Drewsen"<jdrewsen nospam.com>  wrote in message
 news:invnrn$2pgf$1 digitalmars.com...
 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:

 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.
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" :)
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.
Sounds like a pain for the users of Phobos (and maybe the users of Phobos-developed software?).
I don't understand where the pain lies, here.
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
Apr 12 2011
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
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
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 12 Apr 2011 13:54:19 -0400, Jérôme M. Berger <jeberger free.fr>  
wrote:

 Steven Schveighoffer wrote:
 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.
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...
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. -Steve
Apr 12 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"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
prev sibling parent reply spir <denis.spir gmail.com> writes:
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:
 On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
 [ . . . ]
 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.
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.
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 -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 10:29, schrieb spir:
 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:
 On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
 [ . . . ]
 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.
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.
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
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, - Daniel
Apr 12 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 10:41, schrieb Daniel Gibson:
 Am 12.04.2011 10:29, schrieb spir:
 On 04/12/2011 09:05 AM, Andrew Wiley 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.
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
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, - Daniel
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, - Daniel
Apr 12 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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...
 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.
You can also sell support for/with GPL software.
 
 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
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Daniel Gibson wrote:
 Am 12.04.2011 12:45, schrieb Nick Sabalausky:
 Actually, because of that, I could likely be enticed by an (L)GPL-like=
=20
 license if it was actually readable like zlib, BSD, or MIT, and easier=
for=20
 users/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=
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.fr
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 20:11, schrieb "Jérôme M. Berger":
 Daniel Gibson wrote:
 Am 12.04.2011 12:45, schrieb Nick Sabalausky:
 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" 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
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 12 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Daniel Gibson wrote:
 Am 12.04.2011 20:11, schrieb "J=C3=A9r=C3=B4me M. Berger":
 Daniel 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=
ke=20
 license if it was actually readable like zlib, BSD, or MIT, and easi=
er for=20
 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 del=
ete
 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 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.
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.fr
Apr 13 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
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
parent "Nick Sabalausky" <a a.a> writes:
"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:
 (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).
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.
Apr 12 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 11 Apr 2011 16:17:29 -0400, Jonas Drewsen <jdrewsen nospam.com>  
wrote:

 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:

 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.
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" :) -Steve
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.
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. -Steve
Apr 12 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.04.2011 19:05, schrieb Russel Winder:
 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. [ . . . ]
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, - Daniel
Apr 11 2011
next sibling parent Jonas Drewsen <jdrewsen nospam.com> writes:
On 12/04/11 03.45, Daniel Gibson wrote:
 Am 11.04.2011 19:05, schrieb Russel Winder:
 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. [ . . . ]
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, - Daniel
OK. So it is an executive decision. Very nice to know and fine with me. /Jonas
Apr 12 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-12 03:45, Daniel Gibson wrote:
 Am 11.04.2011 19:05, schrieb Russel Winder:
 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. [ . . . ]
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, - Daniel
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 Carlborg
Apr 12 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 10:43, schrieb Jacob Carlborg:
 On 2011-04-12 03:45, Daniel Gibson wrote:
 Am 11.04.2011 19:05, schrieb Russel Winder:
 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. [ . . . ]
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, - Daniel
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.
Yeah but that's against the idea of Phobos being self-contained.
Apr 12 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 10:43 AM, Jacob Carlborg wrote:
 On 2011-04-12 03:45, Daniel Gibson wrote:
 Am 11.04.2011 19:05, schrieb Russel Winder:
 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. [ . . . ]
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, - Daniel
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.
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.com
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 14:49, schrieb spir:
 On 04/12/2011 10:43 AM, Jacob Carlborg wrote:
 On 2011-04-12 03:45, Daniel Gibson wrote:
 Am 11.04.2011 19:05, schrieb Russel Winder:
 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. [ . . . ]
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, - Daniel
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.
Why care about the that readme file? Guess all software I have ever used under linux have such readmes. Who cares? Denis
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, - Daniel
Apr 12 2011
parent reply spir <denis.spir gmail.com> writes:
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
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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:
 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".
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. -Steve
Apr 12 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Kagamin Wrote:

 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.
I also wander, what people plan to do with libmysql? It's GPL.
Apr 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.04.2011 17:40, schrieb Kagamin:
 Kagamin Wrote:
 
 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.
I also wander, what people plan to do with libmysql? It's GPL.
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, - Daniel
Apr 11 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:io0blg$jsc$5 digitalmars.com...
 Am 11.04.2011 17:40, schrieb Kagamin:
 Kagamin Wrote:

 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.
I also wander, what people plan to do with libmysql? It's GPL.
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?
PostgreSQL? ;)
Apr 11 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 04:00, schrieb Nick Sabalausky:
 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:io0blg$jsc$5 digitalmars.com...
 Am 11.04.2011 17:40, schrieb Kagamin:
 Kagamin Wrote:

 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.
I also wander, what people plan to do with libmysql? It's GPL.
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?
PostgreSQL? ;)
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.
Apr 11 2011
parent reply spir <denis.spir gmail.com> writes:
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
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 11:34, schrieb spir:
 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
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.
Apr 12 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 04/12/2011 11:55 AM, Daniel Gibson wrote:
 Am 12.04.2011 11:34, schrieb spir:
 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
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.
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.com
Apr 12 2011
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
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:
 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
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.
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.com
Apr 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
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
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
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
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 04:18, schrieb dsimcha:
 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.)
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, - Daniel
Apr 11 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 04:18 AM, dsimcha wrote:
 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.)
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.com
Apr 12 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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:
 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.)
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.
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.
Apr 12 2011
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
spir wrote:
 On 04/12/2011 04:18 AM, dsimcha wrote:
 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.)
=20 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 lice=
nse.
=20
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). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Apr 12 2011
parent spir <denis.spir gmail.com> writes:
On 04/12/2011 08:19 PM, "Jérôme M. Berger" wrote:
 spir wrote:
 On 04/12/2011 04:18 AM, dsimcha wrote:
 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.)
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.
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). Jerome
True. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 12 2011
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Kagamin wrote:
 Kagamin Wrote:

 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.
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. 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_Protocol
Apr 12 2011
next sibling parent Kagamin <spam here.lot> writes:
Piotr Szturmaj Wrote:

 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.
I believe, phobos is boost licensed in order to be corporations-friendly, which will be impossible with inclusion of libmysql.
Apr 12 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Piotr Szturmaj Wrote:

 http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol
LOL, take a look at this: http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374
Apr 12 2011
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Kagamin wrote:
 Piotr Szturmaj Wrote:

 http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol
LOL, take a look at this: http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374
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."
Apr 12 2011
prev sibling parent Kagamin <spam here.lot> writes:
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
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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
parent spir <denis.spir gmail.com> writes:
On 04/11/2011 06:09 PM, Adam D. Ruppe wrote:
 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.
Yes, that's definitely the great thing about generics, IMO. Denis -- _________________ vita es estrany spir.wikidot.com
Apr 11 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
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
parent Adam D. Ruppe <destructionator gmail.com> writes:
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) shape
Yes, indeed.
Apr 11 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"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.d
Boy, 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