Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > The Industry choice

Reply
Thread Tools

The Industry choice

 
 
Robert Kern
Guest
Posts: n/a
 
      01-07-2005
Alex Martelli wrote:

> 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
http://www.velocityreviews.com/forums/(E-Mail Removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
 
Reply With Quote
 
 
 
 
Paul Rubin
Guest
Posts: n/a
 
      01-07-2005
(E-Mail Removed) (Alex Martelli) writes:
> > 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) ...?


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.
 
Reply With Quote
 
 
 
 
Paul Rubin
Guest
Posts: n/a
 
      01-07-2005
Bulba! <(E-Mail Removed)> writes:
> 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.
 
Reply With Quote
 
Bulba!
Guest
Posts: n/a
 
      01-07-2005
On 6 Jan 2005 19:01:46 -0500, (E-Mail Removed) (Aahz) wrote:

>>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.


>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..




--
It's a man's life in a Python Programming Association.
 
Reply With Quote
 
Jeff Shannon
Guest
Posts: n/a
 
      01-07-2005
Paul Rubin wrote:
> Jeff Shannon <(E-Mail Removed)> writes:
>
>>Note that the so-called 'viral' nature of GPL code only applies to
>>*modifications you make* to the GPL software.

>
>
> 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.)

>>(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.)

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

 
Reply With Quote
 
Jeff Shannon
Guest
Posts: n/a
 
      01-07-2005
Bulba! wrote:

> On 6 Jan 2005 19:01:46 -0500, (E-Mail Removed) (Aahz) wrote:
>
>
>>>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.

>
>
>>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?


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

 
Reply With Quote
 
Jeff Shannon
Guest
Posts: n/a
 
      01-07-2005
Alex Martelli wrote:

> Jeff Shannon <(E-Mail Removed)> wrote:
>
>>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"!



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

 
Reply With Quote
 
Scott Robinson
Guest
Posts: n/a
 
      01-07-2005
On Fri, 07 Jan 2005 12:06:42 -0800, Jeff Shannon <(E-Mail Removed)>
wrote:

>Bulba! wrote:
>
>> On 6 Jan 2005 19:01:46 -0500, (E-Mail Removed) (Aahz) wrote:
>>
>>
>>>>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.

>>
>>
>>>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?

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

 
Reply With Quote
 
Stefan Axelsson
Guest
Posts: n/a
 
      01-07-2005
Bulba! wrote:

> 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,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
 
Reply With Quote
 
Bulba!
Guest
Posts: n/a
 
      01-09-2005
On 6 Jan 2005 20:07:19 -0500, (E-Mail Removed) (Aahz) wrote:

>>Nope. That is not what I'm arguing. Really, I think you have
>>jumped to conclusion about that: I merely pointed out that
>>I don't like what I perceive as end effect of what GPL license
>>writers are attempting to achieve: vendor lock-in.
>>
>>I think I stated that clearly.

>
>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.



--
It's a man's life in a Python Programming Association.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
c++ as choice for long term application choice. miles.jg C++ 16 11-14-2007 03:43 PM
VHDL or Verilog, which one is more porpular in industry?Thanks, Lee VHDL 2 05-05-2004 08:24 PM
Can Choice components respond to keyboard input like HTML Choice components? Mickey Segal Java 0 02-02-2004 10:59 PM
Choice of DHCP-server? Is the "IOS-one" a good choice? Fred Cisco 1 12-11-2003 06:25 AM
Entry level postion in Synthesis, design or EDA industry Vishal VHDL 0 11-14-2003 01:09 AM



Advertisments