logo       
Google Custom Search
    AddThis Social Bookmark Button

Re: Fw: Re: Persistence, UI, etc.: msg#00065

Subject: Re: Fw: Re: Persistence, UI, etc.
On Thu, Mar 10, 2005 at 08:09:36PM +0100, Robin Sonefors wrote:
> 
> Actually, you are not allowed to ship GPL:ed code together with
> BSD-code. They aren't compatible with each other. If one use the
> Linux-kernel, the user would have to fetch that themselves.

Actually, the discussion of what one can and can not do with software is
best left to those who have absolutely no attachment to reality.

The problem lies in the definiton of a "derivative work". Consider a
work A, and a potentially "derivative" work B. When does B become
"derivative"? The GPL is pretty good about saying that if A library, and
B statically links with it, then B is a derivative work. This is a dumb
definition, but whatever.

Now, what if I don't statically link, but do a shared link instead?
Well, B still uses A; they just are not in the same file. Is it still a
derivative work?

Or, what if A is a library, but it's written in Python. Well, the
linking here is performed by the ascii bytes "import A" in the sources
of B. Does this make B a derivative work?

Maybe that doesn't count because a python executable is also a python
source code. But, what if I distributed just the .pyc from B? It's the
same program, just in a more easilly parsed binary format. How about
now?

What if I told you it is possible to reconstruct the .py source from a
.pyc bytecode, complete with names and all? It's possible; only the
comments can not be restored. Is that .pyc still a derivative work?
Would running an obfuscator on the source or the bytecode change this?

The only conclusion we can draw here is that people who are worried
about this sort of thing should be shot.



Try Searching:
servers, voip, java, networking, microsoft ...
<Prev in Thread] Current Thread [Next in Thread>