Recommendation for a CL data structures library
RG
looked promising:
http://www.cliki.net/fare-utils
But I couldn't find any documentation for it nor could I
reverse-engineer the API. Anyone had success with this, or
found/written something better?
rg
Nicolas Neuss
Maybe Scott Burson's Fset-library? What do you need precisely?
Nicolas
RG
Nicolas Neuss <last...@kit.edu> wrote:
That looks good. Thanks for the pointer.
> What do you need precisely?
For now just an associative map that's O(logN) for inserts and lookups
on ordered keys. But I figured as long as I was looking I'd fill out my
collection as completely as possible in anticipation of future needs.
rg
Alex Mizrahi
R> For now just an associative map that's O(logN) for inserts and lookups
R> on ordered keys. But I figured as long as I was looking I'd fill out my
R> collection as completely as possible in anticipation of future needs.
I was looking for a sane library which implements binary tree-based
associative container, but wasn't able to find any :(.
There are some tree implementations, but they lack iterators and stuff like
that.
If you're looking for a general data structures library, cl-containers [1]
is supposed to be it, but quality is lacking -- API is not consistent,
documentation is auto-generated (basically, it is a list of functions), some
things just do not work. But, I think, all code is there, it just needs some
cleanup.
Karol Skocik
There is also http://github.com/ks/X.FDATATYPES
It's a port of Clojure's datastructures (w/o the transient stuff added
later).
The docs are missing, but API is described in package.lisp like this:
;; FSET
"FSET" ;; constructor
"FSET-EX" ;; constructor
"COERCE-FSET" ;; converts data type to fset
"FSET-LIST" ;; converts fset to list
"FSET-DIFFERENCE" ;; fset difference
"FSET-EXCLUSIVE-OR";; fset exlusive or
"FSET-UNION" ;; fset union
"ADD-KEY" ;; adds key to fset
"ADD-KEY*" ;; adds more keys to fset
"HAS-KEY" ;; tests if key is in fset
"HAS-KEY*" ;; tests more keys at once
;; FTAB
"FTAB" ;; constructor
"FTAB-EX" ;; constructor
"COERCE-FTAB" ;; converts data type to ftab
"FTAB-ALIST" ;; converts ftab to alist
;; FVEC
"FVEC" ;; constructor
"COERCE-FVEC" ;; converts data type to fvec
"FVEC-LIST" ;; converts fvec to list
"FVEC-VECTOR" ;; converts fvec to vector
"FVEC-IOTA" ;; creates fvec with contents from start to n by step
"UPDATE" ;; replaces value at index (slow but sometimes useful
operation)
"UPDATE*" ;; replaces values at indices in one go (slow but
sometimes useful operation)
"ADD-TAIL" ;; adds value to the end - a LOT faster than add* on
fvec - use this to add stuff to fvec
"ADD-TAIL*" ;; adds more values to the end in one go - a LOT faster
than add* on fvec
"DEL-TAIL" ;; removes element from tail - a LOT faster than del on
fvec
"DEL-TAIL*" ;; removes more values from tail - s LOT faster than
del* on fvec
;; FSET FTAB
"KEYS" ;; returns keys as list
;; FTAB FVEC
"VALS" ;; returns values of container as list
;; *
"SIZE" ;; number of elements/associations in fvec/ftab
"EMPTY" ;; empty predicate
"ADD" ;; adds value with key/index to container (use add-tail for
fvec for efficiency)
"ADD*" ;; adds more key/index value pairs to container (use add-
tail* for fvec for efficiency)
"REF" ;; gets value at key/index, error if not found
"REF*" ;; gets more values at keys/indexes as list, error if not
found
"REF-OPT" ;; gets value at key/index, returns optional if not found
"REF-OPT*" ;; gets more values at keys/indexes as list, returns
optional if not found
"REF-OPT-FN*" ;; gets more values at keys/indexes as list, calls
function if not found
"DEL" ;; removes element from container (use del-tail for fvec for
effeciency if you can)
"DEL*" ;; removes more elements from container in one go (use del-
tail* for fvec for effeciency if you can)
"FMAP" ;; maps function over container, returns new container
"FMAP-TO" ;; maps function over container, returns type supplied as
argument (nil, list, vector, bit-vector, ...)
"FOLD" ;; fold function over container
"FILTER" ;; filter function over container, returns new container
I live in impression that it should be enough to start using it.
RG
"Alex Mizrahi" <udod...@users.sourceforge.net> wrote:
Thanks, will look at that too.
rg
Pascal J. Bourguignon
> ??>> What do you need precisely?
>
> R> For now just an associative map that's O(logN) for inserts and lookups
> R> on ordered keys. But I figured as long as I was looking I'd fill out my
> R> collection as completely as possible in anticipation of future needs.
>
> I was looking for a sane library which implements binary tree-based
> associative container, but wasn't able to find any :(.
> There are some tree implementations, but they lack iterators and stuff
> like that.
What about
http://darcs2.informatimago.com/lisp/common-lisp/llrbtree.lisp
(Left Leaning Red-Black Tree).
It even has a with-tree-iterator macro!
--
__Pascal Bourguignon__
Raffael Cavallaro
> What about
> http://darcs2.informatimago.com/lisp/common-lisp/llrbtree.lisp
> (Left Leaning Red-Black Tree).
> It even has a with-tree-iterator macro!
Maybe you don't realize this Pascal, but even though much of your code
may be quite interesting, no one who currently works on a commercial,
published product, or who contemplates working on a commercial
published product in the future, can take the risk of using your
libraries because they are GPL licensed.
Using them would place their employer or the commercial organization to
which they belong under the obligation of publishing all of the source
code for any released product that included your library. As a result,
most people working on commercial published software, or who
contemplate doing so in the future, simply avoid gpl libraries
altogether.
This is why so many c/c++ libraries are released under the lgpl, not
the gpl. It is also why so many lisp libraries are released under the
llgpl, bsd, apache, or mit style licenses. Your libraries would see
much wider use if they were bsd or apache licensed, for eample.
warmest regards,
Ralph
--
Raffael Cavallaro
Alex Mizrahi
??>> associative container, but wasn't able to find any :(.
??>> There are some tree implementations, but they lack iterators and stuff
??>> like that.
PJB> What about
PJB> http://darcs2.informatimago.com/lisp/common-lisp/llrbtree.lisp
PJB> (Left Leaning Red-Black Tree).
PJB> It even has a with-tree-iterator macro!
Um...
(defun make-iterator (tree &rest args
&key ;; (start nil startp) (end nil endp) ; not yet
from-end)
(defmacro with-tree-iterator ((name tree &rest args
&key ;; start end ; not yet
from-end) &body body)
---
NOTE: The data is collected before iterating, so you can modify the
tree at will during iteration.
---
WTF? You could as well call it tree-to-list.
Traversal of K conse?utive elements of a tree with N elements should be of
O(K + log N) complexity. Otherwise it is not a tree but a poor joke.
Alex Mizrahi
RC> may be quite interesting, no one who currently works on a commercial,
RC> published product, or who contemplates working on a commercial
RC> published product in the future, can take the risk of using your
RC> libraries because they are GPL licensed.
Indeed, good catch!
Pascal J. Bourguignon
writes:
I know.
I worked hard to write it (*), I expect a compensation.
I reclaim as compensation to be able to see the source of any
application using it that I might buy. Is it too high a price?
Notice that the GPL is not contradictory to commercial interests, on the
contrary. In fact, it would be in the best interest of any commercial
endeavour to distribute the sources of their software and firmware under
the GPL license, since otherwise a competitor could patent the core
techniques. Or if the original company patents it itself, then it will
have published it already so no evil would come from giving a copy of
the source along with any product.
Now, perhaps I should explicitely state in each file that commercial
licenses are also available upon request, but I guess that if commercial
entities were interested I would have contacted with me already.
If I ever win big a lottery, or if I ever become a civil "servant", I
may publish my code under BSD or MIT. But until one of these unlikely
events occurs, I will stick to GPL or commercial licensing, with a very
strong favor for the former.
(*) But much less hard than Robert Sedgewick, let's thank HIM for the
really hard work, which americans did by paying his tenure, and the
other peoples of the Earth by supporting (willingly or not) the
american debt. We've already paid for his ideas.
--
__Pascal Bourguignon__
Pascal J. Bourguignon
"Alex Mizrahi" <udod...@users.sourceforge.net> writes:
The problem is in identifying the start element without off-by-one
error. I hadn't time to think about it when I added the iterator, so it
remains a TODO item. But indeed, given the tree keeps the number of
elements near the root, it should be possible to find the path to the
start element in O(log N). (For a full binary tree, it would be trivial).
--
__Pascal Bourguignon__
RG
Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
wrote:
> On 2010-03-19 09:24:34 -0400, Pascal J. Bourguignon said:
>
> > What about
> > http://darcs2.informatimago.com/lisp/common-lisp/llrbtree.lisp
> > (Left Leaning Red-Black Tree).
> > It even has a with-tree-iterator macro!
>
> Maybe you don't realize this Pascal, but even though much of your code
> may be quite interesting, no one who currently works on a commercial,
> published product, or who contemplates working on a commercial
> published product in the future, can take the risk of using your
> libraries because they are GPL licensed.
>
> Using them would place their employer or the commercial organization to
> which they belong under the obligation of publishing all of the source
> code for any released product that included your library. As a result,
> most people working on commercial published software, or who
> contemplate doing so in the future, simply avoid gpl libraries
> altogether.
Publishing code under the GPL does not preclude the copyright holder
from also making the code available under a commercial license. If you
want to use PJB's code in a commercial product why don't you just ask
him for a price quote?
rg
RG
I like it. Clean code. Wicked fast.
> It even has a with-tree-iterator macro!
This I don't like so much because:
The data is collected before iterating, so you can modify the
tree at will during iteration.
Collecting all the data ahead of time is a very high price to pay for
mutability during traversal. But this is a minor nit. llrbtree is more
or less exactly what I was looking for.
Thanks!
rg
Pascal J. Bourguignon
I take note of the popular demand for a better with-tree-iterator :-)
As soon as I have some time to work on it, I'll do. But if you're in a
hurry, better do it yourself and contribute ;-).
--
__Pascal Bourguignon__
RG
Here you go:
(defun make-iterator1 (tree)
(let ((node (tree-root tree)) (stack nil) (state :left))
(labels ((loop ()
(ecase state
(:left (cond ((null (node-left node))
(setf state :right)
(values t (node-key node) (node-value
node)))
(t (push node stack)
(setf node (node-left node))
(loop))))
(:right (cond ((null (node-right node))
(setf state :up)
(loop))
(t (push node stack)
(setf node (node-right node))
(setf state :left)
(loop))))
(:up
(cond ((null stack) nil)
((eq node (node-left (car stack)))
(setf node (pop stack))
(setf state :right)
(values t (node-key node) (node-value node)))
(t (setf node (pop stack))
(loop)))))))
#'loop)))
rg
Raffael Cavallaro
> Publishing code under the GPL does not preclude the copyright holder
> from also making the code available under a commercial license. If you
> want to use PJB's code in a commercial product why don't you just ask
> him for a price quote?
That's certainly true, and if I wanted/needed any of his libraries for
use in a commercial product, I certainly would (assuming a commercial
license were within budget, etc.). However, as I'm sure you know, the
library space is fairly competitive, and many of the competitors'
offerings are not GPL licensed, with the predictable result that these
other libraries will see wider use.
Raffael Cavallaro
> Notice that the GPL is not contradictory to commercial interests, on the
> contrary. In fact, it would be in the best interest of any commercial
> endeavour to distribute the sources of their software and firmware under
> the GPL license, since otherwise a competitor could patent the core
> techniques.
Unless they themselves already hold said patents, which is how closed
source often works (cf. Apple, Microsoft, ...)
> Or if the original company patents it itself, then it will
> have published it already so no evil would come from giving a copy of
> the source along with any product.
>
>
>
> Now, perhaps I should explicitely state in each file that commercial
> licenses are also available upon request, but I guess that if commercial
> entities were interested I would have contacted with me already.
Not necessarily. Stating the price for a royalty free commercial
license for each/all of your libraries might very well provide you with
non-negligble revenue. For example, I know for a fact that at least a
couple of the regular correspondents to this newsgroup payed a
significant amount to support development of an open source lisp IDE...
If I knew that your libraries were available for a reasonable cost, I
might very well buy a license. What's a reasonable cost? Well,
LispWorks sells an entire common lisp implementation, with GUI
framework and fully featured IDE and editor for US$1500.00, so I would
think that a handful of lisp libraries would be significantly less than
that.
RG
Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
wrote:
> On 2010-03-19 14:48:25 -0400, RG said:
That's true. But that is *very* different from what you first said:
> no one who currently works on a commercial,
> published product, or who contemplates working on a commercial
> published product in the future, can take the risk of using your
> libraries because they are GPL licensed.
Being uncompetitive is not at all the same thing as being an
unacceptable risk.
rg
Raffael Cavallaro
> That's true. But that is *very* different from what you first said:
>
>> no one who currently works on a commercial,
>> published product, or who contemplates working on a commercial
>> published product in the future, can take the risk of using your
>> libraries because they are GPL licensed.
>
> Being uncompetitive is not at all the same thing as being an
> unacceptable risk.
The one flows from the other. He presents his libraries as GPL. Many
will see this as an unacceptable risk - i.e., they will not use his
libraries for fear that one day they may find their way into a
commercial product (this has happened to commercial organizations in
the past). Other libraries that are not GPL do exist. These libraries
will see wider use.
There is no contradiction here - GPL licensed works can also be
commercially licensed, but there is no guarantee that they will be
should such works find their way into a commercial published product.
The copyright holder has every right to simply demand that the
published work be open sourced rather than grant a commercial license.
Pascal J. Bourguignon
writes:
Yes, I might try to do that. But I guess I'll have first to split my
libraries, for it seems that in general people only want one feature and
not the whole code base.
--
__Pascal Bourguignon__
Alex Mizrahi
PJB> application using it that I might buy. Is it too high a price?
It depends on what kind of library it is and what kind of application. I
guess usually it is too high.
PJB> Notice that the GPL is not contradictory to commercial interests, on
PJB> the contrary.
I think that GPL'ing application code can absolutely ruin application's
commercial viability in all but few cases.
PJB> In fact, it would be in the best interest of any commercial
PJB> endeavour to distribute the sources of their software and firmware
PJB> under the GPL license, since otherwise a competitor could patent the
PJB> core techniques. Or if the original company patents it itself, then
PJB> it will have published it already so no evil would come from giving a
PJB> copy of the source along with any product.
This is bullshit.
PJB> Now, perhaps I should explicitely state in each file that commercial
PJB> licenses are also available upon request, but I guess that if
PJB> commercial entities were interested I would have contacted with me
PJB> already.
Ha, you see, so your "business model" depends on application vendors _not
liking_ GPL enough to pay you.
So please don't tell us that GPL is good for everyone.
Library developers might be interested in using GPL for their libraries so
they can demand compensation for their work.
Application developers might be interested in libraries which are not GPLd
so they can make their application for less money and have higher profit
margins.
PJB> If I ever win big a lottery, or if I ever become a civil "servant", I
PJB> may publish my code under BSD or MIT. But until one of these unlikely
PJB> events occurs, I will stick to GPL or commercial licensing, with a
PJB> very strong favor for the former.
Well, it's your choice, so why not. Just do not pretend that what is good
for you should be also "in the best interest of any commercial endeavour".
It is simply not true.
I usually use LGPL (or LLGPL) for libraries I write for fun -- because I do
not expect to gain any monetary compensation for these libraries, but if
somebody takes my lib and makes some improvements -- I'd like to see those
improvements.
Also I think LGPL is useful when library is developed by a company for its
internal use -- when other companies use this library and work on it too,
original company might enjoy improvements and bugfixes they make.
PJB> (*) But much less hard than Robert Sedgewick, let's thank HIM for the
PJB> really hard work, which americans did by paying his tenure, and the
PJB> other peoples of the Earth by supporting (willingly or not) the
PJB> american debt. We've already paid for his ideas.
Oh, don't forget that Sedgewick did not invent it all by himself. Red-black
tree is inspired by B-tree by Rudolf Bayer.
And don't forget centuries of mathematical thought which made these things
possible at all.
Also don't forget that there are other forms of self-balancing binary
trees -- e.g. AVL trees:
"The AVL tree is more rigidly balanced than Red-Black trees, leading to
slower insertion and removal but faster retrieval."
So it's not like we absolutely need those red-black trees...
AVL trees were invented by Soviet computer scientists, by the way, did you
pay them for their ideas? :)
Raffael Cavallaro
> Yes, I might try to do that. But I guess I'll have first to split my
> libraries, for it seems that in general people only want one feature and
> not the whole code base.
Please post an all-code discount price as well - it might be worth my
while (and others') to just purchase a single license for everything.
RG
Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
wrote:
> On 2010-03-20 01:08:20 -0400, RG said:
>
> > That's true. But that is *very* different from what you first said:
> >
> >> no one who currently works on a commercial,
> >> published product, or who contemplates working on a commercial
> >> published product in the future, can take the risk of using your
> >> libraries because they are GPL licensed.
> >
> > Being uncompetitive is not at all the same thing as being an
> > unacceptable risk.
>
> The one flows from the other. He presents his libraries as GPL. Many
> will see this as an unacceptable risk - i.e., they will not use his
> libraries for fear that one day they may find their way into a
> commercial product (this has happened to commercial organizations in
> the past).
Anyone who rejects a GPL library as an unacceptable risk without even
making the slightest attempt at mitigating that risk by, say, sending an
email and asking about the availability of a commercial license, is an
idiot.
> Other libraries that are not GPL do exist. These libraries
> will see wider use.
That my well be, but that is a matter of competition, not unacceptable
risk.
> There is no contradiction here - GPL licensed works can also be
> commercially licensed, but there is no guarantee that they will be
There are never any guarantees about anything. But before one rejects a
GPL library as an unacceptable risk I think it is prudent to at least
make an inquiry to find out if that risk is real or just an assumption
you're making.
> should such works find their way into a commercial published product.
> The copyright holder has every right to simply demand that the
> published work be open sourced rather than grant a commercial license.
Yes, that is why it is wise to make these inquiries *before* deciding to
use the code. This really isn't that difficult. Here, let me show you:
PB: would you be willing to license your llrbtree library to me for use
in a commercial product? What would be your terms?
That wasn't so hard now, was it?
rg
Pascal J. Bourguignon
> PJB> I reclaim as compensation to be able to see the source of any
> PJB> application using it that I might buy. Is it too high a price?
>
> It depends on what kind of library it is and what kind of
> application. I guess usually it is too high.
>
> PJB> Notice that the GPL is not contradictory to commercial interests, on
> PJB> the contrary.
>
> I think that GPL'ing application code can absolutely ruin
> application's commercial viability in all but few cases.
Explain how Toyota providing the sources of its buggy brake software
would badly impact its sales.
You have basically two cases:
- the software is patented, and Tata buys a license to use it. This
situation is no different than today, so Toyota distributing its
sources under GPL would not change a cent of its revenue.
- Tata choose to use the GPL'ed software, and as soon as it sells its
first car, Toyota gets to see all the changes (since Tata must provide
its derived sources GPL'ed), and correct gets the bug corrected even
before the first customer is dead.
--> benefit for Toyota: - no spending in damage control marketing
- less spending on debugging and HR
shuffling.
--> benefit for Tata: - less R&D on some non-innovative part.
--> benefit for the society: the good engineers at Toyota who don't
have to debug the bugs of the bad engineers at Toyota, and the
engineers at Tata who didn't have to redesign from scratch a
brake software, but only to debug it, now have time to think
about my flying car I've been promised in the 60's for 2000.
Remember that contrarily to a certain misinformed American judge,
corporations are not free-wheeling beings (pun intended), but should be only
groups of human persons given a specific priviledge of some monetary and
safety benefits against their work for the betterment of the human
society.
> PJB> In fact, it would be in the best interest of any commercial
> PJB> endeavour to distribute the sources of their software and firmware
> PJB> under the GPL license, since otherwise a competitor could patent the
> PJB> core techniques. Or if the original company patents it itself, then
> PJB> it will have published it already so no evil would come from giving a
> PJB> copy of the source along with any product.
>
> This is bullshit.
This is an opinion.
> PJB> Now, perhaps I should explicitely state in each file that commercial
> PJB> licenses are also available upon request, but I guess that if
> PJB> commercial entities were interested I would have contacted with me
> PJB> already.
>
> Ha, you see, so your "business model" depends on application vendors
> _not liking_ GPL enough to pay you.
> So please don't tell us that GPL is good for everyone.
Not at all. This is a concession I could envisage to do. I would
regretfully accept money in compensation of not bettering the human
society by keeping some software secret. Actually I would be so ashamed
to do so, that I would have to be paid a lot to tame my shame. Ask
Judas about it! (Clearly, 30 gold coins wasn't enough; of course in the
case of Jesus, no amount would have been enough).
> Library developers might be interested in using GPL for their
> libraries so they can demand compensation for their work.
> Application developers might be interested in libraries which are not
> GPLd so they can make their application for less money and have higher
> profit margins.
>
> PJB> If I ever win big a lottery, or if I ever become a civil "servant", I
> PJB> may publish my code under BSD or MIT. But until one of these unlikely
> PJB> events occurs, I will stick to GPL or commercial licensing, with a
> PJB> very strong favor for the former.
>
> Well, it's your choice, so why not. Just do not pretend that what is
> good for you should be also "in the best interest of any commercial
> endeavour". It is simply not true.
I just haven't asked any price yet! (Other than the one put by the
GPL).
> I usually use LGPL (or LLGPL) for libraries I write for fun -- because
> I do not expect to gain any monetary compensation for these libraries,
> but if somebody takes my lib and makes some improvements -- I'd like
> to see those improvements.
>
> Also I think LGPL is useful when library is developed by a company for
> its internal use -- when other companies use this library and work on
> it too, original company might enjoy improvements and bugfixes they
> make.
I gave a snapshot of my library under LGPL once, but I won't do it
again, I definitely do not like it. It will be GPL, or make an
unrejectable offer.
> PJB> (*) But much less hard than Robert Sedgewick, let's thank HIM for the
> PJB> really hard work, which americans did by paying his tenure, and the
> PJB> other peoples of the Earth by supporting (willingly or not) the
> PJB> american debt. We've already paid for his ideas.
>
> Oh, don't forget that Sedgewick did not invent it all by
> himself. Red-black tree is inspired by B-tree by Rudolf Bayer.
> And don't forget centuries of mathematical thought which made these
> things possible at all.
Sure, he just improved it, which was possible because it was "open
source".
> Also don't forget that there are other forms of self-balancing binary
> trees -- e.g. AVL trees:
>
> "The AVL tree is more rigidly balanced than Red-Black trees, leading
> to slower insertion and removal but faster retrieval."
Sure, and thanks for these algorithms being "open source", we can know
that Left Leaning Red-Black tree are much easier to implement and
therefore their implementations are much less risky of having bugs than
those of AVL trees.
> So it's not like we absolutely need those red-black trees...
>
> AVL trees were invented by Soviet computer scientists, by the way, did
> you pay them for their ideas? :)
You bet! And not only with money, but with the blood of the hundred of
million of people killed by the soviets.
--
__Pascal Bourguignon__
Cor
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Yes, that is why it is wise to make these inquiries *before* deciding to
> use the code. This really isn't that difficult. Here, let me show you:
>
> PB: would you be willing to license your llrbtree library to me for use
> in a commercial product? What would be your terms?
I think you mean a "closed" asin non-GPL'ed commercial product.
Because if the commercial product would be a GPL'ed product the GPL
would cover that allready.
Cor
--
Join us and live in peace or face obliteration
If you hate to see my gun consider a non criminal line of work
I never threathen but merely state the consequences of your choice
Geavanceerde politieke correctheid is niet te onderscheiden van sarcasme
Alex Mizrahi
??>> application's commercial viability in all but few cases.
PJB> Explain how Toyota providing the sources of its buggy brake software
PJB> would badly impact its sales.
Um. You should distinguish software which is a product itself from a
software bundled with hardware which is product.
When company's business is in selling hardware with software being only a
minor component, of course it is not a problem to release software as open
source.
But when software is a product, releasing it into open source means that
customers can just take it for free and compile it themselves. Or a
competitor can just compile it and sell for less money.
Sometimes companies can still make money selling an improved proprietary
version, or selling support, or something like that.
But that won't work for everybody.
PJB> - Tata choose to use the GPL'ed software, and as soon as it sells its
PJB> first car, Toyota gets to see all the changes (since Tata must
PJB> provideits derived sources GPL'ed), and correct gets the bug corrected
PJB> evenbefore the first customer is dead.
LGPL would work same way here, by the way.
Raffael Cavallaro
> Yes, that is why it is wise to make these inquiries *before* deciding to
> use the code. This really isn't that difficult. Here, let me show you:
>
> PB: would you be willing to license your llrbtree library to me for use
> in a commercial product? What would be your terms?
>
> That wasn't so hard now, was it?
No, but as easy as it is, (and this doesn't take account of authors who
don't reply, or take 3 weeks to begin the back and forth over a
commercial license price, etc.) it is still significantly more effort
than using a bsd/mit/apace/lgpl/etc. licensed library with similar
functionality. So people will just do that.
The result is, libraries that are licensed lgpl will see more use than
libraries that are licensed gpl (this is, after all why the lgpl was
created - though now called the Lesser GPL it was originally the
Library GPL, as I'm sure you're aware).
Barriers to adoption, even if "not so hard," still reduce usage.
RG
Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
wrote:
> On 2010-03-20 13:52:18 -0400, RG said:
Of course. There is a competitive landscape. Those who provide more
for less will take customers away from those who provide less for more.
But again, that is very different from what you originally said (which I
notice you keep cutting out of the context):
> no one who currently works on a commercial,
> published product, or who contemplates working on a commercial
> published product in the future, can take the risk of using your
> libraries because they are GPL licensed.
*That* is simply false.
rg
Raffael Cavallaro
>
>> no one who currently works on a commercial,
>> published product, or who contemplates working on a commercial
>> published product in the future, can take the risk of using your
>> libraries because they are GPL licensed.
>
> *That* is simply false.
Sorry, should have written no one who currently works on a commercial,
published product, or who contemplates working on a commercial
published product in the future, can take the risk of just using GPL
licensed libraries, as they could just use LLGPL licensed libraries, or
just use MIT licensed libraries, or just use BSD licensed libraries, or
just use Apache licensed libraries, without first negotiating and
obtaining an affordable commmercial license, which affordable
commercial license may or may not be available.
RG
Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
wrote:
> On 2010-03-20 15:51:52 -0400, RG said:
Assuming competing libraries under those licenses exist. They may not.
I guess the operative words in what you're saying are "just using."
It's true that you can't "just use" GPL code in a commercial product.
You have to either GPL your own code, or negotiate a separate license
with the copyright holder. But those are hardly insurmountable
obstacles. The way you phrase it still sounds like FUD to my ear.
rg
Nicolas Neuss
writes:
> Using them would place their employer or the commercial organization
> to which they belong under the obligation of publishing all of the
> source code for any released product that included your library. As a
> result, most people working on commercial published software, or who
> contemplate doing so in the future, simply avoid gpl libraries
> altogether.
Here is a question which I find rather interesting: Is in-house use of
GPLed software allowed? It is quite clear that using GPLed software by
a single developer to run a commercial web server for example is
allowed. But in the case of multiple developers inside a company one
could either argue that the company operates as an entity, or
alternatively that the company by letting one of their developers
combine GPLed software with their own product is forced to give her/him
the whole software under GPL.
Nicolas
P.S.: Sorry about Cross-posting to gnu.misc.discuss, but there should be
the experts.
Pascal J. Bourguignon
In-house use would be outside of the scope of the GPL, since no
"distribution" would occur.
A more interesting question would be what happens with respect to
holdings, and the daughter companies. In this case, I would argue
distribution occurs (invoicing would have to occur legally AFAIK), and
therefore GPL would apply. Which doesn't mean that YOU would get access
to the code of course, only that the daughter company who buys it from
another daughter company would get it (and be able to hire YOU instead
of the sister company if them need a patch and the sister is unable or
unwilling to provide it).
--
__Pascal Bourguignon__
Nicolas Neuss
> In-house use would be outside of the scope of the GPL, since no
> "distribution" would occur.
This means that in-house "distribution" to employees would not count as
distribution in the GPL sense. OK, this might indeed be the most
reasonable point of view.
Nicolas
John Hasler
> Using them would place their employer or the commercial organization
> to which they belong under the obligation of publishing all of the
> source code for any released product that included your library.
They are not required to publish it. They are merely required to
distribute it along with the binaries. If you offer source to everyone
to whom you sell binaries you are done.
> As a result, most people working on commercial [closed source]
> published software, or who contemplate doing so in the future, simply
> avoid gpl libraries altogether.
And that's fine, just as it is fine that some of us avoid non-free
libraries because source is not available or the terms are too
restrictive.
Nicolas writes:
> Here is a question which I find rather interesting: Is in-house use of
> GPLed software allowed?
Yes.
> But in the case of multiple developers inside a company one
> could either argue that the company operates as an entity...
It does.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Pascal J. Bourguignon
Yes, definitely.
First, the most efficient companies won't have any "distribution". The
new software would be instealled on the file server, and everybody
could use it from here.
And even in the less efficient companies, employees don't install
softwarem (it's the job of the IT jockeys).
--
__Pascal Bourguignon__
Raffael Cavallaro
> They are not required to publish it. They are merely required to
> distribute it along with the binaries. If you offer source to everyone
> to whom you sell binaries you are done.
In practice this amounts to publication. Every customer would receive
the source; every customer has the right to make it public; it would
only take one customer excercising this right to make the source
publicly available.
--
Raffael Cavallaro
John Hasler
> They are not required to publish it. They are merely required to
> distribute it along with the binaries. If you offer source to everyone
> to whom you sell binaries you are done.
> In practice this amounts to publication. Every customer would receive
> the source; every customer has the right to make it public; it would
> only take one customer excercising this right to make the source
> publicly available.
They might, but there are cases where they did not. The point is that
_you_ are not required to publish anything. Offering source to everyone
who receives binaries from you satisfies your GPL obligations. You can
ignore requests for source from anyone else.
Of course, if the possibility that someone might pass the software on
worries you, the solution is simple: don't link to GPL works.
Raffael Cavallaro
> They might, but there are cases where they did not.
One can't rely on this unlikely possibility, which becomes increasingly
unlikely the more sales are made.
> The point is that
> _you_ are not required to publish anything.
It hardly matters who does the publishing. The point is that the source
still becomes publicly available.
> Offering source to everyone
> who receives binaries from you satisfies your GPL obligations. You can
> ignore requests for source from anyone else.
>
> Of course, if the possibility that someone might pass the software on
> worries you, the solution is simple: don't link to GPL works.
Which is why many developers choose to avoid this possibility and use
LGPL/LLGPL/BSD/MIT/Apache licensed libraries instead. And now we've
come full circle.
Pascal J. Bourguignon
writes:
Sure.
And the question remains why you should imposes your choices on me?
--
__Pascal Bourguignon__
John Hasler
> And the question remains why you should imposes your choices on me?
Explain.
Raffael Cavallaro
> Sure.
>
> And the question remains why you should imposes your choices on me?
Not only am I not imposing anything on you, I've already offered to pay
you for a commercial license. So you can have your cake (GPL licensing)
and eat it too (paid commercial licensing).
My principal objection to the GPL is that its license requirements
regarding opening source code make it very unpopular with many
commercial developers, and therefore whenever possible, they choose
non-GPL alternatives.
In short, I don't think GPL licensing gets you anything additional in
terms of getting code open sourced. Users who need to keep their source
closed either won't use it, or will use in in a way that allows them
not to open the source (e.g., Paul Graham's viaweb and their use of the
GPL CLISP).
Meanwhile, users of LLGPL or BSD, etc. licensed code frequently open
source whatever they are able as contributions back to the relevant
project. Giving users the choice of what they will and won't open
source results in more users, and just as many open source
contributions.
More use means the library is more of a community standard, more
contributors, more bug fixes, more extensions, more additions, etc. And
non-GPL license authors can still sell support (e.g., priorty for
bugfixes or priority for adding new features, etc. - The Clozure folks
did this for their IDE, and Clozure is LLGPL licensed).
I think people should avoid GPL licensing their work as a pragmatic
means of ensuring maximal adoption. Ironically, the FSF understood this
dynamic which is why they created the Library GPL, now known as the
Lesser GPL.
John Hasler
> I think people should avoid GPL licensing their work as a pragmatic
> means of ensuring maximal adoption.
You assume that everyone has maximum adoption as their primary goal.
David Kastrup
writes:
> On 2010-03-21 22:14:30 -0400, Pascal J. Bourguignon said:
>
>> Sure.
>>
>> And the question remains why you should imposes your choices on me?
>
> My principal objection to the GPL is that its license requirements
> regarding opening source code make it very unpopular with many
> commercial developers, and therefore whenever possible, they choose
> non-GPL alternatives.
That's perfectly fine since what makes the source code unpopular with
the commercial developers also stops them from contributing back. So
there is no loss.
> In short, I don't think GPL licensing gets you anything additional in
> terms of getting code open sourced. Users who need to keep their
> source closed either won't use it, or will use in in a way that allows
> them not to open the source (e.g., Paul Graham's viaweb and their use
> of the GPL CLISP).
It does not get you "anything additional", but it gets you something
_less_: a proprietary product that uses your own code to draw your user
base away from you.
> Meanwhile, users of LLGPL or BSD, etc. licensed code frequently open
> source whatever they are able as contributions back to the relevant
> project. Giving users the choice of what they will and won't open
> source results in more users, and just as many open source
> contributions.
The real world tends to disagree by example.
Yes, I'd prefer a world in which Richard Stallman was pretty much wrong
about everything, too.
But one has to make the best from what one actually got.
--
David Kastrup
RG
John Hasler <jha...@newsguy.com> wrote:
> Ralph writes:
> > I think people should avoid GPL licensing their work as a pragmatic
> > means of ensuring maximal adoption.
>
> You assume that everyone has maximum adoption as their primary goal.
Indeed, if maximal adoption were the goal the best way to achieve that
would be to simply renounce the copyright and release the code into the
public domain.
rg
RG
Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
wrote:
> On 2010-03-21 22:14:30 -0400, Pascal J. Bourguignon said:
>
> > Sure.
> >
> > And the question remains why you should imposes your choices on me?
>
> Not only am I not imposing anything on you, I've already offered to pay
> you for a commercial license. So you can have your cake (GPL licensing)
> and eat it too (paid commercial licensing).
>
> My principal objection to the GPL is that its license requirements
> regarding opening source code make it very unpopular with many
> commercial developers, and therefore whenever possible, they choose
> non-GPL alternatives.
That's a much better way of putting it than your original formulation.
> In short, I don't think GPL licensing gets you anything additional in
> terms of getting code open sourced.
...
> I think people should avoid GPL licensing their work as a pragmatic
> means of ensuring maximal adoption.
Here is where you are imposing your choices on others. Not everyone
shares this quality metric of yours. Some people have goals other than
insuring maximal adoption, like, oh, I don't know, making money for
example. Such people might want to use the copyright laws not to force
others to create open-source software but to create artificial scarcity
in order to drive up prices. One can argue whether or not this strategy
will be effective. One can argue (as Stallman does) that one ought not
choose this quality metric for moral or political reasons. But neither
the quality metric nor the strategy are unreasonable a priori.
rg
Raffael Cavallaro
> You assume that everyone has maximum adoption as their primary goal.
I assume that the author's goal is maximizing the amount of open source
- and in fact, it is Pascal's stated goal - that others who use his
library will open their source code for him to see and use - a
perfectly reasonable desire. I just don't think anyone whose source is
closed is going to open that source code simply to use a library - if
they are constrained not to open their source, they simply won't use
GPL libraries.
In order to accomplish this primary goal - greater amounts of open
source - you need users and contributors. Possibly counterintuitively,
the goal of maximizing open source is actually better accomplished by
*not* choosing the GPL. The GPL drives potential users away, and
potential users are potential contributors, bug fixers, etc. Instead,
these potential users will become users of some other library which is
LGPL, or BSD, etc. licensed, and they will become open source
contributors to those other libraries, not to the GPL licensed project.
Again, recognition of this dynamic is what drove the creation of the
Library GPL (now the Lesser GPL) in the first place.
Raffael Cavallaro
>
>> I think people should avoid GPL licensing their work as a pragmatic
>> means of ensuring maximal adoption.
>
> Here is where you are imposing your choices on others. Not everyone
> shares this quality metric of yours.
See my reply to John Hasler for why maximizing adoption is a means to
maximizing openly available source code, Pascal's stated goal.
Pascal J. Bourguignon
Indeed these are the questions. I will have to think more about it, and
may be change the licence in the future (perhaps this year).
I also would like to contribute some of my code to some common library
and this would certainly require a change of license anyway.
But I need more time to think about it and work on it.
--
__Pascal Bourguignon__
John Hasler
> Possibly counterintuitively, the goal of maximizing open source is
> actually better accomplished by *not* choosing the GPL.
I guess this is why Linux has been totally eclipsed by BSD.
> Instead, these potential users will become users of some other library
> which is LGPL, or BSD, etc. licensed, and they will become open source
> contributors to those other libraries, not to the GPL licensed
> project.
Most never become contributors at all.
Nicolas Neuss
> It does not get you "anything additional", but it gets you something
> _less_: a proprietary product that uses your own code to draw your
> user base away from you.
This is quite understandable - I would not really like seeing Microsoft
use my code.
However, when I was in search for a license for code of mine -Femlisp, a
PDE solver written in Common Lisp- I stood before the question which
license to choose[*]. A commercial license did not make much sense,
because the code was (and is) not yet commercially valuable. However, I
wanted to retain at least some possibility of providing enhanced value
(in the form of additional features) within a commercial setting. A GPL
license would make this business model impossible for everyone -
_including me_ as soon as other people would start contributing relevant
portions of code under the GPL. Therefore, I decided in favor of the
(modified) BSD license.
Nicolas
[*] More precisely, I asked my university for permission to use either
GPL or BSD, and then had the choice.
David Kastrup
> David Kastrup <d...@gnu.org> writes:
>
>> It does not get you "anything additional", but it gets you something
>> _less_: a proprietary product that uses your own code to draw your
>> user base away from you.
>
> This is quite understandable - I would not really like seeing Microsoft
> use my code.
>
> However, when I was in search for a license for code of mine -Femlisp,
> a PDE solver written in Common Lisp- I stood before the question which
> license to choose[*]. A commercial license did not make much sense,
> because the code was (and is) not yet commercially valuable. However,
> I wanted to retain at least some possibility of providing enhanced
> value (in the form of additional features) within a commercial
> setting. A GPL license would make this business model impossible for
> everyone - _including me_ as soon as other people would start
> contributing relevant portions of code under the GPL.
>
> Therefore, I decided in favor of the (modified) BSD license.
That does not keep other people from contributing relevant portions of
code under the GPL, if they so desire.
--
David Kastrup
Raffael Cavallaro
> I guess this is why Linux has been totally eclipsed by BSD.
1. Linux isn't a *library*, it's an operating system. A GPL operating
system doesn't force GPL licensing for any application that runs on it.
A GPL library *does* force GPL licensing for any program that links
with it.
Again, the LLGPL was created for precisely this purpose.
2. Mac OS X is BSD Unix. It has existed for half the time that linux
has, and has more than 5 times the web client share of linux, so yes,
BSD is on its way to eclipsing linux as a client OS.
<http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems>
John Hasler
> Mac OS X is BSD Unix.
No it isn't. It's a heavily modified Mach single-server kernel with a
partial BSD userland. And Apple contributes little or nothing back.
Raffael Cavallaro
> No it isn't.
The Open Group which does the official UNIX certification would beg to differ:
<http://www.opengroup.org/public/prods/brand3581.htm>
<http://www.opengroup.org/homepage-items/c399.html>
> It's a heavily modified Mach single-server kernel with a
> partial BSD userland. And Apple contributes little or nothing back.
<http://www.apple.com/opensource/>
lists scores of open source components that form part of Mac OS X and
to which Apple contributes its enhancements.
The market reality is that many programmers work on projects that are,
at least in part, closed source. Open source licenses other than the
GPL allow these programmers to use and contribute to open source
projects.
John Hasler
> The Open Group which does the official UNIX certification would beg to
> differ:
Purchasing a certificate granting the right to label one's product UNIX
does not make it a BSD.
> The market reality...
...is irrelevant to many of us.
> ...is that many programmers work on projects that are, at least in
> part, closed source. Open source licenses other than the GPL allow
> these programmers to use and contribute to open source projects.
The Berkeley license as well as _some_ other Open Source licenses permit
them to keep some of their changes secret. This is the very reason some
programmers use the GPL.
refun
> The Berkeley license as well as _some_ other Open Source licenses permit
> them to keep some of their changes secret. This is the very reason some
> programmers use the GPL.
While I respect Pascal's decision to use whatever license he wants to use, it
might be worth noticing that a good majority of Common Lisp libraries(besides
Pascal's and a handful of others) are licensed under BSD, LLGPL, MIT or public
domain.
GPL seems to be an unpopular choice for Common Lisp code, especially libraries.
This means that in practice, people will pick a license which grants them more
effective rights, and doesn't force them to release the code to their entire
application just because they used a handful of functions from another library
which is licensed under GPL. In most of the cases, even if other people don't
have the intention of going commercial, they like to have the option, which is
why GPLed libraries are usually unpopular with Common Lisp developers.
Raffael Cavallaro
> Purchasing a certificate granting the right to label one's product UNIX
> does not make it a BSD.
Being a derivative of 4.4 BSD makes it a BSD; Being certified by the
Open Group makes it a UNIX. Mac OS X is a BSD UNIX.
>
>> The market reality...
>
> ...is irrelevant to many of us.
Many may wish it weren't relevant, but it is. The FSF recognized that
the GPL was a poor match for the market realities of library use nearly
20 years ago when the FSF created the GNU Library Public License, now
the Lesser GPL, for precisely this reason.
>
>> ...is that many programmers work on projects that are, at least in
>> part, closed source. Open source licenses other than the GPL allow
>> these programmers to use and contribute to open source projects.
>
> The Berkeley license as well as _some_ other Open Source licenses permit
> them to keep some of their changes secret. This is the very reason some
> programmers use the GPL.
People and organizations who want to keep code secret are going to do
so. It is naive to think that they will change their whole business
model just to use a library. Instead, they will use libraries with
licenses that allow them to keep some code private while still open
sourcing other code thus contributing to the sum total of open source
code.
Lieven Marchand
writes:
> In short, I don't think GPL licensing gets you anything additional in
> terms of getting code open sourced. Users who need to keep their
> source closed either won't use it, or will use in in a way that allows
> them not to open the source (e.g., Paul Graham's viaweb and their use
> of the GPL CLISP).
As far as I can tell, GPL CLISP would allow you to distribute your
commercial applications compiled and dumped with it.
Nicolas Neuss
> That does not keep other people from contributing relevant portions of
> code under the GPL, if they so desire.
Of course, and it should not. But I think that people contributing to a
library usually do so under the same license which is used for the
original body of code, especially if it is a "fair" license like GPL or
BSD which does not give any particular group of people special rights.
Nicolas
Hyman Rosen
> 2. Mac OS X is BSD Unix. It has existed for half the time that linux
> has, and has more than 5 times the web client share of linux, so yes,
> BSD is on its way to eclipsing linux as a client OS.
It is not correct to say that Mac OS X "is" BSD Unix for normal
definitions of "is".
Look at <http://www.opensource.apple.com/release/mac-os-x-105/>.
The mix of licenses is broad, but many of Apple's own OS components
are licensed under the APPLE PUBLIC SOURCE LICENSE, found at
<http://www.opensource.apple.com/license/apsl/>. It has these key
provisions:
If You Externally Deploy Your Modifications, You must make
Source Code of all Your Externally Deployed Modifications
either available to those to whom You have Externally Deployed
Your Modifications, or publicly available. Source Code of Your
Externally Deployed Modifications must be released under the
terms set forth in this License, including the license grants
set forth in Section 3 below, for as long as you Externally
Deploy the Covered Code or twelve (12) months from the date of
initial External Deployment, whichever is longer. You should
preferably distribute the Source Code of Your Externally Deployed
Modifications electronically (e.g. download from a web site).
...
In consideration of, and as a condition to, the licenses granted
to You under this License, You hereby grant to any person or
entity receiving or distributing Covered Code under this License
a non-exclusive, royalty-free, perpetual, irrevocable license,
under Your Applicable Patent Rights and other intellectual property
rights (other than patent) owned or controlled by You, to use,
reproduce, display, perform, modify, sublicense, distribute and
Externally Deploy Your Modifications of the same scope and extent
as Apple's licenses under Sections 2.1 and 2.2 above.
Raffael Cavallaro
> As far as I can tell, GPL CLISP would allow you to distribute your
> commercial applications compiled and dumped with it.
My understanding is that if your published application (commercial or
otherwise) uses facilities of CLISP not generally available in other
lisps (i.e., CLISP specific extensions to common lisp) then you would
be required to release the source of your application under the GPL.
IOW, an application that could just as easily be distributed using sbcl
or ccl, etc. does not need to open its source, but one that is clisp
specific does.
Raffael Cavallaro
> It is not correct to say that Mac OS X "is" BSD Unix for normal
> definitions of "is".
Mac OS X *is* descended from 4.4 BSD for normal definitions of "is."
Mac OS X *is* a UNIX by the only legal definition of UNIX and for
normal definitions of "is."
The license under which Apple releases its open source doesn't change
Mac OS X's BSD heritage, and it doesn't invalidate Mac OS X's UNIX
certification.
Hyman Rosen
> The license under which Apple releases its open source doesn't change
> Mac OS X's BSD heritage, and it doesn't invalidate Mac OS X's UNIX
> certification.
However, the license under which Apple releases its OS components
does affect how those components may be used by others. BSD-licensed
code does not require publication of changes, for example, while the
Apple license does. Since much of the discussion in this newsgroup
focuses on license features and requirements, saying that Mac OS X
"is" BSD needlessly confuses that issue.
Pillsy
> On 3/22/2010 8:01 PM, Raffael Cavallaro wrote:
> > 2. Mac OS X is BSD Unix. It has existed for half the time that linux
> > has, and has more than 5 times the web client share of linux, so yes,
> > BSD is on its way to eclipsing linux as a client OS.
> It is not correct to say that Mac OS X "is" BSD Unix for normal
> definitions of "is".
> Look at <http://www.opensource.apple.com/release/mac-os-x-105/>.
> The mix of licenses is broad, but many of Apple's own OS components
> are licensed under the APPLE PUBLIC SOURCE LICENSE, found at
> <http://www.opensource.apple.com/license/apsl/>.
If Raffael had said that OS X is a "BSD-licensed Unix", your argument
would be on point (and Raffael's would be very, very silly). However,
he said nothing of the sort.
Whether it's a BSD Unix or not has nothing to do with its licensing,
and never has. The BSD Unix codebase was intentionally licensed in
such a way as to allow people to make and sell partially or wholly
closed-source, commercial derivatives. Over the years, a lot of
vendors have taken advantage of this opportunity, including Sun, NeXT,
Apple and, IIRC, Digital.
Cheers,
Pillsy
Pillsy
wrote:
> Raffael Cavallaro <raffaelcavall...@pas.espam.s.il.vous.plait.mac.com>
> writes:
[...]
> > Which is why many developers choose to avoid this possibility and use
> > LGPL/LLGPL/BSD/MIT/Apache licensed libraries instead. And now we've
> > come full circle.
> Sure.
> And the question remains why you should imposes your choices on me?
He shouldn't, and AFAICT isn't trying to.
Upthread, you said that you allow people to use your libraries at the
price of abiding by the GPL. Pointing out that the price you charge is
too high for a given market is not remotely the same thing as forcing
you to choose a different price. Indeed, people attempt to negotiate,
better prices with vendors all the time. Of course, vendors refuse to
lower their prices in response to such requests with a good deal of
frequency as well.
When the consideration being exchanged is just a pile of currency,
this is all regarded as so mundane that people hardly notice it. The
only thing that's different here is that the negotiation is over
source code instead of money.
Cheers,
Pillsy
David Kastrup
writes:
> On 2010-03-23 09:11:03 -0400, Hyman Rosen said:
>
>> It is not correct to say that Mac OS X "is" BSD Unix for normal
>> definitions of "is".
>
> Mac OS X *is* descended from 4.4 BSD for normal definitions of "is."
Not really. Darwin may be, but all the graphical folderol running on it
is rather descended (or written new) from older MacOS code not based on
BSD.
--
David Kastrup
RJack
> Raffael Cavallaro
> <raffaelc...@pas.espam.s.il.vous.plait.mac.com> writes:
>
>> On 2010-03-23 09:11:03 -0400, Hyman Rosen said:
>>
>>> It is not correct to say that Mac OS X "is" BSD Unix for normal
>>> definitions of "is".
"That depends on what the definition of 'is' is." --- William Jefferson
Clinton, 42nd President of the United States.
>> Mac OS X *is* descended from 4.4 BSD for normal definitions of
>> "is."
Sincerely,
RJack :)
Hyman Rosen
>>> On 2010-03-23 09:11:03 -0400, Hyman Rosen said:
>>>> It is not correct to say that Mac OS X "is" BSD Unix for normal
>>>> definitions of "is".
> "That depends on what the definition of 'is' is." --- William Jefferson
> Clinton, 42nd President of the United States.
Well, duh.
Thomas A. Russ
> Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
> writes:
> >
> > Mac OS X *is* descended from 4.4 BSD for normal definitions of "is."
>
> Not really. Darwin may be, but all the graphical folderol running on it
> is rather descended (or written new) from older MacOS code not based on
> BSD.
Well, actually, a fair bit of the graphical code on OS X comes from the
NeXT operating system and graphics library. The older MacOS code has
slowly been dropped from the Mac OS over the years.
(The classic Mac OS actually used a Pascal interface. The current Mac
OS uses Objective C.)
--
Thomas A. Russ, USC/Information Sciences Institute
Andy Chambers
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> What's a reasonable cost? Well,
> LispWorks sells an entire common lisp implementation, with GUI
> framework and fully featured IDE and editor for US$1500.00, so I would
> think that a handful of lisp libraries would be significantly less than
> that.
But Lispworks are competing with a number of similar products of
varying prices (all the way down to free). Price is not, never has
been, and never will be determined solely by the effort that goes into
making the thing you're selling.
If Pascal can convince you that by using his libraries you'll increase
your profits a gazillion times, then you'd be silly to refuse to pay
because it costs more than Lispworks.
Regards,
Andy
Raffael Cavallaro
> Since much of the discussion in this newsgroup
> focuses on license features and requirements, saying that Mac OS X
> "is" BSD needlessly confuses that issue.
Saying that Mac OS X is BSD is:
1. true
2. a counterexample to the claim that linux is trouncing BSD UNIX.
The original claim was that linux was dominating BSD UNIX because of
the GPL. The 5x web client numbers for Mac OS X show that non-GPL
licensed UNIX (here, BSD, APSL) in fact has much greater numbers than
GPL linux.
Finally, the APSL requires that modifications to *covered code* (i.e.,
the APSL library or code you are using in your larger work) be open
sourced if your larger work is distributed. You are not required to
open source the whole larger work, something that the GPL *does*
require, and the LGPL, like the APSL, does not.
Alan Mackenzie
>> Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
>> writes:
Objective-C shows the advantages of the GPL. Since the writers of the
compiler, NeXT, wanted to use GCC's backend, they had to make their
frontend GPL'd too. As a result, there exists a public Objective-C
compiler, and that has done neither NeXT nor Apple any disfavours.
--
Alan Mackenzie (Nuremberg, Germany).
Raffael Cavallaro
> If Pascal can convince you that by using his libraries you'll increase
> your profits a gazillion times, then you'd be silly to refuse to pay
> because it costs more than Lispworks.
This is a fairly absurd hypothetical. Using Pascal's library would only
save me the time of implementing it myself, and so would be worth
precisely the effort that goes into making it.
Pascal J. Bourguignon
writes:
> On 2010-03-23 09:41:02 -0400, Hyman Rosen said:
>
>> Since much of the discussion in this newsgroup
>> focuses on license features and requirements, saying that Mac OS X
>> "is" BSD needlessly confuses that issue.
>
> Saying that Mac OS X is BSD is:
>
> 1. true
For some meaning.
In the case of licensing, it looks like it's closer to LGPL than to BSD.
> 2. a counterexample to the claim that linux is trouncing BSD UNIX.
I'm afraid this counterexample is based on the wrong idea that MacOSX is
a system whose life started in 2001, after Linux.
Actually, MacOSX is just NeXTSTEP, and is older than Linux, so it's not
surprizing it has more web clients than Linux. After all, NeXTSTEP was
the system where the web was INVENTED, and where the first web browser
was ever IMPLEMENTED!
> The original claim was that linux was dominating BSD UNIX because of
> the GPL. The 5x web client numbers for Mac OS X show that non-GPL
> licensed UNIX (here, BSD, APSL) in fact has much greater numbers than
> GPL linux.
>
> Finally, the APSL requires that modifications to *covered code* (i.e.,
> the APSL library or code you are using in your larger work) be open
> sourced if your larger work is distributed. You are not required to
> open source the whole larger work, something that the GPL *does*
> require, and the LGPL, like the APSL, does not.
Yes.
--
__Pascal Bourguignon__
Raffael Cavallaro
> Actually, MacOSX is just NeXTSTEP, and is older than Linux, so it's not
> surprizing it has more web clients than Linux. After all, NeXTSTEP was
> the system where the web was INVENTED, and where the first web browser
> was ever IMPLEMENTED!
And the laser printer was first connected to the Xerox Alto, but you
don't see many of those at graphic design firms.
NeXTSTEP never had a significant web client share once numbers of
internet users grew into the tens of millions. The numbers matched OS
usage - 95% of these new users were on Windows, and the overwhelming
majority of the remainder were on Mac OS. That's why NeXT had to sell
the company to Apple, itself a minority player.
Mac OS X has 5x as many web clients as Linux because of what Apple did
with NeXT, not because NeXT was ever a popular client platform.
Andrew Haley
> On 2010-03-21 22:14:30 -0400, Pascal J. Bourguignon said:
>
> My principal objection to the GPL is that its license requirements
> regarding opening source code make it very unpopular with many
> commercial developers, and therefore whenever possible, they choose
> non-GPL alternatives.
The choose non-GPL alternatives because they want their software not
to be free, unlike the libraries they use.
> In short, I don't think GPL licensing gets you anything additional in
> terms of getting code open sourced.
But history says otherwise. For example, there's a lot of code in gcc
that is there because the customer was told that if they wanted their
gcc extension (custom back-end, front-end changes, etc) they'd have to
release it under the GPL.
> I think people should avoid GPL licensing their work as a pragmatic
> means of ensuring maximal adoption. Ironically, the FSF understood
> this dynamic which is why they created the Library GPL, now known as
> the Lesser GPL.
There's nothing ironic about it. The FSF seeks to maximize freedom,
so licenses code whichever way works best. Libraries sometimes have
different needs from applications.
Andrew.
Raffael Cavallaro
> There's nothing ironic about it. The FSF seeks to maximize freedom,
> so licenses code whichever way works best. Libraries sometimes have
> different needs from applications.
Which is why I suggest that Pascal's lisp libraries would be more
useful licensed under the LLGPL than the GPL. It's ironic because the
FSF is the creator of the GPL, and even they recognized that the GPL
was a poor fit for libraries which is why they created the Library (now
Lesser) GPL.
--
Raffael Cavallaro
Hyman Rosen
> It's ironic because the FSF is the creator of the GPL,
> and even they recognized that the GPL was a poor fit
> for libraries which is why they created the Library
> (now Lesser) GPL.
The FSF does not believe that the GPL is a poor fit for
libraries. They believe that when there are good non-free
alternatives to free libraries, they should use the LGPL
for the free libraries so that users will have at least
some freedom. When there are no good non-free versions
available, they will use the GPL to maximize freedom for
users.
Tamas K Papp
I disagree -- I don't think that the FSF considers the GPL a "poor
fit" for libraries. Quite the opposite (see [1]). They just
recognized that in certain situations, some people would prefer
something like the LGPL, and I guess that they wanted to give them the
choice. But the GPL is still the option they recommend, even for
libraries.
[1] http://www.gnu.org/licenses/why-not-lgpl.html
Regarding the broader issue (of how people license their libraries): I
think this is an optimization problem where people have heterogeneous
objective functions, and thus trying to convince people to pick
another license is not always a worthwhile.
It is possible that someone using a GPL/LGPL/LLGPL/BSD/MIT/... license
is perfectly aware of the advantages and disadvantages, it is just that
they decided to make a different choice. In which case, threads like these
are unlikely to be fruitful.
Regards,
Tamas
David Kastrup
More pragmatically: they want their licenses to be taken seriously.
That involves being able to go after violations in court and/or
settlements with good chances of success. Licenses covering a work "as
a whole" are hard to press when the material they cover is functionally
a drop-in replacement of existing non-free libraries. That makes "mere
aggregation" a really good defense.
--
David Kastrup
Hyman Rosen
> Licenses covering a work "as a whole" are hard to press
> when the material they cover is functionally a drop-in
> replacement of existing non-free libraries. That makes
> "mere aggregation" a really good defense.
This is completely wrong. The GPL applies to work as a whole
only when the GPL-covered work is made part of a combined
work and that combined work is copied and distributed.
Your statement sounds as if you continue to believe incorrectly
that a program which uses a dynamically linked library covered
by the GPL is subject to the GPL even when it is copied and
distributed without that library. That is not so. Copyright law
is about copying, and when a GPL-covered work is not being copied
and distributed, the GPL cannot come into play. What the program
does when it runs is not relevant for falling under the GPL because
the GPL does not restrict running covered works.
Similarly, mere aggregation is irrelevant to libraries which
are statically linked into programs. Such a combined work is
not a mere aggregation of the library and the other components.
Mere aggregation refers to including a covered work on a medium
of distribution along with other works.
David Kastrup
> On 3/25/2010 10:05 AM, David Kastrup wrote:
>> Licenses covering a work "as a whole" are hard to press
>> when the material they cover is functionally a drop-in
>> replacement of existing non-free libraries. That makes
>> "mere aggregation" a really good defense.
>
> This is completely wrong.
The legal council of the FSF is, as far as I can concern, of different
opinion than you are, and this opinion influences what kind of work they
decide to release under what kind of license.
So whether or not you agree with their reasoning, it is part of the
decisions they make with regard to licensing.
--
David Kastrup
Alexander Terekhov
Hyman Rosen wrote:
[...]
> Similarly, mere aggregation is irrelevant to libraries which
> are statically linked into programs. Such a combined work is
> not a mere aggregation of the library and the other components.
Static linking is "mere aggregation" of (sub)programs with relocation
and symbol resolution done earlier than in the case of dynamic linking.
See also
http://www.rosenlaw.com/Rosen_Ch06.pdf
(Linking to GPL Software)
and
http://www.btlj.org/data/articles/21_04_04.pdf
(SOFTWARE COMBINATIONS UNDER THE GENERAL PUBLIC LICENSE)
regards,
alexander.
P.S. "Every computer program in the world, BusyBox included, exceeds the
originality standards required by copyright law."
Hyman Rosen <hyr...@mail.com> The Silliest GPL 'Advocate'
P.P.S. "Of course correlation implies causation! Without this
fundamental principle, no science would ever make any progress."
Hyman Rosen <hyr...@mail.com> The Silliest GPL 'Advocate'
--
http://gng.z505.com/index.htm
(GNG is a derecursive recursive derecursion which pwns GNU since it can
be infinitely looped as GNGNGNGNG...NGNGNG... and can be said backwards
too, whereas GNU cannot.)
Hyman Rosen
> Static linking is "mere aggregation" of (sub)programs with relocation
> and symbol resolution done earlier than in the case of dynamic linking.
No, static linking results in a combined work since the
elements are chosen with intention and by design, much
as would be the case for stories in an anthology. Mere
aggregation corresponds to shipping a pile of books in
one box.
David Kastrup
It would appear that you are not familiar with the realities of dynamic
linking on UNIX-like operating systems. Dynamically linked libraries
(we are not talking about Windows DLLs here) are carefully versioned and
tend to become incompatible with their predecessors pretty regularly.
That's why you need to compile a program using dynamic libraries with
the corresponding header versions for the API versioning.
It is a quite special case to explicitly load a shared executable (and
call its entry points) for which not particular headers were used in the
preparation of the binary. I do not even know the library/system call
for that.
--
David Kastrup
Raffael Cavallaro
> The FSF does not believe that the GPL is a poor fit for
> libraries.
The release of the Library GPL is an implicit recognition of the fact
that the GPL is a poor fit for libraries. Renaming it to the Lesser GPL
isn't likely to convince anyone old enough to remember, or intelligent
enough to do a little research.
David Kastrup
writes:
> On 2010-03-25 09:51:04 -0400, Hyman Rosen said:
>
>> The FSF does not believe that the GPL is a poor fit for
>> libraries.
>
> The release of the Library GPL is an implicit recognition of the fact
> that the GPL is a poor fit for libraries.
Correction: for equivalents to already existing established libraries.
And the problem is not "poor fit", but "incentive for change".
> Renaming it to the Lesser GPL isn't likely to convince anyone old
> enough to remember, or intelligent enough to do a little research.
A name is a name.
--
David Kastrup
Peter Keller
Not that I really care, and I probably won't post in this thread again,
but the GPL V2 has to say:
"However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable."
So, that covers one not having to ship the glibc sources with your
project just because you linked with it. However, if you have a modified
version of the glibc in your package, then you'd have to make the modified
sources available.
Then it goes on to say:
"This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License."
It is that "permit linking proprietary applications" phrase which is the rub.
It doesn't mention static or dynamic, so one must assume both. Hence, the
LGPL.
If you're still curious, then read the faq:
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
It has a few different scenarios about what it means to link with a GPL library.
Later,
-pete
Alexander Terekhov
Hyman Rosen wrote:
>
> On 3/25/2010 11:18 AM, Alexander Terekhov wrote:
> > Static linking is "mere aggregation" of (sub)programs with relocation
> > and symbol resolution done earlier than in the case of dynamic linking.
>
> No, static linking results in a combined work since the
> elements are chosen with intention and by design, much
Ha ha. So the GPL "mere aggregation" applies only to random
aggregations?
> as would be the case for stories in an anthology. Mere
An anthology is "mere aggregation" of literary works.
> aggregation corresponds to shipping a pile of books in
> one box.
Think of shipping a pile of e-books in own file. That's what static
linking is as far as copyright is concerned because relocation and
symbol resolution are irrelevant details regarding copyright.
Raffael Cavallaro
> I disagree -- I don't think that the FSF considers the GPL a "poor
> fit" for libraries. Quite the opposite (see [1]). They just
> recognized that in certain situations, some people would prefer
> something like the LGPL, and I guess that they wanted to give them the
> choice. But the GPL is still the option they recommend, even for
> libraries.
>
> [1] http://www.gnu.org/licenses/why-not-lgpl.html
I don't put much stock in such rationalizations. IOW, having released
the Library GPL, they realized that it was in many ways superior to the
GPL from both the user and the open source perspective. They've been
backpedaling ever since, and the frankly silly renaming of the Library
GPL to the Lesser GPL is a clear sign of this ongoing attempt at damage
control.
I.e., when I say they recognize that the GPL is a poor fit for
libraries, I'm saying that their actions (release of the LGPL and
subsequent renaming) speak louder and more convincingly than their
words (the link you provide).
>
> Regarding the broader issue (of how people license their libraries): I
> think this is an optimization problem where people have heterogeneous
> objective functions, and thus trying to convince people to pick
> another license is not always a worthwhile.
>
> It is possible that someone using a GPL/LGPL/LLGPL/BSD/MIT/... license
> is perfectly aware of the advantages and disadvantages, it is just that
> they decided to make a different choice. In which case, threads like these
> are unlikely to be fruitful.
I don't think their objective functions differ much from mine. I think
they don't appreciate how the license plays out in the real world.
Those who support the GPL for libraries think that by doing so they
maximize the promotion of open source. I contend that the LGPL or
Apache or APSL license lead to greater amounts of open source because a
GPL library excludes one of the largest pools of possible contributors
- professional developers who work on closed source projects. These
potential contributors will instead either
1. reinvent that particular wheel in a closed source fashion (loss to
free software)
2. use a library with a license that doesn't require any publication
such as the bsd, or mit. (possible loss to free software)
3. use a library with a license that requires publication only of
covered code such as the LGPL, APSL, Apache, etc. Only this last case
inevitably results in more open source.
So by releasing a library under the GPL one provides as many ways for
open source to lose as to win. Choosing the winning path in the first
place by releasing the library under the LGPL/LLGPL/Apache etc. license
leads to the biggest gains for open source. Again, the recognition of
this reality is what led to the Library GPL in the first place. So
people who support the GPL for libraries are unwittingly advocating for
freedom in a way that actually results in less open source.
Even if I don't convince my correspondents here, I do hope that some of
those reading this thread will develop a more nuanced view of open
source licenses. I've said what I have to say, so (undoubtedly much to
your relief), I'll stop.
Alexander Terekhov
Peter Keller wrote:
[...]
> http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
"What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide."
To wit:
http://www.law.washington.edu/LCT/Events/FOSS/MootFacts.pdf
(Moot Court Statements of Fact)
http://www.law.washington.edu/LCT/Events/FOSS/OmegaBrief.pdf
(Omega Plaintiff's Brief)
http://www.law.washington.edu/LCT/Events/FOSS/AlphaBrief.pdf
(Alpha Defendant's Brief)
http://www.law.washington.edu/LCT/Events/FOSS/03.%20Beyond%20the%20Basics%20-%20Moot%20Court.mp3
(Hearing and Q&A)
-------
The Scope of "Derivative Works" as Applied to Software: David Bender
of White & Case LLP and author of Computer Law and Ieuan Mahony of
Holland & Knight LLP will argue the proper scope of "derivative work"
under U.S. copyright law when applied to software, before a panel of
distinguished federal appellate judges:
* HONORABLE WILLIAM C. BRYSON, U.S. Court of Appeals for the
Federal Circuit
* HONORABLE HALDANE ROBERT MAYER, U.S. Court of Appeals for the
Federal Circuit
* HONORABLE MARGARET MCKEOWN, U.S. Court of Appeals for the
Ninth Circuit
-------
It didn't bode well for the copyleft side...
Hyman Rosen
> It would appear that you are not familiar with the realities of dynamic
> linking on UNIX-like operating systems. Dynamically linked libraries
> (we are not talking about Windows DLLs here) are carefully versioned and
> tend to become incompatible with their predecessors pretty regularly.
> That's why you need to compile a program using dynamic libraries with
> the corresponding header versions for the API versioning.
That's irrelevant. If you do not copy and distribute the library as
part of the program, then the license of the library cannot affect
the right to copy and distribute the program. Copyright law does not
care that a program needs a certain version of a library to work
correctly, because copyright law does not care whether or not a
program works at all. It's only copying and distribution that count.
> It is a quite special case to explicitly load a shared executable (and
> call its entry points) for which not particular headers were used in the
> preparation of the binary. I do not even know the library/system call
> for that.
That the text of a program contains indications that the program
will use certain libraries in certain ways is generally irrelevant
to the copyright status of the program. There is generally only one
way to express within the text of a program that the program will
use elements of a library, and therefore that expression is not
copyrightable because it lacks originality as defined by copyright
law - see the Lexmark printer cartridge case
<http://www.mwe.com/index.cfm/fuseaction/publications.nldetail/object_id/e9bc6a89-03dc-4e37-9dba-d3d324d6a94c.cfm>.
To put it more simply, that the program contains "#include "joe-lib.h"'
and 'JOEbits jb;' and 'JOEjob(jb, "hello");' does not generally cause
the text of the program to fall under the copyright of the JOE library,
nor does it cause the compiled binary which dynamically links to the
JOE library to fall under the copyright of the JOE library.
Hyman Rosen
> The release of the Library GPL is an implicit recognition of the fact
> that the GPL is a poor fit for libraries.
No. The LGPL is an attempt to get people to use free libraries
when they might easily use non-free ones instead. It trades
away some of the users' freedom where the alternative might be
that the users get no freedom at all.
Hyman Rosen
> It is that "permit linking proprietary applications" phrase which is the rub.
> It doesn't mention static or dynamic, so one must assume both.
No. It does not matter what the GPL or the LGPL says unless
there is a reason that the license should apply. When a program
is linked dynamically against a library and is copied and
distributed without that library, then the copyright license of
the library is irrelevant because the library is not being copied
and distributed.
That is, when copying and distributing a program, the first thing
to determine is which licenses apply. Only after that do you need
to worry about what those licenses say.
Alexander Terekhov
Wow. Hyman, I agree with you 100% with the caveat that static linking
doesn't change anything. It's mere aggregation, stupid.
Hyman Rosen
> An anthology is "mere aggregation" of literary works.
> Think of shipping a pile of e-books in own file. That's what static
> linking is as far as copyright is concerned because relocation and
> symbol resolution are irrelevant details regarding copyright.
No, both of these statements are wrong. See 17 USC 101
<http://www.copyright.gov/title17/92chap1.html#101>
A “collective work” is a work, such as a periodical issue,
anthology, or encyclopedia, in which a number of contributions,
constituting separate and independent works in themselves, are
assembled into a collective whole.
A “compilation” is a work formed by the collection and assembling
of preexisting materials or of data that are selected, coordinated,
or arranged in such a way that the resulting work as a whole
constitutes an original work of authorship. The term “compilation”
includes collective works.
Hyman Rosen
> Wow. Hyman, I agree with you 100% with the caveat that static
> linking doesn't change anything. It's mere aggregation
Your agreement or disagreement is irrelevant, since even when
your conclusions are correct you seldom arrive at them through
correct reasoning. Your error with respect to static linking
is an example; a statically linked program is not a mere
aggregation of its components.
Alexander Terekhov
Hyman Rosen wrote:
>
> On 3/25/2010 12:00 PM, Alexander Terekhov wrote:
> > An anthology is "mere aggregation" of literary works.
> > ...
> > Think of shipping a pile of e-books in own file. That's what static
> > linking is as far as copyright is concerned because relocation and
> > symbol resolution are irrelevant details regarding copyright.
>
> No, both of these statements are wrong. See 17 USC 101
> <http://www.copyright.gov/title17/92chap1.html#101>
> A “collective work” is a work, such as a periodical issue,
> anthology, or encyclopedia, in which a number of contributions,
> constituting separate and independent works in themselves, are
> assembled into a collective whole.
Why do you think that "assembled" doesn't fall under "mere aggregation"?
>
> A “compilation” is a work formed by the collection and assembling
Why do you think that "collection and assembling" doesn't fall under
"mere aggregation"?
Hyman, please stop ignoring the facts.
Facts such as
http://www.redhat.com/licenses/rhel_us_3.html
"LICENSE AGREEMENT AND LIMITED PRODUCT WARRANTY RED HAT® ENTERPRISE
LINUX® AND RED HAT® APPLICATIONS
This agreement governs the use of the Software and any updates to the
Software, regardless of the delivery mechanism. The Software is a
collective work under U.S. Copyright Law. "
Note that Red Hat's collective work contains tons of non-GPL components
even "incompatible" with the GPL.
Alexander Terekhov
Sez who?