The Industry choice

[Robert Kern]

.
.
.



With my mathematical background, I'm consistent about calling
these "non-open" rather than "closed". I don't insist others
adopt my nomenclature ...

I'm with Cameron on this one.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Steve Holden]

Err, but what did I do that got you visibly pissed off?

I certainly did not mean offending anyone. If I did smth
that did, I apologize, but honestly I didn't mean that. I
just expressed my opinion and cited some small bits of evidence,
which I think I'm entitled to.

I am probably not as pissed off as you might think, but I'm beginning to
find (what I regard as) your naivety a little irritating. However,
nothing I have said was intended to question your integrity.

[...]

And you are using this example to try and argue that engineers are
better-educated than sales people?

Nope. The context was that behavior of companies tends to
be highly rational, optimized and not wasting resources. My
naturally individual experience was that it was oft not the case,
and that was the example.

Well, anyone who *does* believe that companies are managed in a way
that's any more rational than the way individual humans manage their own
lives is deluding themselves. But perhaps I'm a little clearer now about
*your* thinking on this.

Which was my point when explaining the clustering that
demonstrably happened: if the behavior of decisionmakers
is highly informed, rational and not really induced much by
risk avoidance as Alex claims, then the clusters are created
by "natural economic forces".

The agent of economic forces, however, are always individual humans. It
just isn't possible to factor them out.

However, if the process is not that rational, then maybe
clusters are the correlation of "cover your ass" aspect
in managers' behavior all wanting to get their branch office
in yesterday in Tokyo, today in Beijing, and during
speculative craze in Russia in Moscow "because everybody
is doing that". Which observations of Paul Krugman on
"defective investors" seem to support.

Now, I'm very strongly opposed to saying that all that
somehow invalidates economics, including economics
of software, as _science_.

All I'm saying is that maybe this particular model is not
what some people think it is. This is the problem with
economics, people tend to get hot under the collar about
it for some reason and it's oft hard to debate that calmly.
Which personally I find a pity, because e.g. economics
of software is such an interesting subject..
I can live with that, I guess.



I have no idea, as I were not a manager there and it
didn't really pertain my work.

I was merely trying to point out that the sales people may well have
worked a flanker on the "better educated" engineers who might have
bought the plant.

But there is a subtler point here: most likely it was NOT in the
short-term personal interest to make this mistake (as I believe
corruption was not the case in this decision)!

After all, whoever responsible was still running the considerable risk
of getting fired. It is an example that precisely negates either
collective or individual, long-term or short-term, interest was
primary factor in this decision.

Well, you would know better than me, but believe me when I say that such
decisions being made for the economic benefit of a single individual are
far from rare.

Which in economic terms could mean that your "utility function"
is "modeled" in this particular way (well, strictly speaking utility
functions regard simple consumption), while most people tend
to misunderstand it as the idea that supposedly is "vulgar
consumption of as much stuff as possible is what makes people
happy" and they feel rightly repulsed from such an idiotic idea.
The trouble is, well-informed people do not to argue that, while
people tend to think economists actually do...

Well, even assuming I were to allow that such an intellectual thing as a
utility function were to apply to my behavior in this case (which would
be allowing economists more credence than I believe most of them
deserve, but what the heck), all we are really taking about is that "it
takes all sorts to make a world".

I'm as fond of what money can buy as the next guy, but there are still
limits on what I will do to acquire it.

So really a utility function is a very dry and abstract way of looking
at human behavior, and is simply incapable (at the present stage of the
game) of modeling human behavioral complexity.

regards
Steve

 

[Stefan Axelsson]

I've read Novell license of internal development tools it provides
(which I reviewed for some purpose). This is I think relevant
part:

I'm not saying licenses like you claim don't exist. Sure,
they may exist and they suck.

The point is, they have _limited impact_ and by
the very fact of their "exclusion" nature, this
aspect tends to repel users than attract them to
use this thing.

Well, as I didn't catch that we were discussing development tools but
even so, I thought the license you quoted rather strengthened my point
in the section on 'reverse engineering?. (Then again I've seen other's
where that was not the case, was it MS (?) quite a few years back that
didn't allow you to develop an OS using their tool chain? And that was a
binary license.) If you look at actual end user program licenses (such
as Solaris/wxWorks etc) the picture is much clearer.

In any case, it's somewhat beside the point as even the license you
chose to quote took away precisely all those rights that the GPL grants
you. You weren't allowed to (in any way shape or form) to communicate
anything you knew about that source to anyone else.

And I don't buy into your argument that a use of some source code would
go against the 'intended' use by making it GPL. How the hell am I
supposed to know what the author 'intends' if he doesn't tell me?
Especially if, of all the available licenses, choses one that explicitly
permits the sort of use that I envision? I mean, it's not as if many BSD
fans complain that MS took much TCP/IP related code and put it in
Windows (ftp etc). Without sharing anything back with the community. If
that's OK, how am I supposed to know that my use isn't?

It's just the same situation as when I lock my house. That's intended as
a means of communication with the rest of society. It communicates my
intent that I'm not home (or don't want to be disturbed) and that I
don't want them in the house, and it does so more strongly than mere
social convention does. There are after all several members of community
that needs this reminder; notably children. It's emphatically not to
keep thieves out (much) as they won't be much hampered by the ordinary lock.

If you don't want me to use your code in the way I envision then tell
me. The license is the *perfect* place to do so.

Stefan,

 

[Alex Martelli]

There's no obstacle to doing that with GPL'd software either.

Absolutely -- as long as you don't redistribute, np. But Roel was not
asking about GPL, he was asking about closed-source licenses -- whether
any of them "allow using the [[source]] code *at all*" -- and the answer
is that, yes, quite a few do, in specifically constrained ways.


Alex

 

[Alex Martelli]

I'm with Cameron on this one.

There is no "official" definition of closed-source as there is of
open-source, but I'm with the Wikipedia:

http://en.wikipedia.org/wiki/Closed_source

"any program whose licensing terms do not qualify as open source".

I'm not disputing it would be useful to draw many distinctions within
the universe of programs with non-opensource licenses, just pointing out
that such distinctions are not currently reflected in a popular
definition. Since it's a wiki, it may be worthwhile editing it to add
some materials to start influencing popular usage and perception, maybe.


Alex

 

[Alex Martelli]

Suppose they want to ensure "no forking" or that "bugfixes
and enhancements of original software are given back".

OK, LGPL is fine for this goal. When you say "they see it

Neither LGPL nor GPL can ``ensure "no forking"'', nor can any other
open-source license.


Alex

 

[Alex Martelli]

Note that the so-called 'viral' nature of GPL code only applies to
*modifications you make* to the GPL software. The *only* way in which
your code can be 'infected' by the GPL is if you copy GPL source. ...
(Problems may come if someone licenses a library under the GPL; that's
what the LGPL was invented for. But the issue here is not that the
GPL is bad, it's that the author used the wrong form of it.)

Stallman now says that you should use GPL, not Lesser GPL.

http://www.gnu.org/licenses/why-not-lgpl.html

Specifically, he wants library authors to use GPL to impose the viral
nature of GPL on other programs just USING the library -- the very
opposite of what you say about "only applies ... if you copy"!

Quoting RMS from that URL (about Readline, a GPL library):
'''
Releasing it under the GPL and limiting its use to free programs gives
our community a real boost. At least one application program is free
software today specifically because that was necessary for using
Readline.
'''

Until some judge passes some judgment, the intent and effect of GPL must
remain a matter of opinion. But RMS's opinion is probably more
meaningful than mine or yours -- certainly regarding intent, given his
role in designing that license. If he's badly erred, and one day a
judge endorses your opinion and says that a program which copies no GPL
source cannot be infected by GPL, ah well -- then I guess GPL is badly
designed as to putting its intents into practice. But until there is
some strong basis to think otherwise, I believe it's prudent to assume
RMS is probably right, and your statement therefore badly wrong.


Alex

 

[Robert Kern]

There is no "official" definition of closed-source as there is of
open-source, but I'm with the Wikipedia:

http://en.wikipedia.org/wiki/Closed_source

"any program whose licensing terms do not qualify as open source".

A definition with a nice big "This article may need to be reworded to
conform to a neutral point of view" warning at the top. ;-)

I'm not disputing it would be useful to draw many distinctions within
the universe of programs with non-opensource licenses, just pointing out
that such distinctions are not currently reflected in a popular
definition. Since it's a wiki, it may be worthwhile editing it to add
some materials to start influencing popular usage and perception, maybe.

There seems to be such an edit on the way:

http://en.wikipedia.org/wiki/Talk:Closed_source

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Paul Rubin]

A definition with a nice big "This article may need to be reworded to
conform to a neutral point of view" warning at the top. ;-)
...
There seems to be such an edit on the way:
http://en.wikipedia.org/wiki/Talk:Closed_source

After they're done defining closed source, maybe they can work on
"compact source" (a bounded closed-source program, i.e. one that,
unlike Windows, doesn't try to take over every computer in the world).
Note also from the Heine-Borel theorem that every closed source
program can be covered by some finite collection of open source
programs.

 

[Alex Martelli]

Note also from the Heine-Borel theorem that every closed source
program can be covered by some finite collection of open source
programs.

Every _compact_ one, surely? Quoting by heart from old memories, but,
isn't Heine-Borel about (being able reduce any open covering of X to a
finite subcovering) <-> (X is compact) ...?


Alex

 

[Robert Kern]

Until some judge passes some judgment, the intent and effect of GPL must
remain a matter of opinion. But RMS's opinion is probably more
meaningful than mine or yours -- certainly regarding intent, given his
role in designing that license.

But it may not have practical effect in an actual dispute. I believe
that in some jurisdictions[1], the important piece of information in
interpreting a license is the common understanding of what the license
means between the disputing parties. The author of the license, if he is
not one of the disputing parties, has no say in what the license means
for that dispute.

[1] IANAL; TINLA. This is from my memory of what I read in Lawrence
Rosen's book[2] that I don't have in front of me right now. See his
book, chapter 12, I think, for more details.

[2] http://www.rosenlaw.com/oslbook.htm

If he's badly erred, and one day a
judge endorses your opinion and says that a program which copies no GPL
source cannot be infected by GPL, ah well -- then I guess GPL is badly
designed as to putting its intents into practice. But until there is
some strong basis to think otherwise, I believe it's prudent to assume
RMS is probably right, and your statement therefore badly wrong.

I've always found, especially in light of what I wrote above, the best
thing to do is to ask the author himself what he wants. If he subscribes
to an unreasonable interpretation of the license, it's better that you
found out quickly and avoid getting sued even though you might end up
winning. You also avoid inadvertantly stepping on anyone's toes and
garnering ill-will even if you never go to court.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Paul Rubin]

Every _compact_ one, surely? Quoting by heart from old memories, but,
isn't Heine-Borel about (being able reduce any open covering of X to a
finite subcovering) <-> (X is compact) ...?

Yeah, whoops, that's what I meant; your old memories are clearer than
mine. Actually sometimes the definitions and theorems interchange.

I do remember something about Tikhonov's Theorem that says that no
matter how often bounded closed source programs multiply, the product
is still closed source. So, for example, Adobe Acrobat is still
closed source even if you can download it from Adobe's web site
infinitely often. But that theorem doesn't apply to noncompact
(i.e. unbounded) closed source programs. So ordering Microsoft to
release parts of Windows as open source was one of the potential
remedies discussed in the penalty phase of the US Justice Dept's
antitrust suit. Unfortunately, the DoJ lawyers were not good
topologists so they didn't give enough consideration to this
possibility.

 

[Paul Rubin]

From the viewpoint of looking at availability of source code A,
it's completely irrelevant if those guys are fishmongers or
make derived work A' and redistribute only binary of A'. Not
a single line of publicly available source code appeared or
disappeared as the result of whatever they do. Amounts of
binaries - yes, that is affected. But not the source code.

From the viewpoint of the availability of Adobe Photoshop, it's
completely irrelevant if I run off a few hundred thousand copies on CD
in a warehouse by the waterfront and then sell them out of the back of
a truck at the flea market. Not a single shrink-wrapped retail copy
of Photoshop disappeared from any stores as the result. But Adobe
will still send the US Marshals to raid my operation with guns and
stuff. I don't think you would approve of my illicit Photoshop
replication either.

So why should the situation be any different with GPL code? If
someone wants to copy it, they need to do so according to the license.

 

[Bulba!]

That's not true -- consider linking to a GPL library.

Will someone please explain to me in simple terms what's
the difference between linking to LGPLed library and linking
to GPLed library - obviously in terms of consequences of
what happens to _your_ source code?

Because if there isn't any, why bother with distinguishing
between the two?

Oh, and by the way - since Python bytecode can be relatively
easily decompiled to source, could it interpreted to "really"
count as source code and not binary? What are the consequences
of releasing code _written in Python_ as GPLed?

Licenses are frigging cans of worms..

 

[Jeff Shannon]

Well, only under an unusually broad notion of "modification".

True enough. It can be difficult, in software development, to define
a distiction between a situation where two software products are
distinct but cooperative, and a situation where one software product
is derivative of another. Stallman has chosen a particular definition
for use in the GPL; one may debate the value of using this definition
over any other possible definition, but the line had to be drawn
*somewhere*. (And given Stallman's philosophies, it shouldn't be too
surprising that he's drawn it about as broadly as he reasonably could.)

The "problem" is not a problem except that in the case of some
libraries, simply being able to use a library module is often not
enough incentive to GPL a large application if the library module's
functionality is available some other way (including by
reimplemntation). If the library does something really unique and
difficult, there's more reason to GPL it instead of LGPL'ing it.

To my mind, the intent of the GPL is "use it, but if you change it or
make a derivative, share the changes". With libraries, though, you
*can't* use it without hitting the FSF-specified definition of a
derivative. The LGPL exists to make it clear that, for libraries, the
common meaning of "using" and "changing" are different than they are
for applications.

Of course, there's nothing that stops people from insisting that, if
you *use* their libraries, anything you use them for must be
free-as-in-speech (which is the effect of using the GPL instead of the
LGPL); it's the author's choice what restrictions should be put on the
software. But the usage-restrictions on a library under GPL are more
severe than they are on an application under GPL. The unfortunate
thing, in my opinion, is that a fair number of library authors don't
think about that when they GPL their code.

Jeff Shannon
Technician/Programmer
Credit International

 

[Jeff Shannon]

Will someone please explain to me in simple terms what's
the difference between linking to LGPLed library and linking
to GPLed library - obviously in terms of consequences of
what happens to _your_ source code?

Because if there isn't any, why bother with distinguishing
between the two?

Releasing a product in which your code is linked together with GPL'ed
code requires that your code also be GPL'ed. The GPL goes to some
lengths to define what exactly "linked together" means.

Releasing a product in which your code is linked together with LGPL'ed
code does *not* require that your code also be (L)GPL'ed. Changes to
the core library must still be released under (L)GPL, but application
code which merely *uses* the library does not. (I've forgotten, now,
exactly how LGPL defines this distinction...)

Jeff Shannon
Technician/Programmer
Credit International

 

[Jeff Shannon]

Stallman now says that you should use GPL, not Lesser GPL.

http://www.gnu.org/licenses/why-not-lgpl.html

Specifically, he wants library authors to use GPL to impose the viral
nature of GPL on other programs just USING the library -- the very
opposite of what you say about "only applies ... if you copy"!

Ah, I haven't kept up on Stallman's current opinions, and was speaking
from the understanding I had of GPL/LGPL as of a number of years ago
(before that article was written).

By "copy", above, I meant "use GPL source in your product". The GPL
defines what it means to use source in a rather inclusive way. That
inclusiveness means that the standard usage of libraries falls under
their definition of "using source". This distinction in the normal
terms of "usage" is what impelled the FSF to create the LGPL in the
first place...

So, I think what I said still (mostly) stands, as long as you look at
it in terms of whether object code is copied into your executable.
It's still true that one can use (in a consumer sense) GPL software
for whatever purpose one wishes, and the restrictions only kick in
when one includes GPL code in another product. Indeed, I should have
used the word "include" rather than "copy"...

(It's hardly surprising that Stallman wants to use whatever leverage
he can get to encourage FSF-style free software...)

Jeff Shannon
Technician/Programmer
Credit International

 

[Scott Robinson]

Releasing a product in which your code is linked together with GPL'ed
code requires that your code also be GPL'ed. The GPL goes to some
lengths to define what exactly "linked together" means.

That looks like a typo. The LGPL goes to great length to how you can
link to LGPL software without using either the LGPL or GPL. The GPL
(linked to by fsf.org) merely states:

2. You may modify your copy or copies of the Program or any
portion of it, thus forming a work based on the Program, and
copy and distribute such modifications or work under the terms
of Section 1 above, provided that you also meet all of these
conditions:

Note that the conditions are all those of any program released under
the GPL. Whatever "forming a work based on the Program" means is
whatever you and the copyright owner agree to, or whatever copyright
law considers a derived work in areas you wish to release your code
into. I would suggest consulting a lawyer before getting close to the
line, but you can expect that any legally enforceable restrictions
claimed by FSF and/or RMS to be legally binding on all software
released under the (L)GPL that the FSF owns the copyright of (they
encourage programmers to sign over copyright to the FSF itself).

Releasing a product in which your code is linked together with LGPL'ed
code does *not* require that your code also be (L)GPL'ed. Changes to
the core library must still be released under (L)GPL, but application
code which merely *uses* the library does not. (I've forgotten, now,
exactly how LGPL defines this distinction...)

Jeff Shannon
Technician/Programmer
Credit International

Scott Robinson

 

[Stefan Axelsson]

Oh, and by the way - since Python bytecode can be relatively
easily decompiled to source, could it interpreted to "really"
count as source code and not binary? What are the consequences
of releasing code _written in Python_ as GPLed?

Well, to your first question, in a word 'no', it wouldn't count as
source code. To quote the GPL section 3:

"The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source code
means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to control
compilation and installation of the executable."

As the preferred form for making changes to Python programs would be
Python source, that's what counts. This is also what forbids obfuscated
code. If you were to *write* Python bytecode, as a form of assembly,
then of course that's another matter.

I've released Python source as GPL and as far as I'm concerned it ought
to work, even though that's not explicitly covered. As the only way
you're going to receive my program is by receiving the source then
you'll end up having it and everything's basically OK. If someone tries
to make a binary from that and distribute that without also making the
source available then the GPL obviously comes into effect, and the game
is up. I haven't sought legal (or FSF) input on this matter though, it's
just my understanding. You can be fairly confident that the GPL is iron
clad though, it would have been dragged through every court in the land
by now if it wasn't.

I've also followed the LGPL/GPL library debate, and while I have
opinions on that as well, this is getting long in the tooth already.

Stefan,

 

[Bulba!]

And my counter-argument is that I believe your perception is wrong. If
I agreed with your focus on lock-in, I'd say that what the GPL is trying
to lock in is a specific legal philosophy by subverting the existing
system.

If it finally turns out that I'm wrong on this and GPL does not have
that kind of economic "vendor lock-in" _effect_ behind it (note:
effect, not intent), I will be only happy to see that. Re subverting
existing legal philosophy, I could not care less.

Obviously the only reason that I argued that way is that given
the info that I have it simply looks like that from my viewpoint.