Re: gens License Check - Non-free

[Nathanael Nerode]

Michael Poole wrote:

> Raul Miller writes:
> 
>> Because the linux kernel does not represent mere aggregation of one part
>> of the kernel with some other part on some storage volume.
>>
>> It's not a coincidence that the parts of the kernel are there together.
> 
> The usual contention is that having some helper function load the
> firmware is sufficient to resolve the concern.  That suggests to me
> that the parts being together -- at least in that case -- is a matter
> of convenience, not of necessity.  That is what I would use to test
> for "mere aggregation" (when one is not a derivative work of the
> other).

In some of the cases, rewriting the driver to have a helper function load
the firmware is actually a complicated process involving major changes to
the driver to 'detangle' the firmware.  The 'tangled' version doesn't seem
like mere aggregation.

-- 
There are none so blind as those who will not see.

Re: gens License Check - Non-free

[Patrick Herzig]

On Fri, 2004-06-18 at 21:01, Michael Poole wrote:
> Michael Poole writes:
> 
> > What does the primary purpose have anything to do with it?  When I buy
> > a new computer, I do it because I want the functionality it offers --
> > not because it is a distribution medium for software.
> 
> To tie that into GPL: Does that mean that if I buy a machine
> pre-installed with GPL'ed software, the GPL demands that all the other
> parts of that computer be GPL'ed?  Being a distribution medium is a
> convenient side effect of the computer; it is not the primary purpose.

To stick to my premise of approaching legal texts, yes, unlike a CD,
where the storage medium character is obvious, we have to look further
here. I would argue that with its hard drives and all, being a storage
medium is in fact an aspect of a computer and thus the "mere
aggregation" clause applies.

For the Linux kernel to be a storage medium we have to look even further
(and I'm afraid we won't find anything there).

-Patrick

Re: gens License Check - Non-free

[Patrick Herzig]

On Fri, 2004-06-18 at 20:47, Michael Poole wrote:
> Patrick Herzig writes:
> 
> > The question is if the Linux kernel itself can be interpreted as being a
> > "storage or distribution medium". Storage or distribution of binary
> > blobs is at least not the primary purpose of the Linux kernel as it
> > would be much easier to just store or distribute them on tape.
> 
> What does the primary purpose have anything to do with it?  When I buy
> a new computer, I do it because I want the functionality it offers --
> not because it is a distribution medium for software.

This statement was not intended to be a complete argument for or against
anything. It is part of an exploratory approach at interpreting a legal
document. This first statement makes it clear that if the Linux kernel
is to be interpreted as a storage medium this interpretation has to
based on something else than the primary purpose and one has to look
further (unlike a tape or CD where storage is indeed the primary
purpose).

> > Also, the Linux kernel is, unlike a tape or a CD, not really suitable
> > for storing or distributing binary blobs as it is (in that sense)
> > intangible and needs to be attached to a medium to be stored or
> > distributed.
> 
> I don't follow.  Does this line of argument mean that a Debian mirror
> server or archive violates the GPL, since Debian too is intangible?

It simply means that I have doubts about the storage medium quality of
the Linux kernel as of its intangible nature. We should approach the
question if Debian as a whole can be subsumed under "storage medium"
when (and if) the question comes up. (This is unlikely as the
"intangible Debian", unlike the Linux kernel, keeps its packages
reasonably seperate so that we can rely on the respective medium Debian
is distributed on to invoke the "mere aggregation" clause.)

-Patrick

Re: gens License Check - Non-free

[Brian Thomas Sniffen]

Humberto Massa <[EMAIL PROTECTED]> writes:

> @ 18/06/2004 11:41 : wrote Brian Thomas Sniffen :
>
>  >Now let's say I start distributing WinFoo with wine.  This is a
>  >compilation derivative of his compilation.  It's clearly not mere
>  >aggregation, as the two pieces combine to produce a single work.
>  >If I publish an anthology of short stories, that's a compilation.
>  >If one of them is written to be a prequel or sequel to another,
>  >then it is a derived work of that other.  If they *all* have that
>  >relation to one another, I'm publishing what's probably a joint
>  >work.
>  >
>
> This is the problem: why is it not mere aggregation? where is the
> transformation??!!

I have taken characters, plots, and other expressions of original
ideas, transformed them, and written into the prequel or sequel.  That
story is derivative of the original story.

Additionally, the compilation of all the stories is more than mere
aggregation on a storage medium: it's not just that I'm putting these
all on my bookshelf, but that I'm printing them all together, selected
as complementary reading material.

>  >>First, compilation != derivative work, AFAIK.
>  >
>  >
>  >Yes, not all compilations are derivative works.  Some are.  If you
>  >want to press the claim that most software is compilations, that's
>  >fine -- we just end up talking about derivative works of
>  >compilations instead of derivative works of simple original works
>  >in a lot of cases.
>  >
>
> No. Compilations/anthologies are NOT derivative works OF THE PARTS.
> All compilations/anthologies are derivative works OF EARLIER
> EDITIONS OF THE SAME ANTHOLOGIES. Thus, Linux-2.6.7 is a derivative
> work of Linux-2.6.6, but is *not* a derivative work of the
> kernel/drivers/usb/unusual_devs.h (whatever the real name) that is
> included there. It's an anthology work. The work to make the
> anthology is select/organize/dispose its contents, and its contents
> are *separate* works.

Yes.  I think this was unclear to many people here early on, and I'm
very grateful to you and the others who made it explicit.

>  Being derivative is a property of a work, not a property of its
>  distribution.
>
> YES! Yes! Being derivative has a very fixed meaning: begin the
> result of some transformation.
>
>  >>>
>  >>>And it is that property of the combined work to which the FSF
>  >>>objects -- no matter how tricky the instructions are about who
>  >>>does the combination. >>It is to be expected that the FSF argues
> for as broad an
>  >>intepretitation of the GPL as they can without breaking out
>  >>laughing...
>
> As I said, I don't take the "do not link" GPL disposition at face
> value. The intelligent thing to do is to follow Linus' lead and
> regard derivative works when treating the GPL.

Then where do we get permission to distribute compilations which are
not "mere aggregation" of GPL'd and GPL-incompatible work?

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: gens License Check - Non-free

[Michael Poole]

Michael Poole writes:

> What does the primary purpose have anything to do with it?  When I buy
> a new computer, I do it because I want the functionality it offers --
> not because it is a distribution medium for software.

To tie that into GPL: Does that mean that if I buy a machine
pre-installed with GPL'ed software, the GPL demands that all the other
parts of that computer be GPL'ed?  Being a distribution medium is a
convenient side effect of the computer; it is not the primary purpose.

Michael

Re: gens License Check - Non-free

[Michael Poole]

Patrick Herzig writes:

> The question is if the Linux kernel itself can be interpreted as being a
> "storage or distribution medium". Storage or distribution of binary
> blobs is at least not the primary purpose of the Linux kernel as it
> would be much easier to just store or distribute them on tape.

What does the primary purpose have anything to do with it?  When I buy
a new computer, I do it because I want the functionality it offers --
not because it is a distribution medium for software.

> Also, the Linux kernel is, unlike a tape or a CD, not really suitable
> for storing or distributing binary blobs as it is (in that sense)
> intangible and needs to be attached to a medium to be stored or
> distributed.

I don't follow.  Does this line of argument mean that a Debian mirror
server or archive violates the GPL, since Debian too is intangible?

Michael

Re: gens License Check - Non-free

[Patrick Herzig]

I'm sorry, I messed something up with my mailer in the previous message.
This reply is in the correct thread (see below quote).

On Fri, 2004-06-18 at 19:39, Michael Poole wrote:
> Raul Miller writes:
> 
> > Because the linux kernel does not represent mere aggregation of one part
> > of the kernel with some other part on some storage volume.
> >
> > It's not a coincidence that the parts of the kernel are there together.
> 
> The usual contention is that having some helper function load the
> firmware is sufficient to resolve the concern.  That suggests to me
> that the parts being together -- at least in that case -- is a matter
> of convenience, not of necessity.  That is what I would use to test
> for "mere aggregation" (when one is not a derivative work of the
> other).

In such discussions it is often useful to go back to the actual basis of
the text in question. The "mere aggregation" statement in the GPL is:

"In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of a
storage or distribution medium does not bring the other work under the
scope of this License."

The "mere aggregation" is specified here as being on a volume of a
storage or distribution medium. It seems to me that the intended scope
of the exception is to allow one to give a tape or CD to others and
fully utilise the space on the medium by also putting other stuff on the
same medium.
This surely includes putting several works on the same medium because
they complement each other (like, say, a distribuiton like Debian).

The question is if the Linux kernel itself can be interpreted as being a
"storage or distribution medium". Storage or distribution of binary
blobs is at least not the primary purpose of the Linux kernel as it
would be much easier to just store or distribute them on tape.
Also, the Linux kernel is, unlike a tape or a CD, not really suitable
for storing or distributing binary blobs as it is (in that sense)
intangible and needs to be attached to a medium to be stored or
distributed.

In my opinion it takes some serious word-bending to apply the "mere
aggregation" clause to things contained in the Linux kernel.

-Patrick

Re: gens License Check - Non-free

[Michael Poole]

Raul Miller writes:

> Because the linux kernel does not represent mere aggregation of one part
> of the kernel with some other part on some storage volume.
>
> It's not a coincidence that the parts of the kernel are there together.

The usual contention is that having some helper function load the
firmware is sufficient to resolve the concern.  That suggests to me
that the parts being together -- at least in that case -- is a matter
of convenience, not of necessity.  That is what I would use to test
for "mere aggregation" (when one is not a derivative work of the
other).

Michael

Re: gens License Check - Non-free

[Alexander Cherepanov]

18-Jun-04 12:55 Humberto Massa wrote:
> @ 18/06/2004 12:49 : wrote Raul Miller :

>>  On Fri, Jun 18, 2004 at 12:12:13PM -0300, Humberto Massa wrote:
>>
>> > This is the problem: why is it not mere aggregation? where is the
>> > transformation??!!
>>
>>
>>  Why is this a problem?

> *because* the GPL exempts "mere aggregation"

Exactly. It exempts "mere aggregation", not collections. Roughly
speaking, it's an author who defines its meaning, not copyright law.

Sasha

Re: gens License Check - Non-free

[Raul Miller]

> >  Why is this a problem?

On Fri, Jun 18, 2004 at 12:55:47PM -0300, Humberto Massa wrote:
> *because* the GPL exempts "mere aggregation"

> >  The GPL excercises the right to control the distribution of
> >  collective works based on GPLed code. It grants an exception, but
> >  that exception doesn't apply to the linux kernel.

> why not?

Because the linux kernel does not represent mere aggregation of one part
of the kernel with some other part on some storage volume.

It's not a coincidence that the parts of the kernel are there together.

> That's where my question demands an answer: where is the 
> transformation? When you show me the transformation, it's a derived 
> work; when you show me aggregation of parts, it's exempted by the GPL.

Why is this important?  Which transformations are you specifically
asking about?  What is their legal significance?

Thanks,

-- 
Raul

Re: gens License Check - Non-free

[Humberto Massa]

@ 18/06/2004 12:49 : wrote Raul Miller :


 On Fri, Jun 18, 2004 at 12:12:13PM -0300, Humberto Massa wrote:

> This is the problem: why is it not mere aggregation? where is the
> transformation??!!


 Why is this a problem?

 The GPL excercises the right to control the distribution of
 collective works based on GPLed code. It grants an exception, but
 that exception doesn't apply to the linux kernel.



*And* you forgot to put the context (nothing to to with the Linux kernel):


>Now let's say I start distributing WinFoo with wine.  This is a
>compilation derivative of his compilation.  It's clearly not mere
>aggregation, as the two pieces combine to produce a single work.
>If I publish an anthology of short stories, that's a compilation.
>If one of them is written to be a prequel or sequel to another,
>then it is a derived work of that other.  If they *all* have that
>relation to one another, I'm publishing what's probably a joint
>work.
>



If someone starts distributing WinFoo with Wine, this is not a 
derivative work of any part. It's a compilation/anthology work. 
Anthologies are not derivatives. Anthologies IRT licensing must respect 
the license of the parts when distributing, but their nature is to 
collect things, and merely aggregate them. The engineering to make 
things work is *not* in the anthology, but _in_ _the_ _parts_.


--
br,M

Re: gens License Check - Non-free

[Humberto Massa]

@ 18/06/2004 12:49 : wrote Raul Miller :


 On Fri, Jun 18, 2004 at 12:12:13PM -0300, Humberto Massa wrote:

> This is the problem: why is it not mere aggregation? where is the
> transformation??!!


 Why is this a problem?


*because* the GPL exempts "mere aggregation"



 The GPL excercises the right to control the distribution of
 collective works based on GPLed code. It grants an exception, but
 that exception doesn't apply to the linux kernel.



why not? That's where my question demands an answer: where is the 
transformation? When you show me the transformation, it's a derived 
work; when you show me aggregation of parts, it's exempted by the GPL.


--
br,M

Re: gens License Check - Non-free

[Raul Miller]

On Fri, Jun 18, 2004 at 12:12:13PM -0300, Humberto Massa wrote:
> This is the problem: why is it not mere aggregation? where is the
> transformation??!!

Why is this a problem?

The GPL excercises the right to control the distribution of collective
works based on GPLed code.  It grants an exception, but that exception
doesn't apply to the linux kernel.

-- 
Raul

Re: gens License Check - Non-free

[Humberto Massa]

@ 18/06/2004 11:41 : wrote Brian Thomas Sniffen :

>Now let's say I start distributing WinFoo with wine.  This is a
>compilation derivative of his compilation.  It's clearly not mere
>aggregation, as the two pieces combine to produce a single work.
>If I publish an anthology of short stories, that's a compilation.
>If one of them is written to be a prequel or sequel to another,
>then it is a derived work of that other.  If they *all* have that
>relation to one another, I'm publishing what's probably a joint
>work.
>

This is the problem: why is it not mere aggregation? where is the
transformation??!!

>>First, compilation != derivative work, AFAIK.
>
>
>Yes, not all compilations are derivative works.  Some are.  If you
>want to press the claim that most software is compilations, that's
>fine -- we just end up talking about derivative works of
>compilations instead of derivative works of simple original works
>in a lot of cases.
>

No. Compilations/anthologies are NOT derivative works OF THE PARTS.
All compilations/anthologies are derivative works OF EARLIER
EDITIONS OF THE SAME ANTHOLOGIES. Thus, Linux-2.6.7 is a derivative
work of Linux-2.6.6, but is *not* a derivative work of the
kernel/drivers/usb/unusual_devs.h (whatever the real name) that is
included there. It's an anthology work. The work to make the
anthology is select/organize/dispose its contents, and its contents
are *separate* works.

Being derivative is a property of a work, not a property of its
distribution.

YES! Yes! Being derivative has a very fixed meaning: begin the
result of some transformation.

>>>
>>>And it is that property of the combined work to which the FSF
>>>objects -- no matter how tricky the instructions are about who
>>>does the combination. 
>>It is to be expected that the FSF argues for as broad an

>>intepretitation of the GPL as they can without breaking out
>>laughing...

As I said, I don't take the "do not link" GPL disposition at face
value. The intelligent thing to do is to follow Linus' lead and
regard derivative works when treating the GPL.

--
br,M

Re: gens License Check - Non-free

[Brian Thomas Sniffen]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> On Tue, Jun 15, 2004 at 08:35:23PM -0400, Brian Thomas Sniffen wrote:
>> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
>> 
>> > On Jun 14, 2004, at 22:25, Brian Thomas Sniffen wrote:
>> >>
>> >> I'm not sure I buy the argument that WinFoo is a derivative work of
>> >> Windows.  Surely WinFoo, shipped with Windows, is.
>> >
>> > Either it is or isn't. You create a derivative work (or don't create a
>> > derivative work) when you create a work.
>> 
>> Yes.  And this picture of a Gnu is not a derivative work of Emacs.
>> But if I package it with Emacs as the Emacs icon, the combination
>> IconEmacs is a derivative work of Emacs -- and of my iconic gnu.
>
> How so? To quote Title 17 Sec. 101:
>
>   A ''derivative work'' is a work based upon one or more preexisting
>   works, such as a translation, musical arrangement, dramatization,
>   fictionalization, motion picture version, sound recording, art
>   reproduction, abridgment, condensation, or any other form in which a
>   work may be recast, transformed, or adapted. A work consisting of
>   editorial revisions, annotations, elaborations, or other
>   modifications which, as a whole, represent an original work of
>   authorship, is a ''derivative work''.
>
> Replacing a PNG file doesn't fit that definition at all. We have
> "recast, transformed, or adapted" neither EMACS nor your icon. Neither
> has actually changed. Changing that icon isn't an original work of
> authorship, either. The closest we've come is to creating a compilation:

Part of Emacs has changed.  I have not changed the C source for Emacs,
but I have changed Emacs -- it is a compilation, of documentation, C
code, lisp code, and many other things.  The FSF owns the copyright on
all those components and on the compilation itself.  When I replace
the icon, I have created a new compilation which is a derived work of
the old compilation.

>   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.
>
> But once again, a compilation needs to be original. Which replacing a
> single icon most probably isn't.

Sure it is -- as original as the compilation from which it derived.

Is it not possible to have a work which is both a compilation and a
derived work?

> Also, 103(b):
>The copyright in a compilation or derivative work extends only to
>the material contributed by the author of such work, as
>distinguished from the preexisting material employed in the work
>[...]
>
> "the material contributed by the author of such work", i.e., nothing.
>
> (Of course, the icon itself could be an original work of authorship. But
> we're not talking about that).

No, I am talking about the contribution of compiling a bunch of the
parts of Emacs with this other part, the icon.

> Ummm... You've switched between Wine and Windows several times above; I
> assume that wasn't intended... I'll just read everything as "Windows."

No, I meant to switch in several places, but I think I did get at
least one wrong.  More explicitly, and I hope correctly:

The author wrote WinFoo.  He had in mind either Windows or wine when
he wrote it.  Let's say Windows.  He has thus created and expressed in
a fixed form (when he installed the program on his windows machine) a
compilation, which consists of WinFoo and Windows.  He might
distribute this compilation, which requires him to have licenses to do
such from the authors of WinFoo (himself) and Windows (MS).  MS won't
give him that license, though they will give him a license to
distribute WinFoo for linking with Windows.

Now let's say I start distributing WinFoo with wine.  This is a
compilation derivative of his compilation.  It's clearly not mere
aggregation, as the two pieces combine to produce a single work.  If I
publish an anthology of short stories, that's a compilation.  If one
of them is written to be a prequel or sequel to another, then it is a
derived work of that other.  If they *all* have that relation to one
another, I'm publishing what's probably a joint work.

> First, compilation != derivative work, AFAIK.

Yes, not all compilations are derivative works.  Some are.  If you
want to press the claim that most software is compilations, that's
fine -- we just end up talking about derivative works of compilations
instead of derivative works of simple original works in a lot of cases.

> Second, it can't be a compilation because installing Windows software on
> Windows isn't an original work of authorship. Also, the rest of 103(b):
>
>   The copyright in [a compilation] is independent of, and does not
>   affect or enlarge the scope, duration, ownership, or subsistence of,
>   any co

Re: gens License Check - Non-free

[Andrew Suffield]

On Thu, Jun 17, 2004 at 03:16:46PM -0400, Anthony DeRobertis wrote:
> > > Being derivative is a property of a work, not a property of its
> > > distribution.
> > 
> > And it is that property of the combined work to which the FSF objects
> > -- no matter how tricky the instructions are about who does the combination.
> 
> It is to be expected that the FSF argues for as broad an intepretitation
> of the GPL as they can without breaking out laughing...

Why? I think you're thinking of a different FSF to the "Oh, you don't
really need to edit *that*" one.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: gens License Check - Non-free

[Anthony DeRobertis]

On Tue, Jun 15, 2004 at 08:35:23PM -0400, Brian Thomas Sniffen wrote:
> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> 
> > On Jun 14, 2004, at 22:25, Brian Thomas Sniffen wrote:
> >>
> >> I'm not sure I buy the argument that WinFoo is a derivative work of
> >> Windows.  Surely WinFoo, shipped with Windows, is.
> >
> > Either it is or isn't. You create a derivative work (or don't create a
> > derivative work) when you create a work.
> 
> Yes.  And this picture of a Gnu is not a derivative work of Emacs.
> But if I package it with Emacs as the Emacs icon, the combination
> IconEmacs is a derivative work of Emacs -- and of my iconic gnu.

How so? To quote Title 17 Sec. 101:

A ''derivative work'' is a work based upon one or more preexisting
works, such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which a
work may be recast, transformed, or adapted. A work consisting of
editorial revisions, annotations, elaborations, or other
modifications which, as a whole, represent an original work of
authorship, is a ''derivative work''.

Replacing a PNG file doesn't fit that definition at all. We have
"recast, transformed, or adapted" neither EMACS nor your icon. Neither
has actually changed. Changing that icon isn't an original work of
authorship, either. The closest we've come is to creating a compilation:

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.

But once again, a compilation needs to be original. Which replacing a
single icon most probably isn't.

Also, 103(b):
 The copyright in a compilation or derivative work extends only to
 the material contributed by the author of such work, as
 distinguished from the preexisting material employed in the work
 [...]

"the material contributed by the author of such work", i.e., nothing.

(Of course, the icon itself could be an original work of authorship. But
we're not talking about that).

> Taping, no.  But if I'm distributing WinFoo with wine, such that
> they're installed and working together -- say, some ATM software and
> an OS -- then either that ATM package is a compilation which includes
> Windows, and so is a derivative work, or is not and is instead
> including Wine and a derivative work of that.

Ummm... You've switched between Wine and Windows several times above; I
assume that wasn't intended... I'll just read everything as "Windows."

First, compilation != derivative work, AFAIK.

Second, it can't be a compilation because installing Windows software on
Windows isn't an original work of authorship. Also, the rest of 103(b):

The copyright in [a compilation] is independent of, and does not
affect or enlarge the scope, duration, ownership, or subsistence of,
any copyright protection in the preexisting material

Even if somehow install ATM Software on Windows creates a compilation,
as long as I have appropriate licenses to Windows and the ATM software,
it doesn't matter; Sec. 106 doesn't lsit creating a compilation as one
of the exclusive rights of a copyright holder.

> 
> > Being derivative is a property of a work, not a property of its
> > distribution.
> 
> And it is that property of the combined work to which the FSF objects
> -- no matter how tricky the instructions are about who does the combination.

It is to be expected that the FSF argues for as broad an intepretitation
of the GPL as they can without breaking out laughing...

Re: gens License Check - Non-free

[Humberto Massa]

@ 15/06/2004 23:09 : wrote Evan Prodromou :

>>"BTS" == Brian Thomas Sniffen <[EMAIL PROTECTED]> writes:
>
>
>BTS> Yes.  And this picture of a Gnu is not a derivative work of
>BTS> Emacs.  But if I package it with Emacs as the Emacs icon, the
>BTS> combination IconEmacs is a derivative work of Emacs -- and of
>BTS> my iconic gnu.
>
>This is counterintuitive. There's a connection here between collection
>and derivation that's somewhat difficult to wrap my head around,
>though.
>
>If I write a short story "Evan's Story", that is an independent work,
>on its own. If I submit that story to Atlantic Monthly, the story
>becomes part of the collective work "Atlantic Monthly, June 2004
>issue."
>
>If I then make the short story into a play "Evan's Play", it doesn't
>make much intuitive sense to say that "Evan's Play" is derived from
>"Atlantic Monthly, June 2004 issue". And it seems even stranger to say
>that "Evan's Play" is a derivative work of "Atlantic Monthly, April
>1961" or "Atlantic Monthly, December 2018".
>
>~ESP
>


I don't know about USC 17, but in Brazilian Author's rights law,
derivative works, collective works and anthology (or compilation works)
are three much different beasts:

1. derivative works are those which are intellectual creations of their
own, results of the _transformation_ on the originary work; they don't
exist in their current form independently of the originary work *and*,
most importantly, you _transformed_ the originary work in the derivative
work (this history step -- transformation) is the keyword. The best
example of this is egcs, that was a derivative work on gcc.

2. anthology (or compilation) works are those which are the fusion of
authonomous works, but are an independent intellectual creation itself
by means of its selection, organization, of content disposition. Theo de
Raadt catalogues his OpenBSD CDs in this category, and claims copyrights
on the selection/organization/disposition of the otherwise (dfsg-)free
contents of the CDs.

3. collective works are the fusion of autonomous works, that don't have
the caracteristics of (2) above.

In your example, "Atlantic Monthly June 2004 issue" would be situated in
the cases (2) OR (3) above, and is not a derivative work on "Evan's
Story". What you did is to transform "Evan's Story" in "Evan's Play".
Thus, "Evan's Play" is the derivative work on "Evan's Story". Period.

As additional examples, I would say: gcc-3.1 is a derivative work on
gcc-3.0; WineX is a derivative work on Wine; and so on.

--
br,M

Re: gens License Check - Non-free

[Evan Prodromou]

> "BTS" == Brian Thomas Sniffen <[EMAIL PROTECTED]> writes:

BTS> Yes.  And this picture of a Gnu is not a derivative work of
BTS> Emacs.  But if I package it with Emacs as the Emacs icon, the
BTS> combination IconEmacs is a derivative work of Emacs -- and of
BTS> my iconic gnu.

This is counterintuitive. There's a connection here between collection
and derivation that's somewhat difficult to wrap my head around,
though.

If I write a short story "Evan's Story", that is an independent work,
on its own. If I submit that story to Atlantic Monthly, the story
becomes part of the collective work "Atlantic Monthly, June 2004
issue."

If I then make the short story into a play "Evan's Play", it doesn't
make much intuitive sense to say that "Evan's Play" is derived from
"Atlantic Monthly, June 2004 issue". And it seems even stranger to say
that "Evan's Play" is a derivative work of "Atlantic Monthly, April
1961" or "Atlantic Monthly, December 2018".

~ESP

-- 
Evan Prodromou
Email: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]

Re: gens License Check - Non-free

[Ken Arromdee]

On Tue, 15 Jun 2004, Brian Thomas Sniffen wrote:
> > Being derivative is a property of a work, not a property of its
> > distribution.
> And it is that property of the combined work to which the FSF objects

No, it isn't.

The FSF doesn't prohibit derivatives (of GPL works and proprietary works
together).  Rather, the FSF prohibits *distributing* derivatives.  In other
words, the reason that distribution matters is not because being a derivative
is somehow dependent on being distributed--rather, the reason that it matters
is that distribution is separately and explicitly mentioned.

And "being a derivative" is a property of a work.  "Being a derivative which
has been distributed" is not really a property of the work alone, but rather
a property of the work plus its history.  A series of instructions which result
in the same work but with a different history might change things.

Re: gens License Check - Non-free

[Brian Thomas Sniffen]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> On Jun 14, 2004, at 22:25, Brian Thomas Sniffen wrote:
>>
>> I'm not sure I buy the argument that WinFoo is a derivative work of
>> Windows.  Surely WinFoo, shipped with Windows, is.
>
> Either it is or isn't. You create a derivative work (or don't create a
> derivative work) when you create a work.

Yes.  And this picture of a Gnu is not a derivative work of Emacs.
But if I package it with Emacs as the Emacs icon, the combination
IconEmacs is a derivative work of Emacs -- and of my iconic gnu.

> Taping a copy of WinFoo to a copy of Windows doesn't change the
> copyright status of either work. I don't see how putting them on a CD
> together could, either.

Taping, no.  But if I'm distributing WinFoo with wine, such that
they're installed and working together -- say, some ATM software and
an OS -- then either that ATM package is a compilation which includes
Windows, and so is a derivative work, or is not and is instead
including Wine and a derivative work of that.

> Being derivative is a property of a work, not a property of its
> distribution.

And it is that property of the combined work to which the FSF objects
-- no matter how tricky the instructions are about who does the combination.

>>> Anyway, why isn't Wine a derivative work of Windows if every program
>>> that uses the Windows API is?
>>
>> Wine shares nothing but facts -- the API -- with Windows.  It is an
>> entirely different expression of the same idea.  Programs linking to
>> libraries are, it is claimed, derivative because you need the library
>> included in there to make the combined work.
>
> I'm not quite sure how using the Windows API by calling it would make
> a derivative of Windows, while using it by implementing it
> wouldn't. It's the same API after all.

And it's the only implementation of that API -- and so uncreative and
not copyrightable.  But if I give you the left half of Ulysses,
suggesting that you just, you know, find the other half somewhere,
the FSF suggests that *one* of us is commiting copyright infringement
by combining those halves.

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: gens License Check - Non-free

[Anthony DeRobertis]

On Jun 14, 2004, at 22:25, Brian Thomas Sniffen wrote:


I'm not sure I buy the argument that WinFoo is a derivative work of
Windows.  Surely WinFoo, shipped with Windows, is.


Either it is or isn't. You create a derivative work (or don't create a 
derivative work) when you create a work.


Taping a copy of WinFoo to a copy of Windows doesn't change the 
copyright status of either work. I don't see how putting them on a CD 
together could, either.


Being derivative is a property of a work, not a property of its 
distribution.



Anyway, why isn't Wine a derivative work of Windows if every program
that uses the Windows API is?


Wine shares nothing but facts -- the API -- with Windows.  It is an
entirely different expression of the same idea.  Programs linking to
libraries are, it is claimed, derivative because you need the library
included in there to make the combined work.


I'm not quite sure how using the Windows API by calling it would make a 
derivative of Windows, while using it by implementing it wouldn't. It's 
the same API after all.

Re: gens License Check - Non-free

[Brian Thomas Sniffen]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> On Mon, Jun 14, 2004 at 11:20:57AM -0400, Brian Thomas Sniffen wrote:
>>
>> FOO is and always was a derivative work of MS Windows.  It was
>> provably such until Wine added that function; after that, it's much
>> harder to prove.
>
> Ah... I though it was being argued that wine's existence somehow made
> something less a derivative work of Winddows, not that it'd be harder to
> proove.
>

I'm not sure I buy the argument that WinFoo is a derivative work of
Windows.  Surely WinFoo, shipped with Windows, is.  But books are not
derivative works of eyes.  Nearly everybody has eyes.  It is expected
that books are written to be used with the Eye interface.  Windows is
similarly ubiquitous

> Anyway, why isn't Wine a derivative work of Windows if every program
> that uses the Windows API is?

Wine shares nothing but facts -- the API -- with Windows.  It is an
entirely different expression of the same idea.  Programs linking to
libraries are, it is claimed, derivative because you need the library
included in there to make the combined work.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: gens License Check - Non-free

[Anthony DeRobertis]

On Mon, Jun 14, 2004 at 11:20:57AM -0400, Brian Thomas Sniffen wrote:
>
> FOO is and always was a derivative work of MS Windows.  It was
> provably such until Wine added that function; after that, it's much
> harder to prove.

Ah... I though it was being argued that wine's existence somehow made
something less a derivative work of Winddows, not that it'd be harder to
proove.

Anyway, why isn't Wine a derivative work of Windows if every program
that uses the Windows API is?

> 
> -Brian
> 
> -- 
> Brian Sniffen   [EMAIL PROTECTED]
> 

Re: gens License Check - Non-free

[Brian Thomas Sniffen]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> On Jun 8, 2004, at 14:56, Andrew Suffield wrote:
>
>> Bad example. There are two implementations of most of the significant
>> win32 libraries - windows and wine. Anything which works on both is a
>> derivative of neither.
>
> That leads to even weirder things.
>
> FOO was a derivative work of M$ Windows until Wine added a function it
> needed to run?

FOO is and always was a derivative work of MS Windows.  It was
provably such until Wine added that function; after that, it's much
harder to prove.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: gens License Check - Non-free

[Anthony DeRobertis]

On Jun 8, 2004, at 14:56, Andrew Suffield wrote:


Bad example. There are two implementations of most of the significant
win32 libraries - windows and wine. Anything which works on both is a
derivative of neither.


That leads to even weirder things.

FOO was a derivative work of M$ Windows until Wine added a function it 
needed to run?

Re: gens License Check - Non-free

[Ken Arromdee]

On Tue, 8 Jun 2004, Edmund GRIMLEY EVANS wrote:
> However, in the case of a a GPL library it is possible to argue that
> the person distributing the program is encouraging people to fetch the
> library from a public server and link it with the program, and
> therefore that person is in effect distributing the GPL library in an
> unlicensed manner.

I don't accept this reasoning (though courts have said stranger things).

I can't tell you "you walked around my yard, but that's just another way of
achieving the same result as walking across my yard, so you're in effect
trespassing."  Just because the outcome is the same does not make the two
scenarios 'in effect' the same.

Re: gens License Check - Non-free

[Andrew Suffield]

On Tue, Jun 08, 2004 at 10:03:38PM +0100, Edmund GRIMLEY EVANS wrote:
> Josh Triplett <[EMAIL PROTECTED]>:
> 
> > > So before Wine was created, anything which uses a Windows library was a
> > > derivative of Windows?
> > 
> > Yes.
> 
> There are so many theories on this subject that I am perpetually
> confused, but I don't think that is what is usually claimed in the
> case of GPL libraries.
> 
> I think the usual claim is that the program that uses the library plus
> the library is a derivative of the library (which is obviously true)
> and also a single work even when the parts are distributed separately
> (which is at least plausible).
> 
> In the case of a typical Windows library that's not a problem because:
> 
> 1. Only Microsoft and its agents are distributing the library.
> 
> 2. The library is not available from public servers.
> 
> 3. There is explicit or implicit permission to link the library with
> arbitrary programs.

That said, I have no problem conceiving of the notion that MS might
change the license to prohibit specific programs from linking to a
given library. Probably as part of a security update.

So the theory holds, but it *could* be a problem. Fortunately it won't
be our problem.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: gens License Check - Non-free

[Edmund GRIMLEY EVANS]

Josh Triplett <[EMAIL PROTECTED]>:

> > So before Wine was created, anything which uses a Windows library was a
> > derivative of Windows?
> 
> Yes.

There are so many theories on this subject that I am perpetually
confused, but I don't think that is what is usually claimed in the
case of GPL libraries.

I think the usual claim is that the program that uses the library plus
the library is a derivative of the library (which is obviously true)
and also a single work even when the parts are distributed separately
(which is at least plausible).

In the case of a typical Windows library that's not a problem because:

1. Only Microsoft and its agents are distributing the library.

2. The library is not available from public servers.

3. There is explicit or implicit permission to link the library with
arbitrary programs.

However, in the case of a a GPL library it is possible to argue that
the person distributing the program is encouraging people to fetch the
library from a public server and link it with the program, and
therefore that person is in effect distributing the GPL library in an
unlicensed manner. There are all kinds of hypothetical circumstances
that might strengthen or weaken that argument. For example:

1. The argument seems stronger in a case where the program and the
library are being distributed by the same person or by people who are
in some way working together.

2. The argument seems weaker in a case where the program is being
distributed in source form only together with an explanation that the
program is for research use only until there is a compatibly licensed
substitute for the library.

Obviously I have no idea in what circumstances the argument might be
accepted by a court in what jurisdictions, but I think that's roughly
what the usual argument is, and it doesn't directly imply anything
about the situation with a typical Windows library.

Re: gens License Check - Non-free

[Glenn Maynard]

On Tue, Jun 08, 2004 at 12:00:21PM -0700, Josh Triplett wrote:
> Also, note that the Linux kernel includes an explicit exception for
> works that simply make system calls; without that exception, software
> that uses any system call specific to Linux would most likely be a
> derived work of the kernel, and would fall under the GPL.

I still wonder if this exception is legitimate--I don't have any real
examples, but with a code base the size of the kernel, I can't imagine
that it hasn't imported any GPL code that hasn't granted this permission,
or that they really did track down old MIA contributors.  (Maybe I have
the wrong impression of the kernel people, and they're more thorough
with respect to licensing than I think.)

-- 
Glenn Maynard

Re: gens License Check - Non-free

[Humberto Massa]

@ 08/06/2004 14:48 : wrote Benjamin Cutler :


Benjamin Cutler wrote:



Searching for "Starscream" somehow managed to miss that page. I'll 
check it out.





Eh, it's the same thing from before. Different addy, but just about 
the same content. I'm going to look into replacing the m68k core. 
Probably from UAE, since that's a pretty tested core. :p





*this* checking out is ok. but and the other (easier)? maybe Neill 
Corlett is willing to GPL or BSD/2cl the code for us... why not ask?


--
br,M

Re: gens License Check - Non-free

[Josh Triplett]

Ken Arromdee wrote:
> On Tue, 8 Jun 2004, Andrew Suffield wrote:
>>>The FSF's position here is well-known, but has some odd implications.  For
>>>instance, if you write code that requires Windows libraries, it is a 
>>>derivative
>>>work of Windows, and thus Microsoft can at any time prohibit you from
>>>distributing it.
>>
>>Bad example. There are two implementations of most of the significant
>>win32 libraries - windows and wine. Anything which works on both is a
>>derivative of neither.
> 
> So before Wine was created, anything which uses a Windows library was a
> derivative of Windows?

Yes.

- Josh Triplett

Re: gens License Check - Non-free

[Ken Arromdee]

On Tue, 8 Jun 2004, Andrew Suffield wrote:
> > The FSF's position here is well-known, but has some odd implications.  For
> > instance, if you write code that requires Windows libraries, it is a 
> > derivative
> > work of Windows, and thus Microsoft can at any time prohibit you from
> > distributing it.
> Bad example. There are two implementations of most of the significant
> win32 libraries - windows and wine. Anything which works on both is a
> derivative of neither.

So before Wine was created, anything which uses a Windows library was a
derivative of Windows?

Re: gens License Check - Non-free

[Josh Triplett]

Ken Arromdee wrote:
> On Tue, 8 Jun 2004, Josh Triplett wrote:
> 
>>That is commonly done for packages that allow distribution as source
>>only, or do not allow distribution of binaries built from modified
>>source.  It does not get around the GPL's requirements.  Quoting from
>>http://www.gnu.org/philosophy/pragmatic.html :
>>
>>>Consider GNU Objective C. NeXT initially wanted to make this front
>>>end proprietary; they proposed to release it as .o files, and let
>>>users link them with the rest of GCC, thinking this might be a way
>>>around the GPL's requirements. But our lawyer said that this would
>>>not evade the requirements, that it was not allowed. And so they made
>>>the Objective C front end free software.
> 
> On the other hand, their lawyer is an interested party.  It's like trusting a
> MPAA lawyer to interpret the DMCA for you.

Granted; nice analogy. :)

> The FSF's position here is well-known, but has some odd implications.  For
> instance, if you write code that requires Windows libraries, it is a 
> derivative
> work of Windows, and thus Microsoft can at any time prohibit you from
> distributing it.  (Note that in this scenario the OS exception won't help
> since it would be Microsoft, not the author of any GPL code you use, who would
> be claiming the copyright violation.)

That is a reasonable implication.  I don't know whether licenses are
revocable by default unless stated to be irrevocable, or if they are
irrevocable by default unless stated to be revocable (I think the latter
is true), but either way, it is quite possible for non-free software to
have a revocable license, and for that license to affect derivative
works of that software.  Basically, non-free software could impose any
arbitrary restriction it wants (assuming that contract licenses are
valid).  However, software which is written using a portable library
which works on many different platforms, including Windows, would not be
affected by this.  Furthermore, the existence of wine and winelib
provides a reasonable buffer against claims that a given Windows
application is a derived work of Windows libraries, as long as the given
application works with wine.

Also, note that the Linux kernel includes an explicit exception for
works that simply make system calls; without that exception, software
that uses any system call specific to Linux would most likely be a
derived work of the kernel, and would fall under the GPL.

- Josh Triplett

Re: gens License Check - Non-free

[Andrew Suffield]

On Tue, Jun 08, 2004 at 11:42:12AM -0700, Ken Arromdee wrote:
> On Tue, 8 Jun 2004, Josh Triplett wrote:
> > That is commonly done for packages that allow distribution as source
> > only, or do not allow distribution of binaries built from modified
> > source.  It does not get around the GPL's requirements.  Quoting from
> > http://www.gnu.org/philosophy/pragmatic.html :
> > > Consider GNU Objective C. NeXT initially wanted to make this front
> > > end proprietary; they proposed to release it as .o files, and let
> > > users link them with the rest of GCC, thinking this might be a way
> > > around the GPL's requirements. But our lawyer said that this would
> > > not evade the requirements, that it was not allowed. And so they made
> > > the Objective C front end free software.
> 
> On the other hand, their lawyer is an interested party.  It's like trusting a
> MPAA lawyer to interpret the DMCA for you.
> 
> The FSF's position here is well-known, but has some odd implications.  For
> instance, if you write code that requires Windows libraries, it is a 
> derivative
> work of Windows, and thus Microsoft can at any time prohibit you from
> distributing it.

Bad example. There are two implementations of most of the significant
win32 libraries - windows and wine. Anything which works on both is a
derivative of neither.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: gens License Check - Non-free

[Ken Arromdee]

On Tue, 8 Jun 2004, Josh Triplett wrote:
> That is commonly done for packages that allow distribution as source
> only, or do not allow distribution of binaries built from modified
> source.  It does not get around the GPL's requirements.  Quoting from
> http://www.gnu.org/philosophy/pragmatic.html :
> > Consider GNU Objective C. NeXT initially wanted to make this front
> > end proprietary; they proposed to release it as .o files, and let
> > users link them with the rest of GCC, thinking this might be a way
> > around the GPL's requirements. But our lawyer said that this would
> > not evade the requirements, that it was not allowed. And so they made
> > the Objective C front end free software.

On the other hand, their lawyer is an interested party.  It's like trusting a
MPAA lawyer to interpret the DMCA for you.

The FSF's position here is well-known, but has some odd implications.  For
instance, if you write code that requires Windows libraries, it is a derivative
work of Windows, and thus Microsoft can at any time prohibit you from
distributing it.  (Note that in this scenario the OS exception won't help
since it would be Microsoft, not the author of any GPL code you use, who would
be claiming the copyright violation.)

Re: gens License Check - Non-free

[Benjamin Cutler]

Benjamin Cutler wrote:


Searching for "Starscream" somehow managed to miss that page. I'll check 
it out.





Eh, it's the same thing from before. Different addy, but just about the 
same content. I'm going to look into replacing the m68k core. Probably 
from UAE, since that's a pretty tested core. :p

Re: gens License Check - Non-free

[Benjamin Cutler]

Josh Triplett wrote:

Benjamin Cutler wrote:


I can't even find the original source page for Starscream any more...



A search for the author's name turns up http://www.neillcorlett.com/ ,
which has a page http://www.neillcorlett.com/star/ about Starscream.
There is an email address on that site's contact page; is it the same
one you already tried?

- Josh Triplett




Searching for "Starscream" somehow managed to miss that page. I'll check 
it out.

Re: gens License Check - Non-free

[Humberto Massa]

@ 08/06/2004 13:58 : wrote Benjamin Cutler :


Humberto Massa wrote:


I can't even find the original source page for Starscream any more...


Other (better!) option would be try the Starscream original author to 
release under a more liberal license (BSD/MIT/2clause or even the 
GPL). As to mpg123, what about mpg321 ??




I should also have mentioned that the e-mail address for Starscream 
bounced when I tried it. So I really have no idea how to reach the guy 
who wrote it in the first place.


I had another idea, though. I've noticed a few packages in contrib 
don't actually assemble the package until postinst... could I seperate 
gens into "gens" (all the GPL code) and "gens-nonfree" (mpg123 and 
Starscream), and have gens postinst call "ld" at install-time? The two 
packages would contain the relevant .o files... and would techinically 
be seperate packages.



You still have to *prove* that the "gens" package is not a derived work 
on the "gens-nonfree" package. Your better bet would be getting another 
m68k emulator to work.


--
br,M

Re: gens License Check - Non-free

[Benjamin Cutler]

Andrew Suffield wrote:


A quick search of the Packages file reveals basilisk2, an emulator for
m68k macs. I know there are more m68k emulators out there, which
haven't been packaged.



Looking at Basalisk it says that it uses UAE's emu core for m68k... 
sounds like it's worth looking into, but porting Gens to use UAE's m68k 
core will *probably* be a non-trivial task. Plus last time I tried to 
build UAE (from official source, not Debian) I got an ICE. This could 
get interesting. ;p

Re: gens License Check - Non-free

[Josh Triplett]

Benjamin Cutler wrote:
> I can't even find the original source page for Starscream any more...

A search for the author's name turns up http://www.neillcorlett.com/ ,
which has a page http://www.neillcorlett.com/star/ about Starscream.
There is an email address on that site's contact page; is it the same
one you already tried?

- Josh Triplett

Re: gens License Check - Non-free

[Josh Triplett]

Benjamin Cutler wrote:
> I had another idea, though. I've noticed a few packages in contrib don't
> actually assemble the package until postinst... could I seperate gens
> into "gens" (all the GPL code) and "gens-nonfree" (mpg123 and
> Starscream), and have gens postinst call "ld" at install-time? The two
> packages would contain the relevant .o files... and would techinically
> be seperate packages.

That is commonly done for packages that allow distribution as source
only, or do not allow distribution of binaries built from modified
source.  It does not get around the GPL's requirements.  Quoting from
http://www.gnu.org/philosophy/pragmatic.html :
> Consider GNU Objective C. NeXT initially wanted to make this front
> end proprietary; they proposed to release it as .o files, and let
> users link them with the rest of GCC, thinking this might be a way
> around the GPL's requirements. But our lawyer said that this would
> not evade the requirements, that it was not allowed. And so they made
> the Objective C front end free software.

I would suggest finding another m68k CPU emulator, and modifying Gens to
use it.  There are several available as part of Free Software system
emulators for systems based on the m68k, such as UAE (found via a quick
Google search, which turned up many more results that looked promising).

- Josh Triplett

Re: gens License Check - Non-free

[Andrew Suffield]

On Tue, Jun 08, 2004 at 10:58:04AM -0600, Benjamin Cutler wrote:
> Humberto Massa wrote:
> >>I can't even find the original source page for Starscream any more...
> >>
> >>
> >Other (better!) option would be try the Starscream original author to 
> >release under a more liberal license (BSD/MIT/2clause or even the GPL). 
> >As to mpg123, what about mpg321 ??
> >
> 
> I should also have mentioned that the e-mail address for Starscream 
> bounced when I tried it. So I really have no idea how to reach the guy 
> who wrote it in the first place.
> 
> I had another idea, though. I've noticed a few packages in contrib don't 
> actually assemble the package until postinst... could I seperate gens 
> into "gens" (all the GPL code) and "gens-nonfree" (mpg123 and 
> Starscream), and have gens postinst call "ld" at install-time? The two 
> packages would contain the relevant .o files... and would techinically 
> be seperate packages.

Intent is what counts. You can't try to find loopholes like this
unless you have an expensive lawyer.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: gens License Check - Non-free

[Andrew Suffield]

On Tue, Jun 08, 2004 at 11:01:23AM -0600, Benjamin Cutler wrote:
> Andrew Suffield wrote:
> >
> >No amount of hoop-jumping will help you here. It's still clearly a
> >derivative work of starscream.
> >
> 
> Not even something like what I mentioned in my other message? Seperating 
> the source packages wouldn't help either?

No. It's still a derivative work. There can exist no transformations
on the source which would change this that do not involve writing or
replacing code - that's more or less definitive.

> >m68k is not a difficult chip to emulate, and there are plenty of other
> >emulators for it out there. There's probably something which could
> >replace it, resulting in a package which is both distributable and
> >DFSG-free (given that mpg123 is easy to replace).
> >
> 
> I'd be willing to tackle this if you were able to point one out, it 
> seems the only ones I could find weren't any more DSFG-free than Starscream.

A quick search of the Packages file reveals basilisk2, an emulator for
m68k macs. I know there are more m68k emulators out there, which
haven't been packaged.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: gens License Check - Non-free

[Benjamin Cutler]

Andrew Suffield wrote:


No amount of hoop-jumping will help you here. It's still clearly a
derivative work of starscream.



Not even something like what I mentioned in my other message? Seperating 
the source packages wouldn't help either?



m68k is not a difficult chip to emulate, and there are plenty of other
emulators for it out there. There's probably something which could
replace it, resulting in a package which is both distributable and
DFSG-free (given that mpg123 is easy to replace).



I'd be willing to tackle this if you were able to point one out, it 
seems the only ones I could find weren't any more DSFG-free than Starscream.


I really want to see this package in Debian, can you tell? ;p

Re: gens License Check - Non-free

[Benjamin Cutler]

Humberto Massa wrote:

I can't even find the original source page for Starscream any more...


Other (better!) option would be try the Starscream original author to 
release under a more liberal license (BSD/MIT/2clause or even the GPL). 
As to mpg123, what about mpg321 ??




I should also have mentioned that the e-mail address for Starscream 
bounced when I tried it. So I really have no idea how to reach the guy 
who wrote it in the first place.


I had another idea, though. I've noticed a few packages in contrib don't 
actually assemble the package until postinst... could I seperate gens 
into "gens" (all the GPL code) and "gens-nonfree" (mpg123 and 
Starscream), and have gens postinst call "ld" at install-time? The two 
packages would contain the relevant .o files... and would techinically 
be seperate packages.

Re: gens License Check - Non-free

[Andrew Suffield]

On Tue, Jun 08, 2004 at 09:58:57AM -0600, Benjamin Cutler wrote:
> Humberto Massa wrote:
> >Well, it is if you yank off the non-GPL parts. If you meant the
> >_pristine_, untouched source tarball, yes, it's not distributable.
> >
> >If gens is still usable/useful without the non-free parts, you can
> >package it this way (/vide/ all the flam^W healthy discussions about
> >the non-free parts in the kernel over this list).
> >
> 
> The mpg123 portions would probably be replacable with SMPEG with some 
> work, but Starscream is the main CPU emulation core, so, no, that won't 
> work. MAYBE I could figure out some way to split it off as a non-free 
> shared library and have gens depend on it... that might be worth looking 
> into.

No amount of hoop-jumping will help you here. It's still clearly a
derivative work of starscream.

m68k is not a difficult chip to emulate, and there are plenty of other
emulators for it out there. There's probably something which could
replace it, resulting in a package which is both distributable and
DFSG-free (given that mpg123 is easy to replace).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: gens License Check - Non-free

[Humberto Massa]

@ 08/06/2004 12:58 : wrote Benjamin Cutler :


Humberto Massa wrote:


Well, it is if you yank off the non-GPL parts. If you meant the
_pristine_, untouched source tarball, yes, it's not distributable.

If gens is still usable/useful without the non-free parts, you can
package it this way (/vide/ all the flam^W healthy discussions about
the non-free parts in the kernel over this list).



The mpg123 portions would probably be replacable with SMPEG with some 
work, but Starscream is the main CPU emulation core, so, no, that 
won't work. MAYBE I could figure out some way to split it off as a 
non-free shared library and have gens depend on it... that might be 
worth looking into.


I can't even find the original source page for Starscream any more...


Other (better!) option would be try the Starscream original author to 
release under a more liberal license (BSD/MIT/2clause or even the GPL). 
As to mpg123, what about mpg321 ??


--
br,M

Re: gens License Check - Non-free

[Lewis Jardine]

Benjamin Cutler wrote:


Brian Thomas Sniffen wrote:


Not only is that non-free, it may not be distributable.  A single
work, parts of which are GPL'd and parts of which are non-free, can't
be distributed because the GPL requires that the entire thing be under
the terms of the GPL.

-Brian



I guess I'm missing something, I just read through the GPL and I'm 
having trouble locating the specific clause that states this... not that 
I'm doubting you, I just was not aware of this.


As I understand it (IANAL) :

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

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License."

Causes the conditions of the GPL to apply to the entire work (in 
addition to any restrictions that any code from a third-party may 
already have)


"  6. ...You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License."

Means that if any restrictions imposed by the third party are in 
addition to restrictions in the GPL, the derived work is in 
contravention of the license on the GPL code


"  7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  *If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.*..."

Together with 2b and 6, 7 means that a work combining parts licensed 
under the starscream license and the GPL is not distributable.



However, it may be possible to get the upstream authors (if there really 
are only two as the readme suggests) to add a special exception allowing 
linking with mp3dec and starscream. This would make the work 
distributable in non-free.




Would this mean that even the source tarball is not distributable as well?


In my opinion, the starscream processor emulator can be reasonably 
considered an independent and separate work in itself, thus the GPL does 
not apply to the starscream source files. Similarly, there is no 
starscream code in the GPL files, thus the starscream license does not 
apply to the GPL files. The same applies with GPL/starscream and the 
mp3dec license. Thus the source tarball can be distributed (in my opinion).


As I understand it, individual source files are not derived works of 
each other, merely aggregated in the same archive. This means that the 
source tarball is distributable, as long as all the files containing GPL 
code are unmodified, or only have modifications which are licensed under 
the GPL.


"These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.  But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it."

--
Lewis Jardine
IANAL IANADD

Re: gens License Check - Non-free

[Benjamin Cutler]

Humberto Massa wrote:

Well, it is if you yank off the non-GPL parts. If you meant the
_pristine_, untouched source tarball, yes, it's not distributable.

If gens is still usable/useful without the non-free parts, you can
package it this way (/vide/ all the flam^W healthy discussions about
the non-free parts in the kernel over this list).



The mpg123 portions would probably be replacable with SMPEG with some 
work, but Starscream is the main CPU emulation core, so, no, that won't 
work. MAYBE I could figure out some way to split it off as a non-free 
shared library and have gens depend on it... that might be worth looking 
into.


I can't even find the original source page for Starscream any more...

Re: gens License Check - Non-free

[Humberto Massa]

@ 08/06/2004 12:10 : wrote Benjamin Cutler :

> Brian Thomas Sniffen wrote:
>
>> Not only is that non-free, it may not be distributable.  A single
>> work, parts of which are GPL'd and parts of which are non-free,
>> can't be distributed because the GPL requires that the entire
>> thing be under the terms of the GPL.
>>
>> -Brian


Just to nitpick a little: "A single work, parts of which are GPL'd
and parts of which are _GPL_ _incompatible_ in terms of licensing."

If the other parts were GPL compatible, licensing-wise, then the
whole work could be considered GPL'd. (like using a BSD/MIT/2clause
license to a library to be incorporated in a GPL'd program).

> I guess I'm missing something, I just read through the GPL and I'm
> having trouble locating the specific clause that states this...
> not that I'm doubting you, I just was not aware of this.

GPL#6: "Each time you redistribute the Program (or any work based on
the Program), the recipient automatically receives a license from
the original licensor to copy, distribute or modify the Program
subject to these terms and conditions. You may not impose any
further restrictions on the recipients' exercise of the rights
granted herein. You are not responsible for enforcing compliance by
third parties to this License."

What this means is: for some GPLed-code derived work, all the
distributions of such code *must* be done under the terms of the
GPL (non-derived parts may be licensed _if_ _distributed_
_separately_, but if distributed as a single work, the single work
must be distributed under the terms of the GPL, without additional
restrictions on the rights granted by the GPL).


> Would this mean that even the source tarball is not distributable
> as well?

Well, it is if you yank off the non-GPL parts. If you meant the
_pristine_, untouched source tarball, yes, it's not distributable.

If gens is still usable/useful without the non-free parts, you can
package it this way (/vide/ all the flam^W healthy discussions about
the non-free parts in the kernel over this list).

--
best regards, Massa

Re: gens License Check - Non-free

[Brian Thomas Sniffen]

"Benjamin Cutler" <[EMAIL PROTECTED]> writes:

> Brian Thomas Sniffen wrote:
>> Not only is that non-free, it may not be distributable.  A single
>> work, parts of which are GPL'd and parts of which are non-free, can't
>> be distributed because the GPL requires that the entire thing be under
>> the terms of the GPL.
>> -Brian
>>
>
> I guess I'm missing something, I just read through the GPL and I'm
> having trouble locating the specific clause that states this... not
> that I'm doubting you, I just was not aware of this.

The entire work is derived from the code licensed to Debian only under
the GPL.  So this section applies:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  But when you
  distribute the same sections as part of a whole which is a work based
  on the Program, the distribution of the whole must be on the terms of
  this License, whose permissions for other licensees extend to the
  entire whole, and thus to each and every part regardless of who wrote
  it.

> Would this mean that even the source tarball is not distributable as well?

Looks that way, doesn't it?  The original author can distribute this,
because *he* wrote all the bits we have only under the GPL, and so he
isn't bound by this part of the GPL.  But Debian can't distribute this
-- nobody but the original author can do so.  And if he didn't write
100% of the GPL'd parts, he can't distribute it either.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: gens License Check - Non-free

[Benjamin Cutler]

Brian Thomas Sniffen wrote:

Not only is that non-free, it may not be distributable.  A single
work, parts of which are GPL'd and parts of which are non-free, can't
be distributed because the GPL requires that the entire thing be under
the terms of the GPL.

-Brian



I guess I'm missing something, I just read through the GPL and I'm 
having trouble locating the specific clause that states this... not that 
I'm doubting you, I just was not aware of this.


Would this mean that even the source tarball is not distributable as well?

Re: gens License Check - Non-free

[Brian Thomas Sniffen]

Not only is that non-free, it may not be distributable.  A single
work, parts of which are GPL'd and parts of which are non-free, can't
be distributed because the GPL requires that the entire thing be under
the terms of the GPL.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

gens License Check - Non-free

[Benjamin Cutler]

I'm pretty sure the following is at the very least non-free, but I 
wanted to run it by here first because I don't want to waste any more 
time trying to package this unless it can at least go in non-free. I 
already had to close the ITP[1] once I discovered that some of the code 
was lacking a license. Once I was able to track it down, I rebuilt the 
package, but I'm not reopening the ITP until I'm sure it's actually sure 
 this is even packagable. I suspect it is, but no harm in being sure...


Attached is a verbatim copy of the debian/copyright file I put together 
for the package. Most of the code is GPL, but the code from a couple of 
directories falls under other licenses. (I ended up copying the README 
and COPYING from the mpg123 source package, once I found out that was 
where some of the code originally came from.)


[1] http://bugs.debian.org/253095
This package was debianized by Benjamin Cutler <[EMAIL PROTECTED]> on
Sun,  6 Jun 2004 20:22:43 -0700.

It was downloaded from 

Upstream Authors:   Stephane Dallongeville (Win32 Version) ([EMAIL 
PROTECTED])
Stephane Akhoun (SDL Version) ([EMAIL PROTECTED])

See  for more info.

Main code licensed under the GPL.

On Debian systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL'.



src/gens/mp3_dec/* license:



Copyright (c) 1995-99 by Michael Hipp, all rights reserved.
Parts of the software are contributed by other people, please
refer to the README file for details!

DISTRIBUTION:
This software may be distributed freely, provided that it is
distributed in its entirety, without modifications, and with
the original copyright notice and license included. You may
distribute your own seperate patches together with this software
package or a modified package if you always include a pointer 
where to get the original unmodified package. In this case
you must inform the author about the modfied package.
The software may not be sold for profit or as "hidden" part of 
another software, but it may be included with collections 
of other free software, such as CD-ROM images of FTP servers and 
similar, provided that this software is not a significant part 
of that collection. 
Precompiled binaries of this software may be distributed in the
same way, provided that this copyright notice and license is
included without modification.

USAGE:
This software may be used freely, provided that the original
author is always credited.  If you intend to use this software
as a significant part of business (for-profit) activities, you
have to contact the author first.  Also, any usage that is not
covered by this license requires the explicit permission of
the author.

DISCLAIMER:
This software is provided as-is.  The author can not be held
liable for any damage that might arise from the use of this
software.  Use it at your own risk.



src/starscream/* license:



"Starscream" refers to the following files:
*  STAR.C
*  STARCPU.H
*  CPUDEBUG.C
*  CPUDEBUG.H
*  STARDOC.TXT
*  any object file or executable compiled from the above
*  any source code generated from STAR.C, or object file assembled from such
   code

Starscream may be distributed freely in unmodified form, as long as this
documentation is included.

No money, goods, or services may be charged or solicited for Starscream, or
any emulator or other program which includes Starscream, in whole or in part.
Using Starscream in a shareware or commercial application is forbidden.
Contact Neill Corlett ([EMAIL PROTECTED]) if you'd like to license
Starscream for commercial use.

Any program which uses Starscream must include the following credit text, in
its documentation or in the program itself:

"Starscream 680x0 emulation library by Neill Corlett
 ([EMAIL PROTECTED])"