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:
--0016e6d9765168f23a04a099bbf3
Content-Type: text/plain; charset=ISO-8859-1

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!

--0016e6d9765168f23a04a099bbf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You are on a tear with this image stuff :)<div><br></div><div>Have you cons= idered wrapping something like DevIL?=A0<a href=3D"http://openil.sourceforg= e.net/features.php">http://openil.sourceforge.net/features.php</a>=A0=A0Pro= bably has all the features you could ever want and is cross-platform.</div> <div><a href=3D"http://openil.sourceforge.net/features.php"></a><br>- Cliff= </div><div><br><div class=3D"gmail_quote">On Sun, Apr 10, 2011 at 5:10 PM, = Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail= .com">destructionator gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">I&#39;m pretty happy with how simpledisplay= .d is turning out, and want to<br> spend some time thinking about the client side images now.<br> <br> I think a nice way to do it would be to go with ranges and templates,<br> like std.algorithm, so things will work across many different image<br> formats with the best efficiency and minimal coupling. But, we need to<br> think about some specifics before going too far.<br> <br> Here&#39;s a first draft module to show the idea while doing some useful<br=

<br> <a href=3D"http://arsdnet.net/dcode/imagedraft.d" target=3D"_blank">http://= arsdnet.net/dcode/imagedraft.d</a><br> <br> <br> If you also grab simpledisplay.d<br> <a href=3D"http://arsdnet.net/dcode/simpledisplay.d" target=3D"_blank">http= ://arsdnet.net/dcode/simpledisplay.d</a><br> <br> You can compile this little png display program:<br> <br> =3D=3D=3D=3D=3D=3D=3D<br> import imagedraft;<br> import std.stdio;<br> <br> import simpledisplay;<br> <br> void main(string[] args) {<br> =A0 =A0 =A0 =A0auto png =3D pngFromBytes(File(args[1]).byChunk(4096));<br> =A0 =A0 =A0 =A0auto image =3D new Image(png.header.width, png.header.heigh= t);<br> <br> =A0 =A0 =A0 =A0int y;<br> =A0 =A0 =A0 =A0foreach(line; png.byRgbaScanline) {<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0foreach(x, color; line.pixels)<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0image.putPixel(cast(int) x,= cast(int) y,<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0simpledispl= ay.Color(color.r, color.g, color.b, color.a));<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0y++;<br> =A0 =A0 =A0 =A0}<br> <br> =A0 =A0 =A0 =A0displayImage(image);<br> }<br> =3D=3D=3D=3D<br> <br> And use it as a base to play around and see your algorithm&#39;s results<br=

to be image.display() in simpledisplay. A standalone function will<br> let me separate dependencies better. It works the same way - just<br> show it and wait for the user to hit any key to continue.)<br> <br> The foreach there is ugly. I was going to write up a demo<br> of some actual algorithms for images, but I ended up spending<br> most the day getting my BufferedInputRange and LazyPngFile to<br> work correctly...<br> <br> But, you can see one of the big ideas: providing ranges on images<br> of various formats that present the data to you in a requested<br> standard format (any PNG image is lazily converted to an rgba list<br> of lines here).<br> <br> It also shows how I plan to write other image format loaders - they<br> take arbitrary input ranges, and lazily load and decode the file.<br> (While I had a png loader before, it was in C style.... I&#39;m hoping<br> that it will be easier to port my bmp code now that I have a working<br> foundation...)<br> <br> I&#39;ll write an image saver too. It will take an rgbaScanLine range<br> and save it to the correct format - png, bmp, whatever.<br> <br> <br> Now, back to the main idea here. I wish I had more time. If I fleshed<br> out this existing range a little more, we could do fun things<br> like call std.algorithm.levenshteinDistance on it.. but right now,<br> it&#39;s just an input range, which is fairly limited. I figure the<br> best thing to do is offer whatever facilities the source range offers,<br> so if you give it an array, you can save(), back(), etc. too.<br> <br> Still, we can run a few functions on it.<br> <br> =A0foreach(line; filter!&quot;a.pixels[0].r &gt; 200&quot;(png.byRgbaScanli= ne)) {<br> =A0}<br> <br> Only keeps lines with a lot of red in the first pixel.<br> <br> So that&#39;s pretty cool.<br> <br> <br> <br> Aaaanyway, I want to have a bunch of algorithms written in here that<br> can work on these ranges, capable of doing both in-place and lazy<br> changes to your image.<br> <br> Since I messed up the time, I only wrote one (and it sucks, hard),<br> but it&#39;s the idea I have in mind: the convertToGreyscale function.<br> Any image that provides a range it can use will work for it.<br> <br> <br> <br> What kind of ranges would be useful? A by line surely is, which<br> is why I started with it. A byPixel perhaps? Maybe a byBlock? Though,<br> it for byPixel, it seems like opApply is the way to do it. Maybe it<br> can even shove it off to the GPU to do the work. That&#39;s beyond my<br> knowledge, but David Simcha has done some cool stuff with foreach<br> and parallelism, and this is basically the same concept, so I&#39;m<br> sure it can be done.<br> <br> Then, of course, you&#39;ll surely still want opIndex into the pixels<br> too.<br> <br> I was hoping to have time to write a gaussian blur function to put<br> the idea to the test...<br> <br> <br> The other thing is drawing. I don&#39;t think ranges will help much there.<= br> Drawing algorithms will probably be ok with opIndexAssign into the<br> pixels.<br> <br> <br> But, it&#39;s time for me to get to the work I was supposed to do today.<br=

but I really do think there&#39;s a lot of potential in the idea of<br> a std.algorithm for images and would like any input you have.<br> <br> Thanks for all the feedback this weekend, everyone!<br> </blockquote></div><br></div> --0016e6d9765168f23a04a099bbf3--
Apr 10 2011
next sibling 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 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


 Where's the bug?


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 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
next sibling 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
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 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 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 next 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
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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=


 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 delet=

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

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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=




 license if it was actually readable like zlib, BSD, or MIT, and easi=




 users/developers to comply with.

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=



 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.

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 next 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 next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
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 next 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 next 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 next sibling parent 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 isn't needed when using C++ or C#, I better stick with that" Cheers, - Daniel
Apr 12 2011
prev sibling parent 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
prev sibling parent 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
prev sibling next sibling parent 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
prev sibling parent 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
prev sibling parent 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?


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
prev sibling next sibling parent Cliff Hudson <cliff.s.hudson gmail.com> writes:
--00032555b67e2e771e04a099f072
Content-Type: text/plain; charset=ISO-8859-1

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 :-(

--00032555b67e2e771e04a099f072 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ahh, good point, I didn&#39;t look too closely at the licensing.<div><br></= div><div>- Cliff<br><br><div class=3D"gmail_quote">On Sun, Apr 10, 2011 at = 5:45 PM, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructiona= tor gmail.com">destructionator gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">Cliff Hudson wrote:<br> &gt; Have you considered wrapping something like DevIL?<br> <br> </div>I actually didn&#39;t consider it; since I already have decent homegr= own<br> loaders for a few formats I figured that&#39;d be good enough, for now<br> at least.<br> <br> But, looking now, DevIL is LGPL. As I&#39;m hoping to get into Phobos,<br> that will mean licensing problems. Phobos should Just Work for<br> endusers, meaning it ought to package everything it needs with it,<br> with the exception of operating system libraries.<br> <br> Packaging the source for a big library to satisfy the LGPL won&#39;t<br> really work there :-(<br> </blockquote></div><br></div> --00032555b67e2e771e04a099f072--
Apr 10 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
next sibling parent 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
prev sibling 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 next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
prev sibling next sibling parent "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
prev sibling next 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
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
[ . . . ]
=20
 Regardless, I think we've clearly demonstrated the complete impenetrabili=

 of (L)GPL. I've long since given up trying to understand it, and I seriou=

 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 stil=

 probably about 10 other versions and half of them are even incompatible w=

 each other (in poorly-understood ways). The whole thing's just a damn mes=

 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
next sibling 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 "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
prev sibling 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 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=


 of (L)GPL. I've long since given up trying to understand it, and I serio=


 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=


 probably about 10 other versions and half of them are even incompatible =


 each other (in poorly-understood ways). The whole thing's just a damn me=


 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=

 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
prev sibling next sibling parent "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
prev sibling next 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 next sibling 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 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 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