[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bad license on VCG?



On Fri, Aug 30, 2002 at 10:31:52PM -0500, Jeff Licquia wrote:

> > > Consider the case where a GPLed program is distributed with .o files
> > > that are linked in at link time.  The author could say, under the same
> > > logic and with a straight face, that the .o is "the preferred form for
> > > modification".
> > 
> > They could, and we'd laugh at them. The point is that we would be perfectly
> > within our rights to distribute it, and that whether or not we chose to do
> > so would be an entirely separate question.
> 
> Please point out exactly which section of the GPL would grant us such
> rights.  Remember, rights not explicitly granted are withheld under
> default copyright law.

  1. You may copy and distribute verbatim copies of the Program's
source code as you receive it,

See, we're fine.

  2. You may modify your copy or copies of the Program or any portion
of it,

Also fine.

As I said, I think all those who are saying otherwise are guilty of
confusing what we're allowed to do with what we want to do.


> > > C source code is not "special" or "magic"; it is not metaphysically
> > > classified by God as source code.  The question as to whether the code
> > > is source is properly answered by referring to the definition in the
> > > GPL: does anyone really modify the particular file directly when they
> > > want to change the program's behavior?  In the case of obfuscated
> > > source, the answer clearly is "no".

Wrong. The original author may not, but since this is the best source we
have received, it's exactly that that we'd modify.

Look again at the GPL chunks I quoted, paying particular attention to
'as you receive it' and 'your copy'.

>  Thus, the obfuscated C file is
> > > "object code", no matter what language specification it technically
> > > adheres to.

Surely you jest.


> Well, the author's stated definition of "source" is "the preferred form
> for modifying a work".  Since the .o (or the obfuscated C) isn't the
> preferred form for modifying the work, we cannot fulfill the conditions
> for distribution, since we cannot provide the preferred form for
> modifying those C files.

Again you are bringing into the equation something which as far as we are
concerned does not exist (the original commented unobfuscated source).


> > > Now, in this case, there's no real foul; the author has just chosen a
> > > contradictory license, which means that no one really knows what the
> > > distribution conditions are.

It's not contradictory; it's perfectly clear.


> The author does not consider the obfuscated C files to be source.  How
> do I know?  I read the author's license statement, which reads:
> 
> "The source code for a work means the preferred form of the work for
> making modifications to it."

And given the package with which we have been provided, that is the obfuscated
C.


> > Quite. But in this case there is no such obligation on the author. The only
> > question is what *we* could and should do with it.
> 
> I notice you clipped the "no foul" part, where I agree with you.  The
> author is not obligated to do anything.  Are you trying to manufacture a
> debate where none exists?

Um, it wasn't me who started claiming that we *can't* distribute this package.


> I also note that you agree with me on the definition of "source" when a
> third party's rights are involved.

The definition of source is "the preferred form of the work for making
modifications", selected from those forms which are available to you.


> > What I'm claiming is that he didn't intend to do something that he knew he
> > had no power to do in the first place.
> 
> Which is what?

Force authors to reveal anything, at all.


> You seem to be confusing obligations on the author with license
> consistency.

No, I don't.

>  We cannot take the GPL and use it against the author to
> force him/her to reveal the non-obfuscated source (unless the author
> used third-party GPL code).  However, we can point out the logical
> contradiction in the license the author has granted, and state that we
> do not know what our rights are.

There IS NO CONTRADICTION. You may be confused, so feel free to ask the
author what your rights are (hell, I certainly can't stop you ;). I'm
pretty sure that they will point out exactly what I have. They do want
to license under the GPL, but they also want to at least discourage
modifications to the files in question.

They might like to prevent such modifications, but presumably value the
ability to distribute under the GPL slightly more highly.


> Now, this whole mess can be straightened out if the author provides a
> license that allows the obfuscated C source to be used.  They could
> provide, for example, a GPL exception statement to that effect.  One
> could claim that such a statement is implicit; one would, I think, have
> to be a lawyer to make such a claim, however.

It's not a mess; there are just several over-zealous people here who are
seeing what they would like to see (a legal reason why we can't distribute
this) rather than what is actually before them (a potentially tricky question
which needs to be answered by Debian developers as a whole, not just those
who participate here).

This, whilst understandable, is not desirable.


> If you don't believe me, think for a minute about why this code couldn't
> be linked to third-party GPLed code (which you've already admitted) and
> distributed.

By us, as an extra modification, it could. By the original author (which is
what we previously discussed), it couldn't.

>  If we claim that implicit permission is given to link to
> the obfuscated C source, then we are claiming that the "real" license
> isn't the GPL; 

It's not implicit. It's just as explicit as any other time stuff is released
under the GPL.


> Now that we've determined that the GPL does not describe the whole
> license, we now have to figure out what the license is.

But it does.


> Of course, we both know that it's not terribly likely that any of this
> will happen.  But we don't deal with "likelihoods" in Debian, or try to
> "second-guess" people; we expect them to tell us frankly what they want
> and don't want.  Look at the whole KDE situation; the copyright holders
> for KDE were practically begging everyone to accept a particular
> implicit addition to the license all along, and many distributions went
> along with it.  We did not, however.  Thankfully, that particular mess
> is all in the past; it should be persuasive to you, however, concerning
> how Debian deals with these questions.

In this particular case, given the material which the author has distributed,
it is crystal-clear what they want. Whether or not we go ahead and do what
they want (i.e. distribute it) is the question, and should be answered
alsewhere.


Cheers,


Nick
-- 
Nick Phillips -- nwp@lemon-computing.com
Another good night not to sleep in a eucalyptus tree.



Reply to: