www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.algorithm for images

reply Adam D. Ruppe <destructionator gmail.com> writes:
I'm pretty happy with how simpledisplay.d is turning out, and want to
spend some time thinking about the client side images now.

I think a nice way to do it would be to go with ranges and templates,
like std.algorithm, so things will work across many different image
formats with the best efficiency and minimal coupling. But, we need to
think about some specifics before going too far.

Here's a first draft module to show the idea while doing some useful
work. It's dependency free so you can download and play with ease.

http://arsdnet.net/dcode/imagedraft.d


If you also grab simpledisplay.d
http://arsdnet.net/dcode/simpledisplay.d

You can compile this little png display program:

=======
import imagedraft;
import std.stdio;

import simpledisplay;

void main(string[] args) {
	auto png = pngFromBytes(File(args[1]).byChunk(4096));
	auto image = new Image(png.header.width, png.header.height);

	int y;
	foreach(line; png.byRgbaScanline) {
		foreach(x, color; line.pixels)
			image.putPixel(cast(int) x, cast(int) y,
				simpledisplay.Color(color.r, color.g, color.b, color.a));
		y++;
	}

	displayImage(image);
}
====

And use it as a base to play around and see your algorithm's results
right in the window. (btw, that displayImage() function is what used
to be image.display() in simpledisplay. A standalone function will
let me separate dependencies better. It works the same way - just
show it and wait for the user to hit any key to continue.)

The foreach there is ugly. I was going to write up a demo
of some actual algorithms for images, but I ended up spending
most the day getting my BufferedInputRange and LazyPngFile to
work correctly...

But, you can see one of the big ideas: providing ranges on images
of various formats that present the data to you in a requested
standard format (any PNG image is lazily converted to an rgba list
of lines here).

It also shows how I plan to write other image format loaders - they
take arbitrary input ranges, and lazily load and decode the file.
(While I had a png loader before, it was in C style.... I'm hoping
that it will be easier to port my bmp code now that I have a working
foundation...)

I'll write an image saver too. It will take an rgbaScanLine range
and save it to the correct format - png, bmp, whatever.


Now, back to the main idea here. I wish I had more time. If I fleshed
out this existing range a little more, we could do fun things
like call std.algorithm.levenshteinDistance on it.. but right now,
it's just an input range, which is fairly limited. I figure the
best thing to do is offer whatever facilities the source range offers,
so if you give it an array, you can save(), back(), etc. too.

Still, we can run a few functions on it.

 foreach(line; filter!"a.pixels[0].r > 200"(png.byRgbaScanline)) {
 }

Only keeps lines with a lot of red in the first pixel.

So that's pretty cool.



Aaaanyway, I want to have a bunch of algorithms written in here that
can work on these ranges, capable of doing both in-place and lazy
changes to your image.

Since I messed up the time, I only wrote one (and it sucks, hard),
but it's the idea I have in mind: the convertToGreyscale function.
Any image that provides a range it can use will work for it.



What kind of ranges would be useful? A by line surely is, which
is why I started with it. A byPixel perhaps? Maybe a byBlock? Though,
it for byPixel, it seems like opApply is the way to do it. Maybe it
can even shove it off to the GPU to do the work. That's beyond my
knowledge, but David Simcha has done some cool stuff with foreach
and parallelism, and this is basically the same concept, so I'm
sure it can be done.

Then, of course, you'll surely still want opIndex into the pixels
too.

I was hoping to have time to write a gaussian blur function to put
the idea to the test...


The other thing is drawing. I don't think ranges will help much there.
Drawing algorithms will probably be ok with opIndexAssign into the
pixels.


But, it's time for me to get to the work I was supposed to do today.
If nothing else, hopefully that PNG loader in there will be useful,
but I really do think there's a lot of potential in the idea of
a std.algorithm for images and would like any input you have.

Thanks for all the feedback this weekend, everyone!
Apr 10 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:


 I'm pretty happy with how simpledisplay.d is turning out,


I have tried the fractal tree program, the window doesn't close if you click on
the button on the top right.



 http://arsdnet.net/dcode/imagedraft.d


I suggest you to always compile your D code with -w, in imagedraft.d there is a
switch (line 328) without default.


foreach(line; filter!"a.pixels[0].r > 200"(png.byRgbaScanline)) {
I suggest ==>
foreach(line; filter!"a.pixels[0].r > 200"(png.byRGBAline())) {
Or even:
foreach(line; filter!"a.pixels[0].r > 200"(png.byRGBAScanline())) {



 What kind of ranges would be useful?


Several basic image processing algorithms use a 3x3 (or bigger) neighbourhood
to process images.



 A byPixel perhaps?


Of course :-)
For few ideas look at Python PIL docs:
http://www.pythonware.com/library/pil/handbook/index.htm
http://www.pythonware.com/library/pil/handbook/image.htm



 Thanks for all the feedback this weekend, everyone!


You are welcome :-)

Bye,
bearophile
Apr 10 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 I have tried the fractal tree program, the window doesn't close
 if you click on the button on the top right.


OK, I'll try it on Windows next time I have my laptop out. I've
been doing everything on Linux and Wine so far, so there's probably
a few little differences that need some attention.

There's still a lot of little things that need to be done to finish
it. Probably still several full day's work to cross the t's and dot
the i's.


 I suggest you to always compile your D code with -w, in
 imagedraft.d there is a switch (line 328) without default.


Changed. It's supposed to throw there (all values allowed
in the spec are handled), but I guess it would be better to
shut the compiler up and maybe use a more specific exception at
the same time.


 foreach(line; byRGBAScanline)


Annoyingly, this seems to be the prevailing Phobos style, so I'll
probably change to that. I personally dislike the string of
capitals, but best to be consistent with the rest of the lib.


 For few ideas look at Python PIL docs:


Hmm, it doesn't seem to have the interfaces required. While
we could make some monster classes that do all the work in
a black box, I'm hoping to take an STL approach here, where
the actual data structures are as de-coupled as possible from
the algorithms.

For that, an API listing doesn't help much.... we'll have to
study the requirements of the algorithms themselves. There is
a good list of things to look up there, though.
Apr 10 2011
prev sibling next sibling parent reply Cliff Hudson <cliff.s.hudson gmail.com> writes:
You are on a tear with this image stuff :)

Have you considered wrapping something like DevIL?
http://openil.sourceforge.net/features.php  Probably has all the features
you could ever want and is cross-platform.
<http://openil.sourceforge.net/features.php>
- Cliff

On Sun, Apr 10, 2011 at 5:10 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 I'm pretty happy with how simpledisplay.d is turning out, and want to
 spend some time thinking about the client side images now.

 I think a nice way to do it would be to go with ranges and templates,
 like std.algorithm, so things will work across many different image
 formats with the best efficiency and minimal coupling. But, we need to
 think about some specifics before going too far.

 Here's a first draft module to show the idea while doing some useful
 work. It's dependency free so you can download and play with ease.

 http://arsdnet.net/dcode/imagedraft.d


 If you also grab simpledisplay.d
 http://arsdnet.net/dcode/simpledisplay.d

 You can compile this little png display program:

 =======
 import imagedraft;
 import std.stdio;

 import simpledisplay;

 void main(string[] args) {
        auto png = pngFromBytes(File(args[1]).byChunk(4096));
        auto image = new Image(png.header.width, png.header.height);

        int y;
        foreach(line; png.byRgbaScanline) {
                foreach(x, color; line.pixels)
                        image.putPixel(cast(int) x, cast(int) y,
                                simpledisplay.Color(color.r, color.g,
 color.b, color.a));
                y++;
        }

        displayImage(image);
 }
 ====

 And use it as a base to play around and see your algorithm's results
 right in the window. (btw, that displayImage() function is what used
 to be image.display() in simpledisplay. A standalone function will
 let me separate dependencies better. It works the same way - just
 show it and wait for the user to hit any key to continue.)

 The foreach there is ugly. I was going to write up a demo
 of some actual algorithms for images, but I ended up spending
 most the day getting my BufferedInputRange and LazyPngFile to
 work correctly...

 But, you can see one of the big ideas: providing ranges on images
 of various formats that present the data to you in a requested
 standard format (any PNG image is lazily converted to an rgba list
 of lines here).

 It also shows how I plan to write other image format loaders - they
 take arbitrary input ranges, and lazily load and decode the file.
 (While I had a png loader before, it was in C style.... I'm hoping
 that it will be easier to port my bmp code now that I have a working
 foundation...)

 I'll write an image saver too. It will take an rgbaScanLine range
 and save it to the correct format - png, bmp, whatever.


 Now, back to the main idea here. I wish I had more time. If I fleshed
 out this existing range a little more, we could do fun things
 like call std.algorithm.levenshteinDistance on it.. but right now,
 it's just an input range, which is fairly limited. I figure the
 best thing to do is offer whatever facilities the source range offers,
 so if you give it an array, you can save(), back(), etc. too.

 Still, we can run a few functions on it.

  foreach(line; filter!"a.pixels[0].r > 200"(png.byRgbaScanline)) {
  }

 Only keeps lines with a lot of red in the first pixel.

 So that's pretty cool.



 Aaaanyway, I want to have a bunch of algorithms written in here that
 can work on these ranges, capable of doing both in-place and lazy
 changes to your image.

 Since I messed up the time, I only wrote one (and it sucks, hard),
 but it's the idea I have in mind: the convertToGreyscale function.
 Any image that provides a range it can use will work for it.



 What kind of ranges would be useful? A by line surely is, which
 is why I started with it. A byPixel perhaps? Maybe a byBlock? Though,
 it for byPixel, it seems like opApply is the way to do it. Maybe it
 can even shove it off to the GPU to do the work. That's beyond my
 knowledge, but David Simcha has done some cool stuff with foreach
 and parallelism, and this is basically the same concept, so I'm
 sure it can be done.

 Then, of course, you'll surely still want opIndex into the pixels
 too.

 I was hoping to have time to write a gaussian blur function to put
 the idea to the test...


 The other thing is drawing. I don't think ranges will help much there.
 Drawing algorithms will probably be ok with opIndexAssign into the
 pixels.


 But, it's time for me to get to the work I was supposed to do today.
 If nothing else, hopefully that PNG loader in there will be useful,
 but I really do think there's a lot of potential in the idea of
 a std.algorithm for images and would like any input you have.

 Thanks for all the feedback this weekend, everyone!
Apr 10 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Cliff Hudson wrote:

 Have you considered wrapping something like DevIL?


I actually didn't consider it; since I already have decent homegrown
loaders for a few formats I figured that'd be good enough, for now
at least.

But, looking now, DevIL is LGPL. As I'm hoping to get into Phobos,
that will mean licensing problems. Phobos should Just Work for
endusers, meaning it ought to package everything it needs with it,
with the exception of operating system libraries.

Packaging the source for a big library to satisfy the LGPL won't
really work there :-(
Apr 10 2011
next sibling parent Cliff Hudson <cliff.s.hudson gmail.com> writes:
Ahh, good point, I didn't look too closely at the licensing.

- Cliff

On Sun, Apr 10, 2011 at 5:45 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 Cliff Hudson wrote:

 Have you considered wrapping something like DevIL?


 I actually didn't consider it; since I already have decent homegrown
 loaders for a few formats I figured that'd be good enough, for now
 at least.

 But, looking now, DevIL is LGPL. As I'm hoping to get into Phobos,
 that will mean licensing problems. Phobos should Just Work for
 endusers, meaning it ought to package everything it needs with it,
 with the exception of operating system libraries.

 Packaging the source for a big library to satisfy the LGPL won't
 really work there :-(
Apr 10 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/11/2011 02:45 AM, Adam D. Ruppe wrote:

 Cliff Hudson wrote:

  Have you considered wrapping something like DevIL?




 I actually didn't consider it; since I already have decent homegrown
 loaders for a few formats I figured that'd be good enough, for now
 at least.

 But, looking now, DevIL is LGPL. As I'm hoping to get into Phobos,
 that will mean licensing problems. Phobos should Just Work for
 endusers, meaning it ought to package everything it needs with it,
 with the exception of operating system libraries.

 Packaging the source for a big library to satisfy the LGPL won't
 really work there :-(


There is a point I don't understand: if I'm right, LGPL as well as all other 
"open source", not strictly free-software, licenses allow using licensed 
software even for "privative" (proprietary) work. But they wouldn't allow using 
software for work licensed under other open-source licenses like the Boost
license?
Where's the bug?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 11 2011
next sibling parent reply Kagamin <spam here.lot> writes:
spir Wrote:


 There is a point I don't understand: if I'm right, LGPL as well as all other 
 "open source", not strictly free-software, licenses allow using licensed 
 software even for "privative" (proprietary) work. But they wouldn't allow
using 
 software for work licensed under other open-source licenses like the Boost
license?
 Where's the bug?


They can be used, but they can't become proprietary or Boost licensed.
Apr 11 2011
parent Francisco Almeida <francisco.m.almeida gmail.com> writes:
== Quote from Kagamin (spam here.lot)'s article

 spir Wrote:

 There is a point I don't understand: if I'm right, LGPL as well as all other
 "open source", not strictly free-software, licenses allow using licensed
 software even for "privative" (proprietary) work. But they wouldn't allow using
 software for work licensed under other open-source licenses like the Boost




license?

 Where's the bug?


 They can be used, but they can't become proprietary or Boost licensed.


I'm sorry, but I don't understand this last statement. AFAIK, LGPL source code
may
be used for licensed software, as long as it is compiled so as to keep the
binaries separate (DLL or shared object).
Apr 11 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
spir wrote:

 There is a point I don't understand: if I'm right, LGPL as well as
 all other "open source", not strictly free-software, licenses allow
 using licensed software even for "privative" (proprietary) work.


If the user already had the library installed, I *think* we'd be
fine, but a standard library is distributed with D programs. LGPL
requires you to send source when distributing the library.

We want to keep distributing programs as easy as possible. I'm
not against using lgpl things, but it should be an extra step
so the programmer realizes he has another hurdle to deal with
(either packaging the source with his app or adding instructions
to the installer/readme file so the user can install the library
themselves).

In short, it will work, but it won't *Just Work*, and Phobos
definitely should Just Work.
Apr 11 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
[ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


I would have to check but as far as I remember the (L)GPL does not
require you to distribute the source with the compiled form if that is
what is distributed, it requires that the end user can get the source
for the compiled form.  From a distribution perspective these are very
different things.  cf. The Maven Repository, which distributes masses of
compiled jar files and no source in sight.

[ . . . ]
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 11 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk>  
wrote:


 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form.  From a distribution perspective these are very
 different things.  cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.


IIUC, the LGPL is like applying the GPL to the library, but does not  
restrict proprietary software from linking to it.  I think this means you  
can distribute your proprietary software without providing source code.   
However, if you supply the library (which is covered under the same rules  
as the GPL), then you must provide or provide upon request the source code  
to the LGPL-covered library.  If you don't ship the library, then you  
don't have to supply the source code, but then you are shipping a binary  
that doesn't work unless they also download the LGPL library separately.

It all adds up to "not going to be in druntime/Phobos" :)

-Steve
Apr 11 2011
parent reply Jonas Drewsen <jdrewsen nospam.com> writes:
On 11/04/11 22.01, Steven Schveighoffer wrote:

 On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk>
 wrote:


 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form. From a distribution perspective these are very
 different things. cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.


 IIUC, the LGPL is like applying the GPL to the library, but does not
 restrict proprietary software from linking to it. I think this means you
 can distribute your proprietary software without providing source code.
 However, if you supply the library (which is covered under the same
 rules as the GPL), then you must provide or provide upon request the
 source code to the LGPL-covered library. If you don't ship the library,
 then you don't have to supply the source code, but then you are shipping
 a binary that doesn't work unless they also download the LGPL library
 separately.

 It all adds up to "not going to be in druntime/Phobos" :)

 -Steve


Actually, if you haven't made any changes to the LGPL library that you 
are distribution then you can just refer to the projects homepage for 
the source code.

This also means that putting the list of URLs for the used LGPL 
libraries in the Phobos packages would suffice. Can't get much easier 
than that.

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

 On 11/04/11 22.01, Steven Schveighoffer wrote:

 On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk>
 wrote:


 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form. From a distribution perspective these are very
 different things. cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.


 IIUC, the LGPL is like applying the GPL to the library, but does not
 restrict proprietary software from linking to it. I think this means you
 can distribute your proprietary software without providing source code.
 However, if you supply the library (which is covered under the same
 rules as the GPL), then you must provide or provide upon request the
 source code to the LGPL-covered library. If you don't ship the library,
 then you don't have to supply the source code, but then you are shipping
 a binary that doesn't work unless they also download the LGPL library
 separately.

 It all adds up to "not going to be in druntime/Phobos" :)


 Actually, if you haven't made any changes to the LGPL library that you are 
 distribution then you can just refer to the projects homepage for the 
 source code.

 This also means that putting the list of URLs for the used LGPL libraries 
 in the Phobos packages would suffice. Can't get much easier than that.


Sounds like a pain for the users of Phobos (and maybe the users of 
Phobos-developed software?).

Regardless, I think we've clearly demonstrated the complete impenetrability 
of (L)GPL. I've long since given up trying to understand it, and I seriously 
doubt that anyone really truly understands it (it's the C++ of the legal 
world). Even if you do miraculously understand one form of it, there still 
probably about 10 other versions and half of them are even incompatible with 
each other (in poorly-understood ways). The whole thing's just a damn mess. 
I've always found it best to just avoid any (L)GPL source or library 
outright. Not worth the trouble.
Apr 11 2011
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
[ . . . ]

=20
 Regardless, I think we've clearly demonstrated the complete impenetrabili=


ty=20

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


sly=20

 doubt that anyone really truly understands it (it's the C++ of the legal=


=20

 world). Even if you do miraculously understand one form of it, there stil=


l=20

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


ith=20

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


s.=20

 I've always found it best to just avoid any (L)GPL source or library=20
 outright. Not worth the trouble.


GPL and LGPL are fine licences.  They only appear impenetrable because
there is no case law in the USA or UK to define the accepted meaning as
opposed to the intended meaning.  It may be that in countries that do
not rely on case law to give meaning to statutes, contracts and licence,
things are different.

Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
since they allow organizations to take software, sell it for profit and
return absolutely nothing to the development community.  I think LGPL is
the preferred licence for all non-proprietary software and am very glad
to find libraries that use it.

Sadly the Java world seems to have slipped from using LGPL to being
obsessed with using ASL 2.0 and professing hatred of LGPL.  ASL 2.0
claims to have a patent clause unlike all the other non (L)GPL licences,
but until this is tested in court so that there is case law no-one, not
even lawyers, actually know what the licences mean or entail.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 11 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...

Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
since they allow organizations to take software, sell it for profit and
return absolutely nothing to the development community.


I've never seen that as a realistic concern. Here's the basic scenario:

1. I make program Foo and release it under BSD/MIT/etc.

2. The company EvilSoftwareCo takes Foo and sells it giving me nothing.

That's what's seen as the problem, right? I'm not concerned because the 
obvious next steps are:

3. I go around spreading the fact that EvilSoftwareCo's Foo is available for 
free (both meanings of the term) from my site.

4. There isn't a fucking thing EvilSoftwareCo can do about it.

"But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as 
FooPlus? Your Foo doesn't get any of those extras!"

Don't care. If they put in the time and effort to add value to something, 
then they *should* be allowed to ask for compensation for their work under 
whatever business model they choose. And if the value they've added is 
merely trivial, then A. My version of Foo can still compete and B. I can 
just add it to my Foo myself (or anyone else can).
Apr 12 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 12:24, schrieb Nick Sabalausky:

 "Russel Winder" <russel russel.org.uk> wrote in message 
 news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...

 Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
 since they allow organizations to take software, sell it for profit and
 return absolutely nothing to the development community.


 
 I've never seen that as a realistic concern. Here's the basic scenario:
 
 1. I make program Foo and release it under BSD/MIT/etc.
 
 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing.
 
 That's what's seen as the problem, right? I'm not concerned because the 
 obvious next steps are:
 
 3. I go around spreading the fact that EvilSoftwareCo's Foo is available for 
 free (both meanings of the term) from my site.
 


What difference does it make? You don't have the money to reach
EvilSoftwareCo's (potential) costumers. Ranting in your blogs and some
mailinglists or whatever won't change anything.
They do big marketing to sell your software (with their small
additions), they claim its stable and certified etcpp.
So they still make big money with your code without giving anything
(neither code nor money) back.


 4. There isn't a fucking thing EvilSoftwareCo can do about it.
 
 "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as 
 FooPlus? Your Foo doesn't get any of those extras!"
 
 Don't care. If they put in the time and effort to add value to something, 
 then they *should* be allowed to ask for compensation for their work under 
 whatever business model they choose. And if the value they've added is 
 merely trivial, then A. My version of Foo can still compete and B. I can 
 just add it to my Foo myself (or anyone else can).
 


The problem is not only that they get money for your code (+their
extras), it's also that suddenly there's an incompatible version of your
program.
Maybe it's incompatible with your file formats etc. If their FooPlus is
successful your Foo may become obsolete.
Apr 12 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:io1als$jsc$15 digitalmars.com...

 Am 12.04.2011 12:24, schrieb Nick Sabalausky:

 "Russel Winder" <russel russel.org.uk> wrote in message
 news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...

 Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
 since they allow organizations to take software, sell it for profit and
 return absolutely nothing to the development community.


 I've never seen that as a realistic concern. Here's the basic scenario:

 1. I make program Foo and release it under BSD/MIT/etc.

 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing.

 That's what's seen as the problem, right? I'm not concerned because the
 obvious next steps are:

 3. I go around spreading the fact that EvilSoftwareCo's Foo is available 
 for
 free (both meanings of the term) from my site.


 What difference does it make? You don't have the money to reach
 EvilSoftwareCo's (potential) costumers. Ranting in your blogs and some
 mailinglists or whatever won't change anything.
 They do big marketing to sell your software (with their small
 additions), they claim its stable and certified etcpp.
 So they still make big money with your code without giving anything
 (neither code nor money) back.


Sending out a press release is dirt-cheap. If EvilSoftwareCo is actually 
making significant money, then it's very likely that some news outlets would 
jump at a story like "Big company charging people for a free program."

Or even better yet: EvilSoftwareCo would have done the hard work of proving 
that there's a viable commercial market for Foo. Since I already have the 
same product, I either de-OSS the next version of Foo or cave and make it 
GPL, go get the world's easiest VC or business loan (again, EvilSoftwareCo 
did the hard work of proving the viable market), use those funds to 
advertise/market about being "The real creator of Foo", undercut 
EvilSoftwareCo, and then laugh all the way to the bank as EvilSoftwareCo 
goes under.



 4. There isn't a fucking thing EvilSoftwareCo can do about it.

 "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it 
 as
 FooPlus? Your Foo doesn't get any of those extras!"

 Don't care. If they put in the time and effort to add value to something,
 then they *should* be allowed to ask for compensation for their work 
 under
 whatever business model they choose. And if the value they've added is
 merely trivial, then A. My version of Foo can still compete and B. I can
 just add it to my Foo myself (or anyone else can).


 The problem is not only that they get money for your code (+their
 extras), it's also that suddenly there's an incompatible version of your
 program.
 Maybe it's incompatible with your file formats etc. If their FooPlus is
 successful your Foo may become obsolete.


That would still be equally possible even if FooPlus were a completely open 
project.
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 13:02, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:io1als$jsc$15 digitalmars.com...

 Am 12.04.2011 12:24, schrieb Nick Sabalausky:

 "Russel Winder" <russel russel.org.uk> wrote in message
 news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...

 Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
 since they allow organizations to take software, sell it for profit and
 return absolutely nothing to the development community.


 I've never seen that as a realistic concern. Here's the basic scenario:

 1. I make program Foo and release it under BSD/MIT/etc.

 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing.

 That's what's seen as the problem, right? I'm not concerned because the
 obvious next steps are:

 3. I go around spreading the fact that EvilSoftwareCo's Foo is available 
 for
 free (both meanings of the term) from my site.


 What difference does it make? You don't have the money to reach
 EvilSoftwareCo's (potential) costumers. Ranting in your blogs and some
 mailinglists or whatever won't change anything.
 They do big marketing to sell your software (with their small
 additions), they claim its stable and certified etcpp.
 So they still make big money with your code without giving anything
 (neither code nor money) back.


 
 Sending out a press release is dirt-cheap. If EvilSoftwareCo is actually 
 making significant money, then it's very likely that some news outlets would 
 jump at a story like "Big company charging people for a free program."
 
 Or even better yet: EvilSoftwareCo would have done the hard work of proving 
 that there's a viable commercial market for Foo. Since I already have the 
 same product, I either de-OSS the next version of Foo or cave and make it 
 GPL, go get the world's easiest VC or business loan (again, EvilSoftwareCo 
 did the hard work of proving the viable market), use those funds to 
 advertise/market about being "The real creator of Foo", undercut 
 EvilSoftwareCo, and then laugh all the way to the bank as EvilSoftwareCo 
 goes under.
 


What's left on that market when EvilSoftwareCo is already in it?
"I wanna sell a Office Suite, Microsoft makes millions with it so it's a
viable market"


 

 4. There isn't a fucking thing EvilSoftwareCo can do about it.

 "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it 
 as
 FooPlus? Your Foo doesn't get any of those extras!"

 Don't care. If they put in the time and effort to add value to something,
 then they *should* be allowed to ask for compensation for their work 
 under
 whatever business model they choose. And if the value they've added is
 merely trivial, then A. My version of Foo can still compete and B. I can
 just add it to my Foo myself (or anyone else can).


 The problem is not only that they get money for your code (+their
 extras), it's also that suddenly there's an incompatible version of your
 program.
 Maybe it's incompatible with your file formats etc. If their FooPlus is
 successful your Foo may become obsolete.


 
 That would still be equally possible even if FooPlus were a completely open 
 project.
 


But than you could at least integrate their changes into your version to
support their file format etc
Apr 12 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:io1c0b$jsc$18 digitalmars.com...

 Am 12.04.2011 13:02, schrieb Nick Sabalausky:

 Sending out a press release is dirt-cheap. If EvilSoftwareCo is actually
 making significant money, then it's very likely that some news outlets 
 would
 jump at a story like "Big company charging people for a free program."

 Or even better yet: EvilSoftwareCo would have done the hard work of 
 proving
 that there's a viable commercial market for Foo. Since I already have the
 same product, I either de-OSS the next version of Foo or cave and make it
 GPL, go get the world's easiest VC or business loan (again, 
 EvilSoftwareCo
 did the hard work of proving the viable market), use those funds to
 advertise/market about being "The real creator of Foo", undercut
 EvilSoftwareCo, and then laugh all the way to the bank as EvilSoftwareCo
 goes under.


 What's left on that market when EvilSoftwareCo is already in it?
 "I wanna sell a Office Suite, Microsoft makes millions with it so it's a
 viable market"


If I had actually created Office Suite and owned the rights to it, I do 
think I would have a good shot at making some inroads with the combination 
of "I made it and own it" and undercutting.

And even if not, at least lots of people would be using my software. If I 
had actually been giving it away in the first place, then clearly that would 
have been my larger goal anyway. Being "creator of MS Office" would look 
pretty good on a resume', and that would be something they they would have 
actually *helped* you with - something you wouldn't likely have had 
otherwise.

And most of all, I really think the chances of getting irreprably screwed 
over like that by putting a program out as BSD instead of GPL are small 
enough to just not be worth worrying about. Heck, you'd probably have a 
better chance of getting killed by another car on the way to the grocery 
store.



 The problem is not only that they get money for your code (+their
 extras), it's also that suddenly there's an incompatible version of your
 program.
 Maybe it's incompatible with your file formats etc. If their FooPlus is
 successful your Foo may become obsolete.


 That would still be equally possible even if FooPlus were a completely 
 open
 project.


 But than you could at least integrate their changes into your version to
 support their file format etc


Yea, but now the whole argument has been whittled down to quite a lot of 
"if"s.
Apr 12 2011
parent spir <denis.spir gmail.com> writes:
On 04/12/2011 01:31 PM, Nick Sabalausky wrote:

 And most of all, I really think the chances of getting irreprably screwed
 over like that by putting a program out as BSD instead of GPL are small
 enough to just not be worth worrying about.


Isn't BSD license also unwelcome into Phobos? (/That/ issue was the original 
point of the thread.)
And what about the creative commons attribution-share alike (which I like)?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/12/2011 12:24 PM, Nick Sabalausky wrote:

 "Russel Winder"<russel russel.org.uk>  wrote in message
 news:mailman.3416.1302591172.4748.digitalmars-d puremagic.com...

 Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
 since they allow organizations to take software, sell it for profit and
 return absolutely nothing to the development community.


 I've never seen that as a realistic concern. Here's the basic scenario:

 1. I make program Foo and release it under BSD/MIT/etc.

 2. The company EvilSoftwareCo takes Foo and sells it giving me nothing.

 That's what's seen as the problem, right? I'm not concerned because the
 obvious next steps are:

 3. I go around spreading the fact that EvilSoftwareCo's Foo is available for
 free (both meanings of the term) from my site.

 4. There isn't a fucking thing EvilSoftwareCo can do about it.

 "But what if EvilSoftwareCo makes proprietary changes to Foo and sells it as
 FooPlus? Your Foo doesn't get any of those extras!"

 Don't care. If they put in the time and effort to add value to something,
 then they *should* be allowed to ask for compensation for their work under
 whatever business model they choose. And if the value they've added is
 merely trivial, then A. My version of Foo can still compete and B. I can
 just add it to my Foo myself (or anyone else can).


That's true. And I'm all for EvilSoftwareCo to get money for *their* work; 
rather than for theirs *and* yours ;-) (where 'you' may also be a whole 
community -- that would not even have the opportunity to reuse EvilSoftwareCo's 
advances)
Just like I'm all for music editors to get money for their work: edition, or 
rather distribution. But in reality, they used to get a de facto tax on 
listening to music (via copyright).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
prev sibling next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Tue, Apr 12, 2011 at 1:52 AM, Russel Winder <russel russel.org.uk> wrote=
:

 On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
 [ . . . ]

 Regardless, I think we've clearly demonstrated the complete impenetrabil=




ity

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




usly

 doubt that anyone really truly understands it (it's the C++ of the legal
 world). Even if you do miraculously understand one form of it, there sti=




ll

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




with

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




ss.

 I've always found it best to just avoid any (L)GPL source or library
 outright. Not worth the trouble.


 GPL and LGPL are fine licences. =A0They only appear impenetrable because
 there is no case law in the USA or UK to define the accepted meaning as
 opposed to the intended meaning. =A0It may be that in countries that do
 not rely on case law to give meaning to statutes, contracts and licence,
 things are different.

 Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
 since they allow organizations to take software, sell it for profit and
 return absolutely nothing to the development community. =A0I think LGPL i=


s

 the preferred licence for all non-proprietary software and am very glad
 to find libraries that use it.

 Sadly the Java world seems to have slipped from using LGPL to being
 obsessed with using ASL 2.0 and professing hatred of LGPL. =A0ASL 2.0
 claims to have a patent clause unlike all the other non (L)GPL licences,
 but until this is tested in court so that there is case law no-one, not
 even lawyers, actually know what the licences mean or entail.


The Java world likes ASL precisely because software licensed under it
can be sold. Take a look at the signature lines of the main
contributors to large open source Java projects. It's common for large
companies to pay programmers to develop open source software that's
eventually shipped in products, and at the end of the day, the
community benefits.

Now yes, it's entirely an honor system, and there's certainly a risk
involved, but in general, the ASL has made Java's open source
community grow quite a bit.
Apr 12 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Andrew Wiley wrote:

 The Java world likes ASL precisely because software licensed under it
 can be sold.


	Note that both GPL and LGPL allow you to sell the software...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 12 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/12/11, "J=E9r=F4me M. Berger" <jeberger free.fr> wrote:

 Andrew Wiley wrote:

 The Java world likes ASL precisely because software licensed under it
 can be sold.


 	Note that both GPL and LGPL allow you to sell the software...


Practically this means you can sell services. And not everyone is in
the business of services.
Apr 12 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 01:47 AM, Nick Sabalausky wrote:

 "Jonas Drewsen"<jdrewsen nospam.com>  wrote in message
 news:invnrn$2pgf$1 digitalmars.com...

 On 11/04/11 22.01, Steven Schveighoffer wrote:

 On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder<russel russel.org.uk>
 wrote:


 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form. From a distribution perspective these are very
 different things. cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.


 IIUC, the LGPL is like applying the GPL to the library, but does not
 restrict proprietary software from linking to it. I think this means you
 can distribute your proprietary software without providing source code.
 However, if you supply the library (which is covered under the same
 rules as the GPL), then you must provide or provide upon request the
 source code to the LGPL-covered library. If you don't ship the library,
 then you don't have to supply the source code, but then you are shipping
 a binary that doesn't work unless they also download the LGPL library
 separately.

 It all adds up to "not going to be in druntime/Phobos" :)


 Actually, if you haven't made any changes to the LGPL library that you are
 distribution then you can just refer to the projects homepage for the
 source code.

 This also means that putting the list of URLs for the used LGPL libraries
 in the Phobos packages would suffice. Can't get much easier than that.


 Sounds like a pain for the users of Phobos (and maybe the users of
 Phobos-developed software?).


I don't understand where the pain lies, here.


 Regardless, I think we've clearly demonstrated the complete impenetrability
 of (L)GPL. I've long since given up trying to understand it, and I seriously
 doubt that anyone really truly understands it (it's the C++ of the legal
 world). Even if you do miraculously understand one form of it, there still
 probably about 10 other versions and half of them are even incompatible with
 each other (in poorly-understood ways). The whole thing's just a damn mess.


Have not had a look at the Boost license, but a priori I doubt it to be more 
"penetrable" than any other open-source one. They all are somewhat convoluted 
because they use a right-privating legal tool (a license) to /provide/ rights 
to the user.


 I've always found it best to just avoid any (L)GPL source or library
 outright. Not worth the trouble.


What about other ones, like Creative Commons licenses?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.3420.1302596459.4748.digitalmars-d puremagic.com...

 On 04/12/2011 01:47 AM, Nick Sabalausky wrote:


 I've always found it best to just avoid any (L)GPL source or library
 outright. Not worth the trouble.


 What about other ones, like Creative Commons licenses?


I don't trust any legal document that actually has any need for a separate 
"plain English" version. The one thing that will change my mind on that is 
if I hear from a reliable source that "plain English" versions can be 
legally binding and take precedence over the legalese version when there's a 
discrepancy.

I am a big fan of zlib/libpng though. And I like MIT/new-BSD, too. Not 
exactly thrilled about Boost, but I am ok with it. It's far more 
understandable than (L)GPL, at least.
Apr 12 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 12 Apr 2011 04:20:44 -0400, spir <denis.spir gmail.com> wrote:


 On 04/12/2011 01:47 AM, Nick Sabalausky wrote:

 "Jonas Drewsen"<jdrewsen nospam.com>  wrote in message
 news:invnrn$2pgf$1 digitalmars.com...

 On 11/04/11 22.01, Steven Schveighoffer wrote:

 On Mon, 11 Apr 2011 13:05:24 -0400, Russel  
 Winder<russel russel.org.uk>
 wrote:


 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that  
 is
 what is distributed, it requires that the end user can get the source
 for the compiled form. From a distribution perspective these are very
 different things. cf. The Maven Repository, which distributes masses  
 of
 compiled jar files and no source in sight.


 IIUC, the LGPL is like applying the GPL to the library, but does not
 restrict proprietary software from linking to it. I think this means  
 you
 can distribute your proprietary software without providing source  
 code.
 However, if you supply the library (which is covered under the same
 rules as the GPL), then you must provide or provide upon request the
 source code to the LGPL-covered library. If you don't ship the  
 library,
 then you don't have to supply the source code, but then you are  
 shipping
 a binary that doesn't work unless they also download the LGPL library
 separately.

 It all adds up to "not going to be in druntime/Phobos" :)


 Actually, if you haven't made any changes to the LGPL library that you  
 are
 distribution then you can just refer to the projects homepage for the
 source code.

 This also means that putting the list of URLs for the used LGPL  
 libraries
 in the Phobos packages would suffice. Can't get much easier than that.


 Sounds like a pain for the users of Phobos (and maybe the users of
 Phobos-developed software?).


 I don't understand where the pain lies, here.


The requirement of the *end user* of phobos (i.e. the developer) to have  
to provide means to download/access the library.  For instance, if I make  
a boxed game written in D, I also have to worry about LGPL and making sure  
the end user (who likely cares not at all about the LGPL'd library) can  
access the source.  This means putting their license and either source  
code or link to the source code in my documentation.  It might be worth it  
if I want that library badly enough, but it shouldn't be *required* just  
for writing code in the D language.

A language should be free of such encumbrances.  A language is a tool, and  
should not require special licensing for the end user to pass on to their  
clients.  The *tools* to use the language can be whatever license you  
want, but the user's resulting product should be able to be licensed  
however they want.  This, BTW, is why BSD is not acceptable for Phobos.   
The requirement to put the license in the documentation (even if you  
distribute binary-only) is no good.  Yes, people have said that you can  
embed the license in the binary via a string, but the stigma is still  
there.  There are some companies that will balk at that requirement.  D  
should be available to anyone who wants to use it.

-Steve
Apr 12 2011
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Steven Schveighoffer wrote:

 This, BTW, is why BSD is not acceptable for Phobos.=20
 The requirement to put the license in the documentation (even if you
 distribute binary-only) is no good.


	Have you looked at the license agreement for most Microsoft
products? or most major video games? They all have some line saying
that "this product uses software developed by such and such", which
is no less than the BSD requires...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 12 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 12 Apr 2011 13:54:19 -0400, Jérôme M. Berger <jeberger free.fr>  
wrote:


 Steven Schveighoffer wrote:

 This, BTW, is why BSD is not acceptable for Phobos.
 The requirement to put the license in the documentation (even if you
 distribute binary-only) is no good.


 	Have you looked at the license agreement for most Microsoft
 products? or most major video games? They all have some line saying
 that "this product uses software developed by such and such", which
 is no less than the BSD requires...


Right, but not because they used C, C++, Java, or whatever, to develop  
it.  It's because they *chose* to include that BSD-licensed library.  If  
that library is a part of Phobos, *any* D-developed program will require  
that attribution, which means if you don't want to have that attribution  
requirement, you will choose another language.

I'm not saying BSD is bad, or (L)GPL is bad, they are fine licenses to  
choose for any OSS project you want, but they are not appropriate for the  
core standard library.

Of course, there are exceptions.  For example glibc is practically  
guaranteed to be on any Linux system, so having it be LGPL works perfectly  
fine -- there is no need to redistribute it.  On the other hand, having to  
use the client's libc can run into bad compatibility issues in some cases.

-Steve
Apr 12 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vttw2bybeav7ka steve-laptop...

 This, BTW, is why BSD is not acceptable for Phobos.   The requirement to 
 put the license in the documentation (even if you  distribute binary-only) 
 is no good.  Yes, people have said that you can  embed the license in the 
 binary via a string, but the stigma is still  there.  There are some 
 companies that will balk at that requirement.  D  should be available to 
 anyone who wants to use it.


FWIW, zlib is very similar to BSD, but doesn't have that problem.
Apr 12 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 09:05 AM, Andrew Wiley wrote:

 On Tue, Apr 12, 2011 at 1:52 AM, Russel Winder<russel russel.org.uk>  wrote:

 On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
 [ . . . ]

 Regardless, I think we've clearly demonstrated the complete impenetrability
 of (L)GPL. I've long since given up trying to understand it, and I seriously
 doubt that anyone really truly understands it (it's the C++ of the legal
 world). Even if you do miraculously understand one form of it, there still
 probably about 10 other versions and half of them are even incompatible with
 each other (in poorly-understood ways). The whole thing's just a damn mess.
 I've always found it best to just avoid any (L)GPL source or library
 outright. Not worth the trouble.


 GPL and LGPL are fine licences.  They only appear impenetrable because
 there is no case law in the USA or UK to define the accepted meaning as
 opposed to the intended meaning.  It may be that in countries that do
 not rely on case law to give meaning to statutes, contracts and licence,
 things are different.

 Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
 since they allow organizations to take software, sell it for profit and
 return absolutely nothing to the development community.  I think LGPL is
 the preferred licence for all non-proprietary software and am very glad
 to find libraries that use it.

 Sadly the Java world seems to have slipped from using LGPL to being
 obsessed with using ASL 2.0 and professing hatred of LGPL.  ASL 2.0
 claims to have a patent clause unlike all the other non (L)GPL licences,
 but until this is tested in court so that there is case law no-one, not
 even lawyers, actually know what the licences mean or entail.


 The Java world likes ASL precisely because software licensed under it
 can be sold. Take a look at the signature lines of the main
 contributors to large open source Java projects. It's common for large
 companies to pay programmers to develop open source software that's
 eventually shipped in products, and at the end of the day, the
 community benefits.


This is complete misinterpretation. *All* free software can be sold.


 Now yes, it's entirely an honor system, and there's certainly a risk
 involved, but in general, the ASL has made Java's open source
 community grow quite a bit.


This is an empty assertion. Can you point to any study logically demonstrating 
any relation between Java's preferred license and "Java's open source community 
grow[ing] quite a bit"? Or even to a theoretical reason for this?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 10:29, schrieb spir:

 On 04/12/2011 09:05 AM, Andrew Wiley wrote:

 On Tue, Apr 12, 2011 at 1:52 AM, Russel Winder<russel russel.org.uk> 
 wrote:

 On Mon, 2011-04-11 at 19:47 -0400, Nick Sabalausky wrote:
 [ . . . ]

 Regardless, I think we've clearly demonstrated the complete
 impenetrability
 of (L)GPL. I've long since given up trying to understand it, and I
 seriously
 doubt that anyone really truly understands it (it's the C++ of the
 legal
 world). Even if you do miraculously understand one form of it, there
 still
 probably about 10 other versions and half of them are even
 incompatible with
 each other (in poorly-understood ways). The whole thing's just a
 damn mess.
 I've always found it best to just avoid any (L)GPL source or library
 outright. Not worth the trouble.


 GPL and LGPL are fine licences.  They only appear impenetrable because
 there is no case law in the USA or UK to define the accepted meaning as
 opposed to the intended meaning.  It may be that in countries that do
 not rely on case law to give meaning to statutes, contracts and licence,
 things are different.

 Personally I find licences such as BSD, MIT, ASL, etc. ones to avoid
 since they allow organizations to take software, sell it for profit and
 return absolutely nothing to the development community.  I think LGPL is
 the preferred licence for all non-proprietary software and am very glad
 to find libraries that use it.

 Sadly the Java world seems to have slipped from using LGPL to being
 obsessed with using ASL 2.0 and professing hatred of LGPL.  ASL 2.0
 claims to have a patent clause unlike all the other non (L)GPL licences,
 but until this is tested in court so that there is case law no-one, not
 even lawyers, actually know what the licences mean or entail.


 The Java world likes ASL precisely because software licensed under it
 can be sold. Take a look at the signature lines of the main
 contributors to large open source Java projects. It's common for large
 companies to pay programmers to develop open source software that's
 eventually shipped in products, and at the end of the day, the
 community benefits.


 
 This is complete misinterpretation. *All* free software can be sold.
 

 Now yes, it's entirely an honor system, and there's certainly a risk
 involved, but in general, the ASL has made Java's open source
 community grow quite a bit.


 
 This is an empty assertion. Can you point to any study logically
 demonstrating any relation between Java's preferred license and "Java's
 open source community grow[ing] quite a bit"? Or even to a theoretical
 reason for this?
 
 Denis


I don't have a study at hand, but companies often prefer BSD-style
licenses to the GPL because they want to be able to reuse the code in
their proprietary without open-sourcing them as well.
Example: Apple reimplements the samba-service (SMB - Windows file
sharing) because they don't like the GPLv3. And they push LLVM because
they don't want to use GCC anymore. (But maybe this is because of the
GPLv3 and not the GPL in general.)

Furthermore many (most?) Open Source Java projects are mainly developed
by companies and they chose this kind of license, so I think it's
reasonable to assume that they prefer this kind of license to the GPL
and wouldn't invest so much into these projects if they had a license
they disliked.

Cheers,
- Daniel
Apr 12 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 10:41, schrieb Daniel Gibson:

 Am 12.04.2011 10:29, schrieb spir:

 On 04/12/2011 09:05 AM, Andrew Wiley wrote:

 The Java world likes ASL precisely because software licensed under it
 can be sold. Take a look at the signature lines of the main
 contributors to large open source Java projects. It's common for large
 companies to pay programmers to develop open source software that's
 eventually shipped in products, and at the end of the day, the
 community benefits.


 This is complete misinterpretation. *All* free software can be sold.


 Now yes, it's entirely an honor system, and there's certainly a risk
 involved, but in general, the ASL has made Java's open source
 community grow quite a bit.


 This is an empty assertion. Can you point to any study logically
 demonstrating any relation between Java's preferred license and "Java's
 open source community grow[ing] quite a bit"? Or even to a theoretical
 reason for this?

 Denis


 
 I don't have a study at hand, but companies often prefer BSD-style
 licenses to the GPL because they want to be able to reuse the code in
 their proprietary without open-sourcing them as well.
 Example: Apple reimplements the samba-service (SMB - Windows file
 sharing) because they don't like the GPLv3. And they push LLVM because
 they don't want to use GCC anymore. (But maybe this is because of the
 GPLv3 and not the GPL in general.)
 
 Furthermore many (most?) Open Source Java projects are mainly developed
 by companies and they chose this kind of license, so I think it's
 reasonable to assume that they prefer this kind of license to the GPL
 and wouldn't invest so much into these projects if they had a license
 they disliked.
 
 Cheers,
 - Daniel


What I'd like to add: The GPL is an ideological license. Most companies
aren't ideological, at least not when it comes to software licenses.
They don't use and develop FOSS because they think that the idea of free
software is great and all software should be free (because the products
they sell aren't).
Companies support Open Source for practical reasons (i.e. to save money
and effort): Some components of their software is pretty generic and a
lot of other companies need the same components, so they collaborate and
everybody saves money. But other components of software is pretty
specific and they make money of it so they don't want to release it as
Open Source. So they can't use the GPL for this kind of stuff and even
the LGPL isn't too useful if you want to integrate the source directly
and not put it in a DLL.

Of course they could do that without Open Source, but I guess it's a
huge pain in the ass because of all the legal mumbo jumbo involved when
collaborating with a competitor on closed source software. They need
NDAs, they have to specify who may do what with the software and the
source (maybe sell the source to a 3rd party etc), what happens if both
companies suddenly start suing each other because of some reason, what
happens if one of the companies is bought (possibly by the other
companies arch enemy), ....

With Open Source there's just the project, possibly organized in a
democratic way, and everybody can use it and can contribute - even if
they're competitors that would *never* work together otherwise.

Cheers,
- Daniel
Apr 12 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.3421.1302596976.4748.digitalmars-d puremagic.com...

 This is complete misinterpretation. *All* free software can be sold.


Technically, yes. Realistically, no. If there's software that's 
free-as-in-freedom, then it's inevitably free-as-in-beer as well. If it's 
free-as-in-beer, then who the hell is going to buy it, and what the heck 
for?

That said, there is at least *one* thing I like about GPL: From what 
(incredibly little) I understand of it, it seems that it's actually 
realistic to have a dual-license between GPL and commercial/proprietary. 
I've seen software out there that allows the user to choose between getting 
it under GPL for free, or getting it non-GPL for a fee. I can see how that 
can work out (depending, of course, on the incomprehensible details of the 
GPL). But if you changed it from "GPL or commercial" to, say, "BSD or 
commercial", then the "commercial" choice would seem to loose all its value. 
You'd have to charge for something else, like support or merchandice or 
something.

Actually, because of that, I could likely be enticed by an (L)GPL-like 
license if it was actually readable like zlib, BSD, or MIT, and easier for 
users/developers to comply with.
Apr 12 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 12:45, schrieb Nick Sabalausky:

 "spir" <denis.spir gmail.com> wrote in message 
 news:mailman.3421.1302596976.4748.digitalmars-d puremagic.com...

 This is complete misinterpretation. *All* free software can be sold.


 
 Technically, yes. Realistically, no. If there's software that's 
 free-as-in-freedom, then it's inevitably free-as-in-beer as well. If it's 
 free-as-in-beer, then who the hell is going to buy it, and what the heck 
 for?
 
 That said, there is at least *one* thing I like about GPL: From what 
 (incredibly little) I understand of it, it seems that it's actually 
 realistic to have a dual-license between GPL and commercial/proprietary. 
 I've seen software out there that allows the user to choose between getting 
 it under GPL for free, or getting it non-GPL for a fee. I can see how that 
 can work out (depending, of course, on the incomprehensible details of the 
 GPL). But if you changed it from "GPL or commercial" to, say, "BSD or 
 commercial", then the "commercial" choice would seem to loose all its value. 
 You'd have to charge for something else, like support or merchandice or 
 something.


You can also sell support for/with GPL software.


 
 Actually, because of that, I could likely be enticed by an (L)GPL-like 
 license if it was actually readable like zlib, BSD, or MIT, and easier for 
 users/developers to comply with.
 


Even though the GPL isn't easy to read I think it's not too hard to
comply with (at least v2). Basically it's "release the source of your
changes, don't mix in source from incompatible licenses and don't delete
the original authors from the GPL headers" - the second part may not be
so easy but you also have to comply with it when using any other license
(e.g. don't paste BSD licensed code into boost licensed code) and the
third part is also the same with most licenses: the original
author/copyright holder is mentioned somewhere (mostly in a comment at
the top of source files) and you may not delete that and claim you wrote
everything yourself.

The GPLv3 has some additional restrictions, e.g.
 * "TiVo clause": It isn't sufficient to release the source, the user
has to be able to actually use self compiled versions of that source on
the device you shipped the code with. Named after TiVo devices that ship
with Linux and standard Linux tools but doesn't allow the user to flash
his own system (or modified tools etc) onto the device.
 * Something with patents, I think it was something like "if you hold a
patent that applies to this software and contribute to it you may not
sue people who use this software for violating your patent".
Corporations seem to be unhappy with that but I think it's a legit demand.

Cheers,
- Daniel
Apr 12 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Daniel Gibson wrote:

 Am 12.04.2011 12:45, schrieb Nick Sabalausky:

 Actually, because of that, I could likely be enticed by an (L)GPL-like=




=20

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




 for=20

 users/developers to comply with.


=20
 Even though the GPL isn't easy to read I think it's not too hard to
 comply with (at least v2). Basically it's "release the source of your
 changes, don't mix in source from incompatible licenses and don't delet=


e
the original authors from the GPL headers"

	Not quite: you not only have to release the source of *your*
changes, but you also have to distribute the *whole* source (whether
you made any changes or not).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 20:11, schrieb "Jérôme M. Berger":

 Daniel Gibson wrote:

 Am 12.04.2011 12:45, schrieb Nick Sabalausky:

 Actually, because of that, I could likely be enticed by an (L)GPL-like 
 license if it was actually readable like zlib, BSD, or MIT, and easier for 
 users/developers to comply with.


 Even though the GPL isn't easy to read I think it's not too hard to
 comply with (at least v2). Basically it's "release the source of your
 changes, don't mix in source from incompatible licenses and don't delete


 the original authors from the GPL headers"
 
 	Not quite: you not only have to release the source of *your*
 changes, but you also have to distribute the *whole* source (whether
 you made any changes or not).
 
 		Jerome


If you don't change the source a link to the project homepage should
suffice.
And a link to the original source + your patch should be ok as well.
Apr 12 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Daniel Gibson wrote:

 Am 12.04.2011 20:11, schrieb "J=C3=A9r=C3=B4me M. Berger":

 Daniel Gibson wrote:

 Am 12.04.2011 12:45, schrieb Nick Sabalausky:

 Actually, because of that, I could likely be enticed by an (L)GPL-li=








ke=20

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








er for=20

 users/developers to comply with.


 Even though the GPL isn't easy to read I think it's not too hard to
 comply with (at least v2). Basically it's "release the source of your=







 changes, don't mix in source from incompatible licenses and don't del=






ete

 the original authors from the GPL headers"

 	Not quite: you not only have to release the source of *your*
 changes, but you also have to distribute the *whole* source (whether
 you made any changes or not).

 		Jerome


=20
 If you don't change the source a link to the project homepage should
 suffice.
 And a link to the original source + your patch should be ok as well.


	Only as a tolerance for free projects, commercial projects must
redistribute the whole source.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 13 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 12:45 PM, Nick Sabalausky wrote:

 (depending, of course, on the incomprehensible details of the
 GPL)


GPL is just one sample.
And I don't get your insistance on "incomprehensible details": as if you did 
not know *all* devices and all commercial software you have ever bought come 
with a contract and/or license full of incomprehensible details; not only that, 
but they are designed by professionnal legists to deceive you.
Free software license hairy legalist details are instead made, precisely, to 
avoid such deceiptions (by first users of the software, against end users).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.3438.1302612984.4748.digitalmars-d puremagic.com...

 On 04/12/2011 12:45 PM, Nick Sabalausky wrote:

 (depending, of course, on the incomprehensible details of the
 GPL)


 GPL is just one sample.
 And I don't get your insistance on "incomprehensible details": as if you 
 did not know *all* devices and all commercial software you have ever 
 bought come with a contract and/or license full of incomprehensible 
 details; not only that, but they are designed by professionnal legists to 
 deceive you.
 Free software license hairy legalist details are instead made, precisely, 
 to avoid such deceiptions (by first users of the software, against end 
 users).


Clickwrap agreements are known to difficult to enforce even when the company 
tries to enforce it. Plus it's pretty easy to just violate those licenses 
without anyone ever even knowing. And as far as putting out derivative 
works, the need to reverse-engineer (since they don't come with source) 
makes the whole idea of doing a derivative work fairly unrealistic anyway, 
so it doesn't really even enter into the picture.

Of course, if I'm merely going to *use* some program as an end-user, then I 
have no problem with GPL. And overall, yes, I do prefer GPL to closed-source 
proprietary. But if I'm interested in creating a derivative work, or using 
some library in software I plan to release, or just simply choosing a 
license for my own software, then I'm not happy with GPL *or* typical 
clickwrap licenses.
Apr 12 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 11 Apr 2011 16:17:29 -0400, Jonas Drewsen <jdrewsen nospam.com>  
wrote:


 On 11/04/11 22.01, Steven Schveighoffer wrote:

 On Mon, 11 Apr 2011 13:05:24 -0400, Russel Winder <russel russel.org.uk>
 wrote:


 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form. From a distribution perspective these are very
 different things. cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.


 IIUC, the LGPL is like applying the GPL to the library, but does not
 restrict proprietary software from linking to it. I think this means you
 can distribute your proprietary software without providing source code.
 However, if you supply the library (which is covered under the same
 rules as the GPL), then you must provide or provide upon request the
 source code to the LGPL-covered library. If you don't ship the library,
 then you don't have to supply the source code, but then you are shipping
 a binary that doesn't work unless they also download the LGPL library
 separately.

 It all adds up to "not going to be in druntime/Phobos" :)

 -Steve


 Actually, if you haven't made any changes to the LGPL library that you  
 are distribution then you can just refer to the projects homepage for  
 the source code.

 This also means that putting the list of URLs for the used LGPL  
 libraries in the Phobos packages would suffice. Can't get much easier  
 than that.


But why require it just for using the language?  If I use a language, I  
want complete control over my license.  I do not want to be forced into  
printing/including anything.  If I want to use a LGPL'd library, then that  
should be my choice.  Putting it in Phobos takes away the choice.

-Steve
Apr 12 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.04.2011 19:05, schrieb Russel Winder:

 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 
 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form.  From a distribution perspective these are very
 different things.  cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.
 
 [ . . . ]


The thing is: when someone develops a D application he would have to
ship a README with it that states "contains a LGPLed library, you can
get its source at blah.org".

For more or less the same reason BSD-licensed code (like from Tango)
isn't allowed in Phobos: Everybody shipping a D application would have
to write "Contains BSD licensed Code from the Blah project" in a README
that is distributed with the application (or into some Help->about box
or whatever).

Walter thinks (and I agree) that programs using the standard library of
a programming language shouldn't need to contain any copyright-notes or
similar because of license restrictions in the language or its standard
library.

Cheers,
- Daniel
Apr 11 2011
next sibling parent Jonas Drewsen <jdrewsen nospam.com> writes:
On 12/04/11 03.45, Daniel Gibson wrote:

 Am 11.04.2011 19:05, schrieb Russel Winder:

 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form.  From a distribution perspective these are very
 different things.  cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.

 [ . . . ]


 The thing is: when someone develops a D application he would have to
 ship a README with it that states "contains a LGPLed library, you can
 get its source at blah.org".

 For more or less the same reason BSD-licensed code (like from Tango)
 isn't allowed in Phobos: Everybody shipping a D application would have
 to write "Contains BSD licensed Code from the Blah project" in a README
 that is distributed with the application (or into some Help->about box
 or whatever).

 Walter thinks (and I agree) that programs using the standard library of
 a programming language shouldn't need to contain any copyright-notes or
 similar because of license restrictions in the language or its standard
 library.

 Cheers,
 - Daniel


OK. So it is an executive decision. Very nice to know and fine with me.

/Jonas
Apr 12 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-12 03:45, Daniel Gibson wrote:

 Am 11.04.2011 19:05, schrieb Russel Winder:

 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form.  From a distribution perspective these are very
 different things.  cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.

 [ . . . ]


 The thing is: when someone develops a D application he would have to
 ship a README with it that states "contains a LGPLed library, you can
 get its source at blah.org".

 For more or less the same reason BSD-licensed code (like from Tango)
 isn't allowed in Phobos: Everybody shipping a D application would have
 to write "Contains BSD licensed Code from the Blah project" in a README
 that is distributed with the application (or into some Help->about box
 or whatever).

 Walter thinks (and I agree) that programs using the standard library of
 a programming language shouldn't need to contain any copyright-notes or
 similar because of license restrictions in the language or its standard
 library.

 Cheers,
 - Daniel


If Phobos dynamically link to a LGPL licensed library and doesn't 
distrbute it, Phobos doesn't have to include a README file like that.

-- 
/Jacob Carlborg
Apr 12 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 10:43, schrieb Jacob Carlborg:

 On 2011-04-12 03:45, Daniel Gibson wrote:

 Am 11.04.2011 19:05, schrieb Russel Winder:

 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form.  From a distribution perspective these are very
 different things.  cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.

 [ . . . ]


 The thing is: when someone develops a D application he would have to
 ship a README with it that states "contains a LGPLed library, you can
 get its source at blah.org".

 For more or less the same reason BSD-licensed code (like from Tango)
 isn't allowed in Phobos: Everybody shipping a D application would have
 to write "Contains BSD licensed Code from the Blah project" in a README
 that is distributed with the application (or into some Help->about box
 or whatever).

 Walter thinks (and I agree) that programs using the standard library of
 a programming language shouldn't need to contain any copyright-notes or
 similar because of license restrictions in the language or its standard
 library.

 Cheers,
 - Daniel


 
 If Phobos dynamically link to a LGPL licensed library and doesn't
 distrbute it, Phobos doesn't have to include a README file like that.
 


Yeah but that's against the idea of Phobos being self-contained.
Apr 12 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 10:43 AM, Jacob Carlborg wrote:

 On 2011-04-12 03:45, Daniel Gibson wrote:

 Am 11.04.2011 19:05, schrieb Russel Winder:

 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form. From a distribution perspective these are very
 different things. cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.

 [ . . . ]


 The thing is: when someone develops a D application he would have to
 ship a README with it that states "contains a LGPLed library, you can
 get its source at blah.org".

 For more or less the same reason BSD-licensed code (like from Tango)
 isn't allowed in Phobos: Everybody shipping a D application would have
 to write "Contains BSD licensed Code from the Blah project" in a README
 that is distributed with the application (or into some Help->about box
 or whatever).

 Walter thinks (and I agree) that programs using the standard library of
 a programming language shouldn't need to contain any copyright-notes or
 similar because of license restrictions in the language or its standard
 library.

 Cheers,
 - Daniel


 If Phobos dynamically link to a LGPL licensed library and doesn't distrbute it,
 Phobos doesn't have to include a README file like that.


Why care about the that readme file? Guess all software I have ever used under 
linux have such readmes. Who cares?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 14:49, schrieb spir:

 On 04/12/2011 10:43 AM, Jacob Carlborg wrote:

 On 2011-04-12 03:45, Daniel Gibson wrote:

 Am 11.04.2011 19:05, schrieb Russel Winder:

 On Mon, 2011-04-11 at 15:39 +0000, Adam D. Ruppe wrote:
 [ . . . ]

 fine, but a standard library is distributed with D programs. LGPL
 requires you to send source when distributing the library.


 I would have to check but as far as I remember the (L)GPL does not
 require you to distribute the source with the compiled form if that is
 what is distributed, it requires that the end user can get the source
 for the compiled form. From a distribution perspective these are very
 different things. cf. The Maven Repository, which distributes masses of
 compiled jar files and no source in sight.

 [ . . . ]


 The thing is: when someone develops a D application he would have to
 ship a README with it that states "contains a LGPLed library, you can
 get its source at blah.org".

 For more or less the same reason BSD-licensed code (like from Tango)
 isn't allowed in Phobos: Everybody shipping a D application would have
 to write "Contains BSD licensed Code from the Blah project" in a README
 that is distributed with the application (or into some Help->about box
 or whatever).

 Walter thinks (and I agree) that programs using the standard library of
 a programming language shouldn't need to contain any copyright-notes or
 similar because of license restrictions in the language or its standard
 library.

 Cheers,
 - Daniel


 If Phobos dynamically link to a LGPL licensed library and doesn't
 distrbute it,
 Phobos doesn't have to include a README file like that.


 
 Why care about the that readme file? Guess all software I have ever used
 under linux have such readmes. Who cares?
 
 Denis


D is not a Linux/FOSS-only language, but also to be used on Windows and
for proprietary software. And especially for Windows it's common to
distribute software (especially freeware and shareware ) just as the
self-contained binary.
Also people using D have to know that they'll have to include this
readme - and this alone is deterrent. "What, I can't distribute my D
programs how I want but have to ship this license stuff with it? This


Cheers,
- Daniel
Apr 12 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 03:02 PM, Daniel Gibson wrote:

 D is not a Linux/FOSS-only language, but also to be used on Windows and
 for proprietary software. And especially for Windows it's common to
 distribute software (especially freeware and shareware ) just as the
 self-contained binary.


Windows apps have a menu entry just perfect for that kind of attribution stuff; 
used to be called "about".

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 12 Apr 2011 09:46:24 -0400, spir <denis.spir gmail.com> wrote:


 On 04/12/2011 03:02 PM, Daniel Gibson wrote:

 D is not a Linux/FOSS-only language, but also to be used on Windows and
 for proprietary software. And especially for Windows it's common to
 distribute software (especially freeware and shareware ) just as the
 self-contained binary.


 Windows apps have a menu entry just perfect for that kind of attribution  
 stuff; used to be called "about".


Any requirements placed on the end user are unacceptable.  D is not meant  
to be egotistical.  It does not need attribution.  The less restrictions  
we enforce on the users of D, the more people will be willing to use it.

I personally think the Boost license is perfect for D -- gives rights to  
the authors when the source is distributed so we don't have any question  
as to who wrote things, and gives full control to the end user when he  
just wants to build a product.

-Steve
Apr 12 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Kagamin Wrote:


 spir Wrote:
 

 There is a point I don't understand: if I'm right, LGPL as well as all other 
 "open source", not strictly free-software, licenses allow using licensed 
 software even for "privative" (proprietary) work. But they wouldn't allow
using 
 software for work licensed under other open-source licenses like the Boost
license?
 Where's the bug?


 
 They can be used, but they can't become proprietary or Boost licensed.


I also wander, what people plan to do with libmysql? It's GPL.
Apr 11 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.04.2011 17:40, schrieb Kagamin:

 Kagamin Wrote:
 

 spir Wrote:


 There is a point I don't understand: if I'm right, LGPL as well as all other 
 "open source", not strictly free-software, licenses allow using licensed 
 software even for "privative" (proprietary) work. But they wouldn't allow
using 
 software for work licensed under other open-source licenses like the Boost
license?
 Where's the bug?


 They can be used, but they can't become proprietary or Boost licensed.


 
 I also wander, what people plan to do with libmysql? It's GPL.


Doesn't mysql even have some retarded restriction like "it's GPL but may
not be used for commercial purposes so buy mysql if you wanna use it to
make money"?

Maybe someone has already reimplemented a mysql-client under a more free
license?

Also: I think most databases (and their libs) are under a license that
is not free enough for Phobos (SQLite is an exception - it's Public
domain - and thus can and should be shipped with Phobos).
So I guess Phobos' DB support should be written in a way that allows
plugging in a DB driver that is distributed independently and under a
different license (this makes sense anyway, because maintaining drivers
for dozens of databases in Phobos is too much work). Maybe we'd need
proper DLL support for that?
This model is used by ODBC and JDBC as well.

Cheers,
- Daniel
Apr 11 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:io0blg$jsc$5 digitalmars.com...

 Am 11.04.2011 17:40, schrieb Kagamin:

 Kagamin Wrote:


 spir Wrote:


 There is a point I don't understand: if I'm right, LGPL as well as all 
 other
 "open source", not strictly free-software, licenses allow using 
 licensed
 software even for "privative" (proprietary) work. But they wouldn't 
 allow using
 software for work licensed under other open-source licenses like the 
 Boost license?
 Where's the bug?


 They can be used, but they can't become proprietary or Boost licensed.


 I also wander, what people plan to do with libmysql? It's GPL.


 Doesn't mysql even have some retarded restriction like "it's GPL but may
 not be used for commercial purposes so buy mysql if you wanna use it to
 make money"?

 Maybe someone has already reimplemented a mysql-client under a more free
 license?


PostgreSQL? ;)
Apr 11 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 04:00, schrieb Nick Sabalausky:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:io0blg$jsc$5 digitalmars.com...

 Am 11.04.2011 17:40, schrieb Kagamin:

 Kagamin Wrote:


 spir Wrote:


 There is a point I don't understand: if I'm right, LGPL as well as all 
 other
 "open source", not strictly free-software, licenses allow using 
 licensed
 software even for "privative" (proprietary) work. But they wouldn't 
 allow using
 software for work licensed under other open-source licenses like the 
 Boost license?
 Where's the bug?


 They can be used, but they can't become proprietary or Boost licensed.


 I also wander, what people plan to do with libmysql? It's GPL.


 Doesn't mysql even have some retarded restriction like "it's GPL but may
 not be used for commercial purposes so buy mysql if you wanna use it to
 make money"?

 Maybe someone has already reimplemented a mysql-client under a more free
 license?


 
 PostgreSQL? ;)
 
 


Well I'd always use PostgreSQL instead of MySQL when having the choice, but
1. often MySQL needs to be used because it's already there
2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos.

BTW: I think PHP has a native SQL driver (under their BSD-style PHP
license) - maybe that could be adapted to be used with D, if it's
written in C. This still couldn't be shipped with Phobos, but at least
there are no stupid restrictions on using it for commercial software.
Apr 11 2011
parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 04:06 AM, Daniel Gibson wrote:

 Well I'd always use PostgreSQL instead of MySQL when having the choice, but
 1. often MySQL needs to be used because it's already there
 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos.

 BTW: I think PHP has a native SQL driver (under their BSD-style PHP
 license) - maybe that could be adapted to be used with D, if it's
 written in C. This still couldn't be shipped with Phobos, but at least
 there are no stupid restrictions on using it for commercial software.


I don't understand this story of shipping, neither. It seems to me D's style 
rather pushes to reuse libs (esp written in C), that users (both programmer & 
end-user) are forced to install anyway. Licenses that allow reuse (and 
shipping) provided a copyright note is properly inserted do not change anything 
for me.

Instead, I find this copyright note, not only *extremely* light, but also fair, 
and even nice. In my views, people who do not agree with that are the kinds who 
want to freely take from a community and give nothing back in exchange (rather 
corporations in fact); not even attribute their work to authors. Bad and sad :-(

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 11:34, schrieb spir:

 On 04/12/2011 04:06 AM, Daniel Gibson wrote:

 Well I'd always use PostgreSQL instead of MySQL when having the
 choice, but
 1. often MySQL needs to be used because it's already there
 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos.

 BTW: I think PHP has a native SQL driver (under their BSD-style PHP
 license) - maybe that could be adapted to be used with D, if it's
 written in C. This still couldn't be shipped with Phobos, but at least
 there are no stupid restrictions on using it for commercial software.


 
 I don't understand this story of shipping, neither. It seems to me D's
 style rather pushes to reuse libs (esp written in C), that users (both
 programmer & end-user) are forced to install anyway. Licenses that allow
 reuse (and shipping) provided a copyright note is properly inserted do
 not change anything for me.
 
 Instead, I find this copyright note, not only *extremely* light, but
 also fair, and even nice. In my views, people who do not agree with that
 are the kinds who want to freely take from a community and give nothing
 back in exchange (rather corporations in fact); not even attribute their
 work to authors. Bad and sad :-(
 
 Denis


Yeah this is all fine when you use a third-party lib, but IMHO for a
standard-lib of a language such a copyright-note shouldn't be necessary.
It's not like you have to know that phobos uses zlib, for example.
Sure it's nice if you add to your README "I used the D programming
language and it's standardlib Phobos, which includes the zlib I used for
compression and SQLite for simple database stuff to create this", but it
shouldn't be necessary.
Apr 12 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 04/12/2011 11:55 AM, Daniel Gibson wrote:

 Am 12.04.2011 11:34, schrieb spir:

 On 04/12/2011 04:06 AM, Daniel Gibson wrote:

 Well I'd always use PostgreSQL instead of MySQL when having the
 choice, but
 1. often MySQL needs to be used because it's already there
 2. PostgreSQL uses the BSD-License which also isn't suitable for Phobos.

 BTW: I think PHP has a native SQL driver (under their BSD-style PHP
 license) - maybe that could be adapted to be used with D, if it's
 written in C. This still couldn't be shipped with Phobos, but at least
 there are no stupid restrictions on using it for commercial software.


 I don't understand this story of shipping, neither. It seems to me D's
 style rather pushes to reuse libs (esp written in C), that users (both
 programmer&  end-user) are forced to install anyway. Licenses that allow
 reuse (and shipping) provided a copyright note is properly inserted do
 not change anything for me.

 Instead, I find this copyright note, not only *extremely* light, but
 also fair, and even nice. In my views, people who do not agree with that
 are the kinds who want to freely take from a community and give nothing
 back in exchange (rather corporations in fact); not even attribute their
 work to authors. Bad and sad :-(

 Denis


 Yeah this is all fine when you use a third-party lib, but IMHO for a
 standard-lib of a language such a copyright-note shouldn't be necessary.
 It's not like you have to know that phobos uses zlib, for example.
 Sure it's nice if you add to your README "I used the D programming
 language and it's standardlib Phobos, which includes the zlib I used for
 compression and SQLite for simple database stuff to create this", but it
 shouldn't be necessary.


Right, I now understand the point. But still find it an extremely light 
constraint: just put an "attributions.txt" into your package. Compare this 
constraint eg with makefile issues ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
For my personal libs/programs I fully agree with spir:

1) attribution is a very light burden
2) it is nice, and somehow the right thing to do
3) it gives back at least a bit of advertisement to the stuff *you can  
use freely*

For those reasons I did release blip with an apache 2.0 license, by  
using it I can also easily integrate/use all kinds of free libraries,
but it stays free, and usable also in commercial contexts.

That said I think that having phobos using the Boost license, aside  
form "being nice for the user" it other subtle effects:
yes it makes "standing on the shoulders of giants" more difficult,  
because you cannot as easily use other libraries,
but exactly for that reason it forces one to rebuild things from  
scratch (or almost).
For a *base* library, this is not necessarily a bad thing, it reduces  
dependencies, and might even give code that is more optimized.

I think that there is space in D for other libraries, libraries that  
use licenses like apache 2.0 or BSD.
Still I understand that the base library is boost licensed, it might  
not be my first choice for my own projects (I don't want to always
develop everything from scratch), but it is a clear choice, and a  
choice that has its own merits.

Fawzi

On 12-apr-11, at 15:34, spir wrote:


 On 04/12/2011 11:55 AM, Daniel Gibson wrote:

 Am 12.04.2011 11:34, schrieb spir:

 On 04/12/2011 04:06 AM, Daniel Gibson wrote:

 Well I'd always use PostgreSQL instead of MySQL when having the
 choice, but
 1. often MySQL needs to be used because it's already there
 2. PostgreSQL uses the BSD-License which also isn't suitable for  
 Phobos.

 BTW: I think PHP has a native SQL driver (under their BSD-style PHP
 license) - maybe that could be adapted to be used with D, if it's
 written in C. This still couldn't be shipped with Phobos, but at  
 least
 there are no stupid restrictions on using it for commercial  
 software.


 I don't understand this story of shipping, neither. It seems to me  
 D's
 style rather pushes to reuse libs (esp written in C), that users  
 (both
 programmer&  end-user) are forced to install anyway. Licenses that  
 allow
 reuse (and shipping) provided a copyright note is properly  
 inserted do
 not change anything for me.

 Instead, I find this copyright note, not only *extremely* light, but
 also fair, and even nice. In my views, people who do not agree  
 with that
 are the kinds who want to freely take from a community and give  
 nothing
 back in exchange (rather corporations in fact); not even attribute  
 their
 work to authors. Bad and sad :-(

 Denis


 Yeah this is all fine when you use a third-party lib, but IMHO for a
 standard-lib of a language such a copyright-note shouldn't be  
 necessary.
 It's not like you have to know that phobos uses zlib, for example.
 Sure it's nice if you add to your README "I used the D programming
 language and it's standardlib Phobos, which includes the zlib I  
 used for
 compression and SQLite for simple database stuff to create this",  
 but it
 shouldn't be necessary.


 Right, I now understand the point. But still find it an extremely  
 light constraint: just put an "attributions.txt" into your package.  
 Compare this constraint eg with makefile issues ;-)

 Denis
 -- 
 _________________
 vita es estrany
 spir.wikidot.com
Apr 12 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 04/12/2011 04:01 PM, Fawzi Mohamed wrote:

 For my personal libs/programs I fully agree with spir:

 1) attribution is a very light burden
 2) it is nice, and somehow the right thing to do
 3) it gives back at least a bit of advertisement to the stuff *you can use
freely*

 For those reasons I did release blip with an apache 2.0 license, by using it I
 can also easily integrate/use all kinds of free libraries,
 but it stays free, and usable also in commercial contexts.

 That said I think that having phobos using the Boost license, aside form "being
 nice for the user" it other subtle effects:
 yes it makes "standing on the shoulders of giants" more difficult, because you
 cannot as easily use other libraries,
 but exactly for that reason it forces one to rebuild things from scratch (or
 almost).
 For a *base* library, this is not necessarily a bad thing, it reduces
 dependencies, and might even give code that is more optimized.

 I think that there is space in D for other libraries, libraries that use
 licenses like apache 2.0 or BSD.
 Still I understand that the base library is boost licensed, it might not be my
 first choice for my own projects (I don't want to always
 develop everything from scratch), but it is a clear choice, and a choice that
 has its own merits.


Thanks to everyone, I know understand the point and the choice made for D, or 
rather Phobos. I still do not share the underlying opinion and would not do do 
that choice myself (find properly crediting someone for their work just a Good 
Thing, and no burden at all).
But at least, as Fawzi says, it's a clear choice; and I would not mind 
licensing under Boost potential contributions to Phobos.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 4/11/2011 9:55 PM, Daniel Gibson wrote:

 Doesn't mysql even have some retarded restriction like "it's GPL but may
 not be used for commercial purposes so buy mysql if you wanna use it to
 make money"?


According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual 
licensed GPL or proprietary.  (Actually it's a slightly modified GPL 
that's **less** restrictive than the vanilla one.)
Apr 11 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.04.2011 04:18, schrieb dsimcha:

 On 4/11/2011 9:55 PM, Daniel Gibson wrote:

 Doesn't mysql even have some retarded restriction like "it's GPL but may
 not be used for commercial purposes so buy mysql if you wanna use it to
 make money"?


 
 According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual
 licensed GPL or proprietary.  (Actually it's a slightly modified GPL
 that's **less** restrictive than the vanilla one.)


Hmm.. seems like I've mixed up stuff, I only got my information via hearsay.

However I've looked it up: You can only use MySQL with closed source
software, when you buy a license. Even if you don't touch MySQL's code
itself, because the client library is also under GPL.
I *think* this could be fixed by a custom client library under another
license because then you wouldn't use or link any of MySQLs source but
just communicate with it via TCP or something.

MySQL's license is a bit less restrictive than the GPL, because you may
link it with *any* source using an OSI-Approved (Open Source) license
and not just GPL. That doesn't help with proprietary software, though.

See also: http://www.mysql.com/about/legal/licensing/index.html

Cheers,
- Daniel
Apr 11 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 04/12/2011 04:18 AM, dsimcha wrote:

 On 4/11/2011 9:55 PM, Daniel Gibson wrote:

 Doesn't mysql even have some retarded restriction like "it's GPL but may
 not be used for commercial purposes so buy mysql if you wanna use it to
 make money"?


 According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual licensed
 GPL or proprietary. (Actually it's a slightly modified GPL that's **less**
 restrictive than the vanilla one.)


There is a misconseption (or rather rethorical playing on words) in the 
open-source argumentation versus free software: a license like BSD is said to 
be less restrictive. But in fact it is more privative to (end-)users, in that 
it allows direct users of the software to deprive them from rights that would 
have been guaranted by a free software license.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.3427.1302601308.4748.digitalmars-d puremagic.com...

 On 04/12/2011 04:18 AM, dsimcha wrote:

 On 4/11/2011 9:55 PM, Daniel Gibson wrote:

 Doesn't mysql even have some retarded restriction like "it's GPL but may
 not be used for commercial purposes so buy mysql if you wanna use it to
 make money"?


 According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual 
 licensed
 GPL or proprietary. (Actually it's a slightly modified GPL that's 
 **less**
 restrictive than the vanilla one.)


 There is a misconseption (or rather rethorical playing on words) in the 
 open-source argumentation versus free software: a license like BSD is said 
 to be less restrictive. But in fact it is more privative to (end-)users, 
 in that it allows direct users of the software to deprive them from rights 
 that would have been guaranted by a free software license.


Except such software is more likely to have just simply used some other 
library instead, something either more BSD-like or in-house proprietary. In 
other words, in actual practice, (L)GPL tends to discoruage people from 
actually making derivative works. So that still works against users gaining 
benefit from the software anyway.
Apr 12 2011
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
spir wrote:

 On 04/12/2011 04:18 AM, dsimcha wrote:

 On 4/11/2011 9:55 PM, Daniel Gibson wrote:

 Doesn't mysql even have some retarded restriction like "it's GPL but =






may

 not be used for commercial purposes so buy mysql if you wanna use it =






to

 make money"?


 According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual
 licensed
 GPL or proprietary. (Actually it's a slightly modified GPL that's
 **less**
 restrictive than the vanilla one.)


=20
 There is a misconseption (or rather rethorical playing on words) in the=



 open-source argumentation versus free software: a license like BSD is
 said to be less restrictive. But in fact it is more privative to
 (end-)users, in that it allows direct users of the software to deprive
 them from rights that would have been guaranted by a free software lice=


nse.

=20


	OTOH, the GPL is a lot more restrictive for direct users since it
deprives them of the right to license *their own* code any way they
want (at least, LGPL does not have that restriction).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 12 2011
parent spir <denis.spir gmail.com> writes:
On 04/12/2011 08:19 PM, "Jérôme M. Berger" wrote:

 spir wrote:

 On 04/12/2011 04:18 AM, dsimcha wrote:

 On 4/11/2011 9:55 PM, Daniel Gibson wrote:

 Doesn't mysql even have some retarded restriction like "it's GPL but may
 not be used for commercial purposes so buy mysql if you wanna use it to
 make money"?


 According to Wikipedia (http://en.wikipedia.org/wiki/Mysql) it's dual
 licensed
 GPL or proprietary. (Actually it's a slightly modified GPL that's
 **less**
 restrictive than the vanilla one.)


 There is a misconseption (or rather rethorical playing on words) in the
 open-source argumentation versus free software: a license like BSD is
 said to be less restrictive. But in fact it is more privative to
 (end-)users, in that it allows direct users of the software to deprive
 them from rights that would have been guaranted by a free software license.


 	OTOH, the GPL is a lot more restrictive for direct users since it
 deprives them of the right to license *their own* code any way they
 want (at least, LGPL does not have that restriction).

 		Jerome


True.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 12 2011
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Kagamin wrote:

 Kagamin Wrote:


 spir Wrote:


 There is a point I don't understand: if I'm right, LGPL as well as all other
 "open source", not strictly free-software, licenses allow using licensed
 software even for "privative" (proprietary) work. But they wouldn't allow using
 software for work licensed under other open-source licenses like the Boost
license?
 Where's the bug?


 They can be used, but they can't become proprietary or Boost licensed.


 I also wander, what people plan to do with libmysql? It's GPL.


There's a FOSS license exception for MySQL client library:
http://www.mysql.com/about/legal/licensing/foss-exception/

Boost license is not on the list, but we may ask them to include it.

Anyway, I'm writing my PostgreSQL client without using libpq: 
http://github.com/pszturmaj/ddb

It's licensed under Boost 1.0 so it could be included into Phobos. I 
planned to write MySQL client without using client lib as well. However 
I'm not sure about stability of their protocol (in contrast to 
PostgreSQL's):

http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol
Apr 12 2011
next sibling parent Kagamin <spam here.lot> writes:
Piotr Szturmaj Wrote:


 I also wander, what people plan to do with libmysql? It's GPL.


 
 There's a FOSS license exception for MySQL client library:
 http://www.mysql.com/about/legal/licensing/foss-exception/
 
 Boost license is not on the list, but we may ask them to include it.


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


 http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol


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

 Piotr Szturmaj Wrote:


 http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol


 LOL, take a look at this:
 http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocol&diff=5078&oldid=4374


That's ridiculous. I've just googled for "The MySQL Protocol is 
proprietary" and I've got this:

http://krow.livejournal.com/684068.html

Also take a look at comments... I fully agree with this one:

"MySQL's position on the protocol issue is pure, unadulterated BS. It is 
legal to reverse engineer protocols and file formats without the 
permission of the originator. See Open Office and Samba for two 
particularly widely known examples of this."
Apr 12 2011
prev sibling parent Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 The whole thing's just a damn mess. 
 I've always found it best to just avoid any (L)GPL source or library 
 outright. Not worth the trouble.


GPL is pretty simple: write GPL soft and there will be no problem.
Apr 12 2011
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
I spent a little more time on it and implemented simple PNG writing
from the lines range and fixed a few bugs.

What I really want to see with the ranges is things like using
std.algorithm to make an image diff in just a few lines, and also
being able to use image functions as generic algorithms; they should
be fairly interchangeable.

While that's still a long way off (if we'll ever get there), the
range approach can do some pretty cool things. Check this out:

(first get the new file: http://arsdnet.net/dcode/imagedraft.d )

===

import imagedraft;
import std.stdio;
import std.random;

// Why the hell isn't something like this in Phobos?
struct BinaryFileWriter {
	File f;
	this(string filename) {
		f = File(filename, "wb");
	}

	void put(in ubyte[] data) {
		f.rawWrite(data);
	}
}

// This is a little range to create an image on the fly
struct StaticGenerator {
	int width;
	int height;
	int linesLeft;
	this(int width, int height) {
		this.width = width;
		this.height = height;
		linesLeft = height;
		assert(linesLeft);
	}

	bool empty() {
		return !(linesLeft > 0);
	}

        // required by writePng
	int length() {
		return height;
	}

	void popFront() {
		assert(linesLeft);
		linesLeft--;
	}

	RgbaScanline front() {
		assert(linesLeft);
		RgbaScanline line;
		line.pixels.length = width;
		foreach(ref pixel; line.pixels) {
			ubyte val = cast(ubyte) uniform(0, 255);
			pixel = Color(val, val, val, 255);
		}

		return line;
	}
}

void main(string[] args) {
    // writePng takes an output range and an input range. The
    // output range should accept the ubyte[]s it generates.
    // The input range needs to provide length and it's front
    // should be some RgbaScanlines
    writePng(
        BinaryFileWriter("static.png"),
        StaticGenerator(512, 512));
}

===

Nothing particularly great, yet, but it's slowly becoming something
useful.

I also improved the convertToGreyscale function so the results
don't suck as much, making it a fun little function to play with
too.


========

On a completely unrelated note, I've written basic .wav and fairly
decent .mid file functions too. The .wav can read and write
simple files to an array and add some simple sounds to it (square
wave, etc. I generated my phone's ringtone with a little D program!)
Wav is kinda buggy, but I'm sure if I spent a couple hours on it,
it'd be whipped into shape.

And the .mid functions read them into a series of events, can write
back out, and can also play the files on Windows and Linux*,
including injecting events as they play.

* Linux midi support sucks and requires a lot of code and user
setup... but if you have a working ALSA rig, the program will drive
it.


Just since I'm talking about file formats, if there's any interest,
I can see about cleaning these up too for simple sound support in
the library.
Apr 10 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/10/2011 5:10 PM, Adam D. Ruppe wrote:

 But, you can see one of the big ideas: providing ranges on images
 of various formats that present the data to you in a requested
 standard format (any PNG image is lazily converted to an rgba list
 of lines here).


I don't know much about graphics, but your approach sounds awesome.
Apr 10 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Walter Bright wrote:

 I don't know much about graphics [...]


The irony is neither do I! But, an algorithm is an algorithm
so I'm hoping if it can work well for the few I know, we'll have
an approach that can work for others too, all written independently.
Apr 11 2011
parent spir <denis.spir gmail.com> writes:
On 04/11/2011 06:09 PM, Adam D. Ruppe wrote:

 Walter Bright wrote:

 I don't know much about graphics [...]


 The irony is neither do I! But, an algorithm is an algorithm
 so I'm hoping if it can work well for the few I know, we'll have
 an approach that can work for others too, all written independently.


Yes, that's definitely the great thing about generics, IMO.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 11 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/11/2011 02:10 AM, Adam D. Ruppe wrote:

 I'm pretty happy with how simpledisplay.d is turning out, and want to
 spend some time thinking about the client side images now.

 I think a nice way to do it would be to go with ranges and templates,
 like std.algorithm, so things will work across many different image
 formats with the best efficiency and minimal coupling. But, we need to
 think about some specifics before going too far.

 Here's a first draft module to show the idea while doing some useful
 work. It's dependency free so you can download and play with ease.

 http://arsdnet.net/dcode/imagedraft.d


 If you also grab simpledisplay.d
 http://arsdnet.net/dcode/simpledisplay.d

 You can compile this little png display program:

 =======
 import imagedraft;
 import std.stdio;

 import simpledisplay;

 void main(string[] args) {
 	auto png = pngFromBytes(File(args[1]).byChunk(4096));
 	auto image = new Image(png.header.width, png.header.height);

 	int y;
 	foreach(line; png.byRgbaScanline) {
 		foreach(x, color; line.pixels)
 			image.putPixel(cast(int) x, cast(int) y,
 				simpledisplay.Color(color.r, color.g, color.b, color.a));
 		y++;
 	}

 	displayImage(image);
 }
 ====

 And use it as a base to play around and see your algorithm's results
 right in the window. (btw, that displayImage() function is what used
 to be image.display() in simpledisplay. A standalone function will
 let me separate dependencies better. It works the same way - just
 show it and wait for the user to hit any key to continue.)


Works fine by me :-) Thank you very much again for this nice job.
I intend to do some trials with simpledisplay. This could also provide for a 
few unittests. Are you interested in that?


 The foreach there is ugly. I was going to write up a demo
 of some actual algorithms for images, but I ended up spending
 most the day getting my BufferedInputRange and LazyPngFile to
 work correctly...

 But, you can see one of the big ideas: providing ranges on images
 of various formats that present the data to you in a requested
 standard format (any PNG image is lazily converted to an rgba list
 of lines here).

 It also shows how I plan to write other image format loaders - they
 take arbitrary input ranges, and lazily load and decode the file.
 (While I had a png loader before, it was in C style.... I'm hoping
 that it will be easier to port my bmp code now that I have a working
 foundation...)

 I'll write an image saver too. It will take an rgbaScanLine range
 and save it to the correct format - png, bmp, whatever.


What is the advantage of laziness here (both for input and output)? One needs 
to compute the while pic anyway... Actually simple ranges (aven simple arrays?) 
would do the job as well, wouldn't they?


 Now, back to the main idea here. I wish I had more time. If I fleshed
 out this existing range a little more, we could do fun things
 like call std.algorithm.levenshteinDistance on it.. but right now,
 it's just an input range, which is fairly limited. I figure the
 best thing to do is offer whatever facilities the source range offers,
 so if you give it an array, you can save(), back(), etc. too.

 Still, we can run a few functions on it.

   foreach(line; filter!"a.pixels[0].r>  200"(png.byRgbaScanline)) {
   }

 Only keeps lines with a lot of red in the first pixel.

 So that's pretty cool.



 Aaaanyway, I want to have a bunch of algorithms written in here that
 can work on these ranges, capable of doing both in-place and lazy
 changes to your image.

 Since I messed up the time, I only wrote one (and it sucks, hard),
 but it's the idea I have in mind: the convertToGreyscale function.
 Any image that provides a range it can use will work for it.



 What kind of ranges would be useful? A by line surely is, which
 is why I started with it. A byPixel perhaps?


Surely: this allows running complicated algorithm on the proper level of 
abstraction (the pixel=point). For instance, I'd like a fill(shape,fillColor) 
function working for any (closed) shape defined as a set of pixels of a given 
color. (Not trivial, by the way, for arbitrary convex shapes, as you probably 
know.)


  Maybe a byBlock? Though,
 it for byPixel, it seems like opApply is the way to do it. Maybe it
 can even shove it off to the GPU to do the work. That's beyond my
 knowledge, but David Simcha has done some cool stuff with foreach
 and parallelism, and this is basically the same concept, so I'm
 sure it can be done.

 Then, of course, you'll surely still want opIndex into the pixels
 too.


Yop, i think it's the right level. "Total slice" [] could return, as default 
range, a range of pixels.


 I was hoping to have time to write a gaussian blur function to put
 the idea to the test...


 The other thing is drawing. I don't think ranges will help much there.
 Drawing algorithms will probably be ok with opIndexAssign into the
 pixels.


Yop as well.


 But, it's time for me to get to the work I was supposed to do today.
 If nothing else, hopefully that PNG loader in there will be useful,
 but I really do think there's a lot of potential in the idea of
 a std.algorithm for images and would like any input you have.

 Thanks for all the feedback this weekend, everyone!


Thanks to you!

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 11 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
spir wrote:

 I intend to do some trials with simpledisplay. This could also
 provide for a few unittests. Are you interested in that?


Yeah, sounds good.


 What is the advantage of laziness here (both for input and output)?
 One needs to compute the while pic anyway... Actually simple ranges
(aven simple arrays?) would do the job as well, wouldn't they?


The main reason I went this way was to be like the rest of Phobos.
Why does Phobos use laziness so much?

One big reason is you can always go from lazy to eager, but not
the other way around. Just call array() on it.

Lazy computations can also save on a lot of memory if you don't
need the whole thing at once, especially if it's very large.
One situation this might be useful is working with video. Hopefully,
the lazy algorithms for images will be reusable for a streaming
video too. My StaticGenerator there could do any size without
taking more than the memory needed for a single line.

Finally, there might be a small speed boost, since it lets you
mix CPU and disk operations together - load part of the file, then
process it while the next part is still coming off the disk, instead
of having the processor sit idle while waiting for it to load. It
could also cut down on memory allocations by reusing buffers
too. (My implementation doesn't realize this very well, but it
could be done in theory. However, a part of me isn't sure it's
a great idea... mutable buffers in std.stdio.File wasted some
time yesterday because I forgot to copy them... but still, it's
possible to do more this way.)


 For instance, I'd like a fill(shape,fillColor) function working
 for any (closed) shape


Yes, indeed.
Apr 11 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:intgu2$1bhj$1 digitalmars.com...

 I'm pretty happy with how simpledisplay.d is turning out, and want to
 spend some time thinking about the client side images now.

 I think a nice way to do it would be to go with ranges and templates,
 like std.algorithm, so things will work across many different image
 formats with the best efficiency and minimal coupling. But, we need to
 think about some specifics before going too far.

 Here's a first draft module to show the idea while doing some useful
 work. It's dependency free so you can download and play with ease.

 http://arsdnet.net/dcode/imagedraft.d


Boy, I just can't keep up with you!

I'm still in the process tinkering with my version of Color and Image, 
benchmarking it, and article-writing (This turned out to be the perfect 
second example for the contest article I had already been planning to write. 
I'm not actually presenting any of your orignal code though, I didn't think 
that would be appropriate anyway, just using some of my versions of Color 
and Image.)

I'll definitely get around to looking at this new version at some point, 
though! :)
Apr 11 2011