Re: reiser4 non-free?

Re: reiser4 non-free?

[Walter Landry]

Hans Reiser <reiser@namesys.com> wrote:
> Someone posted the following on slashdot, presumably a debian someone:
> 
>     Nobody's saying that your proprietary hardware will cease to work in
>     Debian. The packages will still exist; they'll just be in the
>     "non-free" section, separated out so that people who don't want any
>     non-free software can omit that section from their sources.list
>     file. Non-free packages are technically not part of Debian, but if
>     you have a non-free line in your sources.list, there's no difference
>     whatsoever in how you use them.
> 
> So hopefully, Debian can print out some nice warning that Reiser4 is not 
> plagiarizable, and if the user indicates that they still want to use it 
> anyway, they can go forward.

The largest problem is that with the "clarification", you seem to have
changed the license, making it slightly more restrictive than the
plain old GPL.  The combination of Reiser4 and the kernel triggers GPL
Section 2.  That means that Debian will not be able to distribute
Reiser4 at all.

If you changed the clarification to a request, then Debian would have
no problems distributing it, even with the blurb.

> I find Debian's aggressive behavior toward myself, and especially 
> Richard Stallman and his GFDL, to be inappropriate and ungrateful, but I 
> also understand that Debian is striving to define its morality, and that 
> much of the world shares its rather asian attitude towards whether it is 
> acceptable to not credit others for their contributions to science. I do 
> not. I think the western approach of rigor in attribution has been of 
> great value in stimulating innovation over the centuries, and think it 
> should be applied to free software as much as it was to free science 
> research.

There are many, many software authors who have given away extremely
useful things for no cost.  That doesn't mean that Debian will
distribute those things.

> I don't expect to convince Debian of this, especially not after your 
> vote that you recently had, but it would be pleasant if users who don't 
> mind attribution are able to select reiser4 if they want it.

Make the license GPL-compatible, and Debian probably will make it
available.

Regards,
Walter Landry
wlandry@ucsd.edu

Re: reiser4 non-free?

[Narcoleptic Electron]

Walter Landry wrote: 

> The largest problem is that with the
> "clarification", you seem to have
> changed the license, making it slightly more
> restrictive than the
> plain old GPL.  The combination of Reiser4 and the
> kernel triggers GPL
> Section 2.  That means that Debian will not be able
> to distribute
> Reiser4 at all.

ReiserFS is heading down the same road as XFree86.

You won't get any recognition, Hans, if nobody is
using ReiserFS.

> If you changed the clarification to a request, then
> Debian would have
> no problems distributing it, even with the blurb.

There is still hope.  Please do not make ReiserFS a
curious footnote in the history of Linux.  It is far
too brilliant.



______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Re: reiser4 non-free?

[Walter Landry]

David Masover <ninja@slaphack.com> wrote:
> First and foremost:  Hans, this is your project.  Someone willing to
> replace entire APIs with things that feel like files is obviously not
> afraid of creating something new.  So at the end of the day, it
> shouldn't matter too much that it's in Debian Non-free, especially if
> (assuming I heard correctly) XFree86 is also non-free.

People seem to be missing this issue, so I'll bring it up again.  The
problem is not so much whether the license is free or not.  The
problem is that it is incompatible with the GPL.  That means that
Debian can't distribute it _at all_.  Not in main, not in non-free.
Not at all.

The license may be perfectly free (e.g. the IBM CPL), but if it is
incompatible with the GPL, then Debian can't distribute it.

Regards,
Walter Landry
wlandry@ucsd.edu

Re: reiser4 non-free?

[Brian Thomas Sniffen]

Walter Landry <wlandry@ucsd.edu> writes:

> David Masover <ninja@slaphack.com> wrote:
>> First and foremost:  Hans, this is your project.  Someone willing to
>> replace entire APIs with things that feel like files is obviously not
>> afraid of creating something new.  So at the end of the day, it
>> shouldn't matter too much that it's in Debian Non-free, especially if
>> (assuming I heard correctly) XFree86 is also non-free.
>
> People seem to be missing this issue, so I'll bring it up again.  The
> problem is not so much whether the license is free or not.  The
> problem is that it is incompatible with the GPL.  That means that
> Debian can't distribute it _at all_.  Not in main, not in non-free.
> Not at all.
>
> The license may be perfectly free (e.g. the IBM CPL), but if it is
> incompatible with the GPL, then Debian can't distribute it.

You're right, Walter, and thank you for the clarification.  To clarify
further, Debian can't distribute a derivative work of the Linux kernel
which is not licensed under the GPL.

-Brian

-- 
Brian Sniffen                                       bts@alum.mit.edu

Re: reiser4 non-free?

[Domenico Andreoli]

On Thu, May 06, 2004 at 09:44:01AM -0400, Brian Thomas Sniffen wrote:
> Walter Landry <wlandry@ucsd.edu> writes:
> 
> > David Masover <ninja@slaphack.com> wrote:
> >> First and foremost:  Hans, this is your project.  Someone willing to
> >> replace entire APIs with things that feel like files is obviously not
> >> afraid of creating something new.  So at the end of the day, it
> >> shouldn't matter too much that it's in Debian Non-free, especially if
> >> (assuming I heard correctly) XFree86 is also non-free.
> >
> > People seem to be missing this issue, so I'll bring it up again.  The
> > problem is not so much whether the license is free or not.  The
> > problem is that it is incompatible with the GPL.  That means that
> > Debian can't distribute it _at all_.  Not in main, not in non-free.
> > Not at all.
> >
> > The license may be perfectly free (e.g. the IBM CPL), but if it is
> > incompatible with the GPL, then Debian can't distribute it.
> 
> You're right, Walter, and thank you for the clarification.  To clarify
> further, Debian can't distribute a derivative work of the Linux kernel
> which is not licensed under the GPL.

if linux kernel distributes itself such a derivative work why debian
can't?

-----[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: reiser4 non-free?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

On Thu, 06 May 2004 16:36:43 +0200, Domenico Andreoli said:

> if linux kernel distributes itself such a derivative work why debian
> can't?

What non-GPL derivative works ship with the kernel?  Even having
facilities to load *non-derivative* non-GPL microcode into adapters
is frowned on....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: reiser4 non-free?

[Brian Thomas Sniffen]

Domenico Andreoli <cavok@debian.org> writes:

> On Thu, May 06, 2004 at 09:44:01AM -0400, Brian Thomas Sniffen wrote:
>> Walter Landry <wlandry@ucsd.edu> writes:
>> 
>> > David Masover <ninja@slaphack.com> wrote:
>> >> First and foremost:  Hans, this is your project.  Someone willing to
>> >> replace entire APIs with things that feel like files is obviously not
>> >> afraid of creating something new.  So at the end of the day, it
>> >> shouldn't matter too much that it's in Debian Non-free, especially if
>> >> (assuming I heard correctly) XFree86 is also non-free.
>> >
>> > People seem to be missing this issue, so I'll bring it up again.  The
>> > problem is not so much whether the license is free or not.  The
>> > problem is that it is incompatible with the GPL.  That means that
>> > Debian can't distribute it _at all_.  Not in main, not in non-free.
>> > Not at all.
>> >
>> > The license may be perfectly free (e.g. the IBM CPL), but if it is
>> > incompatible with the GPL, then Debian can't distribute it.
>> 
>> You're right, Walter, and thank you for the clarification.  To clarify
>> further, Debian can't distribute a derivative work of the Linux kernel
>> which is not licensed under the GPL.
>
> if linux kernel distributes itself such a derivative work why debian
> can't?

Someone who is the sole copyright holder of the Linux Kernel can
distribute it linked with some other program which is not under a
GPL-compatible license.  But nobody is in that position.

It is not Debian's business to attempt to control what the kernel
folks do -- we're all grateful for shier contributions, and that's
about that.

Reiser can distribute his filesystem and tools, because they depend
only on components included with the OS, and others can redistribute
for the same reason -- but Debian, as an OS distributor, can't do
that.  It's part of why we require OpenSSL-targeted license extensions
from GPL'd work which links against libcrypto.

-Brian

-- 
Brian Sniffen                                       bts@alum.mit.edu

Re: reiser4 non-free?

[Hans Reiser]

I just modified the Reiser4 license to be the following:

The Anti-Plagiarism License

Pre-amble:

At the time of writing (2004), distros commonly remove, diminish, or obscure
the credits of original authors from many programs so as to ensure that the
user has brand awareness primarily of the distro. They have a strong
marketing incentive to do so, and there is no shame shown by them in the 
act.
This is a very real problem which has already affected many programs
(e.g. KDE, ReiserFS, many others). Western academia has a strong 
tradition of
opposing plagiarism, and there are good societal reasons for ensuring that
persons are known for what they have done with precision. Individual users
don't benefit as significantly from knowing who produced their software, and
so one cannot say that there is a market demand for better credits that is
sufficient to overpower the desire of the distros to be the only source 
users
know of to turn to for all their needs. While individuals may not be well
motivated to ensure prominent and full crediting, society as a whole is.
Crediting is a powerful incentive to produce good works, and many have 
written
about the power of fame as a motivator for producing free software. Society
needs accuracy in its recognition of its contributors.

The License: The Anti-plagiarism license is the Gnu Public License Version 2
with the following modification: you may not modify, remove, or obscure any
credits in the software unless your modification causes those credits to 
remain
equally prominent and to retain their wording. You are not required to 
display
the credits if the computer has no effective display mechanism, or if 
you do not
distribute the software to others.

FAQ:

Q: Will this license lead to ads?

A: No, credits describe the contribution made to a project. Ads describe a
product someone wants you to buy. Ads are not the same as credits, and their
preservation is not protected by this license.

Q: Can we the distro preserve the credits but send the credits to /dev/null.

A: No. How can you even ask such a question?

Q: Can I change the font? Can I move the credits to a different moment 
in the
user interaction to suit my installer?

A: Yes, if you make sure the credits make an equally effective/frequent
impression on the user. If you have doubts about whether your changes are
fair, be courteous and ask the author and you'll find that most authors are
reasonable.

Q: What in this license prevents persons from making their name display
excessively annoyingly throughout the running of the program? Isn't that a
flaw in the license?

A: The shovel doesn't stop the digger from creating a pit in the road that
endangers other people. The license is a tool. Whether you make an ass out
of yourself using it on the software you write is up to you. No compiler 
makes
broken programs work....

Re: reiser4 non-free?

[Hans Reiser]

 I don't think my clarifications of what is a derivative work conflicted 
with the GPL, they merely make it less vague as to what is a derivative 
work.  The notion that if something is linked determines whether it is 
derivative has no basis in either copyright law or the GPL.  rms, 
correct me if you disagree.

Vagueness is not a benefit to a license, but in this aspect of the GPL 
it is curable only in specific to a particular program being licensed.  
It would be nice if the GPL explicitly allowed particular instances of 
it to specify what are derivative works with some clarity.  (Richard, 
please consider that.....)

I can see that not very clever people who view the GPL as some sort of 
holy writ will make more of an issue out of it than I want to deal 
with.  So, as a result reiser4 plugins will always be compiled in and 
never dynamically loadable and the clarifications of what is or is not a 
derivative work have been removed for now.  Users and I will both lose 
as a result, and maybe some needless lawsuit will result at some time in 
the future that would have been avoided with clear definitions.

Hans

Re: reiser4 non-free?

[Matthew Garrett]

Hans Reiser wrote:
>The License: The Anti-plagiarism license is the Gnu Public License Version 2
>with the following modification: you may not modify, remove, or obscure any
>credits in the software unless your modification causes those credits to 
>remain
>equally prominent and to retain their wording. You are not required to 
>display
>the credits if the computer has no effective display mechanism, or if 
>you do not
>distribute the software to others.

Ok, that's a restriction that's not present in the GPL version 2
(otherwise it wouldn't be necessary). Section 6 of the GPL says:

  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.

Which means that code under the Anti-plagiarism license is not GPL
compatible, since it imposes further restrictions. This would prevent
anyone from distributing it with their kernel. In order for it to be
distributable at all, you'd also need to demonstrate that it isn't a
derivative work of the Linux kernel.
-- 
Matthew Garrett | mjg59-chiark.mail.debian.legal@srcf.ucam.org

Re: reiser4 non-free?

[Hans Reiser]

Matthew Garrett wrote:

>Hans Reiser wrote:
>  
>
>>The License: The Anti-plagiarism license is the Gnu Public License Version 2
>>with the following modification: you may not modify, remove, or obscure any
>>credits in the software unless your modification causes those credits to 
>>remain
>>equally prominent and to retain their wording. You are not required to 
>>display
>>the credits if the computer has no effective display mechanism, or if 
>>you do not
>>distribute the software to others.
>>    
>>
>
>Ok, that's a restriction that's not present in the GPL version 2
>(otherwise it wouldn't be necessary). Section 6 of the GPL says:
>
>  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.
>
>Which means that code under the Anti-plagiarism license is not GPL
>compatible, since it imposes further restrictions. This would prevent
>anyone from distributing it with their kernel. In order for it to be
>distributable at all, you'd also need to demonstrate that it isn't a
>derivative work of the Linux kernel.
>  
>
The kernel portion is GPL V2, this is the progs license.....

Re: reiser4 non-free?

[Humberto Massa]

@ 06/05/2004 15:29 : wrote Hans Reiser :

>I just modified the Reiser4 license to be the following:
>
>The Anti-Plagiarism License
>  
>
etc.

Mr. Heiser,

I am a software developer, a paralegal, and a Debian user. Recently, 
I've participated in various technical discussions in debian-devel and 
in various licensing discussions in -legal. While I have sent you, both 
by way of the lists and personally, some questions about the reasoning 
of your licenses, you have up to the present moment refrained to answer me.

I stated in those e-mails that I am a great admirer of your work. I 
stated, also, that I agree with your concerns about plagiarism. I said, 
moreover, that I think that your work and the other reiser[34] 
contributors' work is important. Important to Debian. Important to the 
Linux community. Important to the Linux users. It's certainly important 
to me.

What I don't understand is _why_ are you doing this in such a beligerant 
manner. I repeat: please, let's work our differences out. Let us reach 
consensus and move forward.

Reading all the lists archives and bug reports, it appears to me that 
(at least part of) the problem is the following: some of your filesystem 
utilities displayed, unconditionally, a big (by some measure, but 
greater than 3 lines) attribution of credits. This was too much to some 
package maintainers, and they transferred said text to a file in the 
documentation directory for the package. You filed a bug, the maintainer 
gave you the shoulder, flames ensued, etc.

I don't agree with you that this is plagiarism. I'm sorry to say, but, 
in my dictionary (and in the jurisdiction I live in) plagiarism would 
be, for instance, remove *all* the credit attributions in the packages, 
or substituting them for some credits crediting the wrong person or 
persons. In this case, here in Brasil at least, the person commiting 
such acts would be subject to one to four years in jail and a fine.

The legal part of this remembers me of another problem, with your old 
"clarifications" over the GPL and with your new Anti-Plagiarism License: 
it's a GPL-incompatible license ... for a work (reiser4) which is 
derived from a GPL'd work (linux).

This pretty much renders your product (reiser4) undistributable by any 
person other than yourself. And, in principle, even by yourself. And I 
think this is a very big loss.

About the credits: if the credits attribution is too long to fit by the 
standards of the package's maintainer (who is the proper authority in 
the case, seemingly), what other solution there is? Just putting a line 
like:

"Many people contributed to this project. Please look: 
/usr/share/doc/reiserfsprogs/CREDITS."

is not enough? I mean, instead of the 20+ lines of the current display 
in dispute? As someone noticed in debian-legal, many people leave the 
theather before the credits roll. They know it's a (for instance) George 
Lucas' movie, but they won't know the name of the cameramen. Isn't it 
the same thing? If you want to see the credits, go and see them. It's 
not like Debian did make them disappear.

Now, I have only one question: is there a way you could back out in your 
opinion and return to the old licensing for your products, provided a 
consensus on moment and size of the credits attribution is reached? If 
the answer is yes, I volunteer to mediate the discussions between you 
and the affected package(s) maintainer(s).

-- 
best regards,
Humberto Massa

Re: reiser4 non-free?

[Stefan Traby]

On Thu, May 06, 2004 at 11:41:02AM -0700, Hans Reiser wrote:
> I don't think my clarifications of what is a derivative work conflicted 
> with the GPL, they merely make it less vague as to what is a derivative 

"clearifications" are modifications to the license and thereof
not relevant and incompatible to GPL.

-- 

  ciao - 
    Stefan

Re: reiser4 non-free?

[Humberto Massa]

@ 06/05/2004 15:56 : wrote Hans Reiser :

> I don't think my clarifications of what is a derivative work conflicted
>with the GPL, they merely make it less vague as to what is a derivative 
>work.  The notion that if something is linked determines whether it is 
>derivative has no basis in either copyright law or the GPL.  rms, 
>correct me if you disagree.
>  
>
In Brazilian copyright law, a derivative work has a simple definition: 
the work achieved by some transformation of the original work, but is a 
novel intellectual creation in itself.

Even the GPL is excessively verbose about what a derivative work is, and 
some of it contradicts the various copyright laws in a lot of 
jurisdictions. What I'm trying to say is: please don't. Solve the 
credits problem in any other way. I would be glad to help you. I care. 
Really.

>Vagueness is not a benefit to a license, but in this aspect of the GPL 
>it is curable only in specific to a particular program being licensed.  
>It would be nice if the GPL explicitly allowed particular instances of 
>it to specify what are derivative works with some clarity.  (Richard, 
>please consider that.....)
>  
>
But, it currently does not. It currently (and, in the case of the linux 
kernel, forever -- the linux kernel is licensed by GPL V2 only, not 
later) forbids aditional restrictions. It already places some 
restrictions, even on what is to be considered a derived work, which is 
a little bit out of its reach. If your work is a derived work (and I'm 
assuming reiser4, for instance, is a derived work of the linux kernel), 
Debian could only distribute it if it's licensed under the GPL V2 -- and 
no aditional restrictions, as per the GPL text itself.

Here is the text of the GPL, section 6, with my coments between {{}}:
*6.* Each time you redistribute the Program (or {{ in this case, reiser4 
}} any work based on the Program {{ linux }} ), the recipient 
automatically receives a license from the original licensor to copy, 
distribute or modify the Program subject to these terms and conditions. 
{{ important part: }} You may not impose any further restrictions on the 
recipients' exercise of the rights granted herein {{ which include, for 
example, moving printf-credits to some-file-credits }}. You are not 
responsible for enforcing compliance by third parties to this License.

>I can see that not very clever people who view the GPL as some sort of 
>holy writ will make more of an issue out of it than I want to deal 
>with.  So, as a result reiser4 plugins will always be compiled in and 
>never dynamically loadable and the clarifications of what is or is not a
>derivative work have been removed for now.  Users and I will both lose 
>as a result, and maybe some needless lawsuit will result at some time in
>the future that would have been avoided with clear definitions.
>  
>
This seems to be unnecessary: in this case, specifically, if reiser4 
plugins were or not derived works of reiser4, is settled even without 
the clarifications -- they are. Rule of thumb to derived works: could 
them (plugins) be created (as they are, not in a different way) if the 
original work (reiser4) was not created? Yes = derived; no = original. 
Likewise, could reiser4 be created as it is now, had linux not been 
created? Yes = reiser4 is a derived work on linux; no = it's an original 
work.

It's the same case as Windows NDIS drivers loading on linux. They were 
created in a different environment, and would exist as they are even if 
linux did not exist. Provided GPL'd glue code, you can load them in the 
linux kernel, and they are _not_ derivative works. This wouldn't happen 
with reiser4 plugins... unless, of course, someone took, for instance, 
NTFS plugins (if those ever come to existence) and put some (GPL'd) glue 
code to load them as reiser4 plugins (this would not render the 
previously-non-derived NTFS plugins in derived code from reiser4.)

>Hans
>  
>
I renew my plea for a peaceful and consensual resolution of these 
matters. Thank you, and please keep up the good work in the filesystems.

-- 
best regards,
Humberto Massa

Re: reiser4 non-free?

[Hans Reiser]

Humberto Massa wrote:

>  (and I'm assuming reiser4, for instance, is a derived work of the 
> linux kernel),

ReiserFS is not, it was created with the intent to port to other 
operating systems, and at least one of our customers has done so for V3, 
and I hope/expect others and I will do so for V4.

While I agree that Reiser4 plugins would be considered derived works 
legally, I think that unless the language is clear people will attempt 
to apply the linker rule to them (which has no legal basis but is what 
people act on).   Lawsuits against persons who had different 
interpretations waste money.

>
>
>>
> I renew my plea for a peaceful and consensual resolution of these 
> matters. Thank you, and please keep up the good work in the filesystems.
>
I hope you get your wishes in the matter.

Re: reiser4 non-free?

[Narcoleptic Electron]

Humberto Massa wrote: 

> Rule of thumb to
> derived works: could 
> them (plugins) be created (as they are, not in a
> different way) if the 
> original work (reiser4) was not created? Yes =
> derived; no = original. 

I believe that is incorrect.  It should be: yes =
original; no = derived.

> Likewise, could reiser4 be created as it is now, had
> linux not been 
> created? Yes = reiser4 is a derived work on linux;
> no = it's an original 
> work.

Again, that should be: yes = it's an original work; no
= reiser4 is a derived work on linux.



______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Re: reiser4 non-free?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

On Thu, 06 May 2004 16:56:23 -0300, Humberto Massa said:

> It's the same case as Windows NDIS drivers loading on linux. They were 
> created in a different environment, and would exist as they are even if 
> linux did not exist. Provided GPL'd glue code, you can load them in the 
> linux kernel, and they are _not_ derivative works.

And in fact, the fact that the NDIS or NVidia drivers *did* start off as Windows
code and have a properly GPL'ed glue layer is the only reason why they're
tolerated at all by the kernel community.  Linus has said on several occasions
words to the effect that "if NVidia hadn't convinced him that all of the closed
.o files were basically of Windows/other heritage, they'd have heard from a lawyer"...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: reiser4 non-free?

[Humberto Massa]

@ 06/05/2004 17:03 : wrote Narcoleptic Electron :

>Humberto Massa wrote: 
>
>  
>
>>Rule of thumb to
>>derived works: could 
>>them (plugins) be created (as they are, not in a
>>different way) if the 
>>original work (reiser4) was not created? Yes =
>>derived; no = original. 
>>    
>>
>
>I believe that is incorrect.  It should be: yes =
>original; no = derived.
>
>  
>
>>Likewise, could reiser4 be created as it is now, had
>>linux not been 
>>created? Yes = reiser4 is a derived work on linux;
>>no = it's an original 
>>work.
>>    
>>
>
>Again, that should be: yes = it's an original work; no
>= reiser4 is a derived work on linux.
>  
>
You're right in both accounts. It's 5:15 pm, I'm tired and I want to go 
home. :-)

-- 
br,M

Re: reiser4 non-free?

[Brian Thomas Sniffen]

Hans Reiser <reiser@namesys.com> writes:

> I just modified the Reiser4 license to be the following:
>
> The License: The Anti-plagiarism license is the Gnu Public License
> Version 2 with the following modification: you may not modify,
> remove, or obscure any credits in the software unless your
> modification causes those credits to remain equally prominent and to
> retain their wording. You are not required to display the credits if
> the computer has no effective display mechanism, or if you do not
> distribute the software to others.

You do realize that this is not GPL compatible, and so works
derivative of the Linux kernel cannot be meaningfully licensed
under it, and works licensed under it cannot be shipped linked to any
GPL'd works, right?

That's not the end of the world, but it's worth making clear. 
There are a couple of other problems with this license.  For example,
what if there is a display mechanism but I must pay an exorbitant
amount to use it?  Say, I'm doing mkreiserfs on the London Stock
Exchange ticker's main display.  Sure, that's a ridiculous case, but
a teletype where the user pays by the byte is not.  Can you restrict
this to works used interactively?  That's an intentionally different
phrasing than the GPLv2's -- and intentionally captures programs like
mkfs, which are not themselves interactive, but which are used in an
interactive way.

Also, as written the license prohibits me from stripping the credits
out of my own copy if I also, separately, distribute the unmodified
code.  I don't think that's what you meant -- is it?

Also, I may not, as written, translate the credits into another
language, since that changes their wording.

With those serious questions about the license out of the way, I
descend to the Faq, which obscures more than it clarifies:

> FAQ:
>
> Q: Will this license lead to ads?
>
> A: No, credits describe the contribution made to a project. Ads describe a
> product someone wants you to buy. Ads are not the same as credits, and their
> preservation is not protected by this license.

Debian's going to have to look really, really closely at every release
of every piece of software under this license, then, and risk an
argument -- in a courtroom -- with a copyright holder who considers
some line to be a credit, or insufficiently prominent in its modified
form.

For example, moving a credit from mkfs to an installer reduces its
frequency, as at least one fs is made per install, but other
filesystems may be made.

> Q: Can we the distro preserve the credits but send the credits to /dev/null.
>
> A: No. How can you even ask such a question?

How about e-mailing them to root?  How about providing a --no-credits switch?
How about making it on by default?

I expect the answers to be Yes, Yes, No, but I certainly can't read
your mind.  This license is very, very vague about what is allowed and
what is not -- normally not so bad, since there's a big clear zone of
what's allowed, but the line of what's Free and what's not is right
through the middle of the murky zone.  Whether this is a Free license,
then, depends very heavily on the licensor.  That's awfully
inconvenient, from a distributor's point of view.

> Q: Can I change the font? Can I move the credits to a different moment
> in the
> user interaction to suit my installer?
>
> A: Yes, if you make sure the credits make an equally effective/frequent
> impression on the user. If you have doubts about whether your changes are
> fair, be courteous and ask the author and you'll find that most authors are
> reasonable.

> Q: What in this license prevents persons from making their name display
> excessively annoyingly throughout the running of the program? Isn't that a
> flaw in the license?
>
> A: The shovel doesn't stop the digger from creating a pit in the
> road that endangers other people. The license is a tool. Whether you
> make an ass out of yourself using it on the software you write is up
> to you. No compiler makes broken programs work....

In other words, some works under this license are free (for example,
one containing no credits but the copyright notice) and others are
non-free.


-- 
Brian Sniffen                                       bts@alum.mit.edu

Re: reiser4 non-free?

[Steve Langasek]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

On Thu, May 06, 2004 at 11:59:23AM -0700, Hans Reiser wrote:
> >>The License: The Anti-plagiarism license is the Gnu Public License 
> >>Version 2
> >>with the following modification: you may not modify, remove, or obscure 
> >>any
> >>credits in the software unless your modification causes those credits to 
> >>remain
> >>equally prominent and to retain their wording. You are not required to 
> >>display
> >>the credits if the computer has no effective display mechanism, or if 
> >>you do not
> >>distribute the software to others.

> >Ok, that's a restriction that's not present in the GPL version 2
> >(otherwise it wouldn't be necessary). Section 6 of the GPL says:

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

> >Which means that code under the Anti-plagiarism license is not GPL
> >compatible, since it imposes further restrictions. This would prevent
> >anyone from distributing it with their kernel. In order for it to be
> >distributable at all, you'd also need to demonstrate that it isn't a
> >derivative work of the Linux kernel.

> The kernel portion is GPL V2, this is the progs license.....

Which does appear to preserve distributability of both parts.

-- 
Steve Langasek
postmodern programmer

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: reiser4 non-free?

[Brian Thomas Sniffen]

Hans Reiser <reiser@namesys.com> writes:

> The kernel portion is GPL V2, this is the progs license.....

Oh!  That makes many things more clear.  I know I've been assuming
"reiser4 non-free" meant the filesystem, not the reference tools which
manipulate it.  So somebody else can reimplement them in free
versions, writing from the specification.  Eugh, what a pain, and what
a waste, redoing all that work, but it's at least feasible.

-Brian

-- 
Brian Sniffen                                       bts@alum.mit.edu

Re: reiser4 non-free?

[Matthew Palmer]

On Thu, May 06, 2004 at 11:10:32AM -0700, Hans Reiser wrote:
> The Anti-Plagiarism License

[...]

> with the following modification: you may not modify, remove, or obscure any
> credits in the software unless your modification causes those credits to 

This licence would benefit greatly from a definition of "Credits". 
Considering that there have already been misunderstandings about Ads vs
Credits (which you attempt to dispel in the FAQ, but which confuse me
further), and different ideas about what exactly is a credit, you really do
need to tighten that up somewhat.  Yes, you can "ask the author", but if
this licence becomes widely used, can you imagine asking the author(s), for
every new version they release, what the credits are?  Do you really want
N+1 distributions all e-mailing you for every release with their credits
questions?

You could go GFDL and define the exact wording of your desired credits in
the licence, but then it would involve a licence change to change the
credits -- which if you've got parts licenced by different people under a
particular form of credits in the work, will require a new licence grant by
them, unless you word the licence in such a way that new credits can be
added to the licence without mucking up old ones.

> Q: Can we the distro preserve the credits but send the credits to /dev/null.
> 
> A: No. How can you even ask such a question?

Q: Can we the distro send the credits to another virtual console other than
the one the user is currently looking at?

Likely Answer: No.  How can you even ask such a question?

Actual answer: ???

Q: Must we then force the user to stay on the virtual console which the
credits are displayed until the notice has finished displaying?

Likely Answer: No.

Actual Answer: ???

Q: Where is the limit between displaying the credits where the user won't
necessarily see them, and forcing the user to read them?

Likely Answer: Umm...

Actual Answer: ???

These are all "line in the sand" questions which need to be answered.  If
distros are desiring to re-brand you (or rather, your contibutors) out of
the equation, they will likely be looking for where the line is, and how far
they can redraw it in their favour while you're not looking.  I'd imagine
that if you don't embed the line in concrete and bolt it down, it'll end up
somewhere you don't expect.  So you really have to tighten up your wording.

I'm not against what you're trying to accomplish - I like to be attributed
for my work, too.  I've never noticed any instances where I've not been
properly attributed in my work on an OSS project, and in fact I've been
surprised several times by the prominence others have given my name for work
I have done.

I've relied on human kindness thus far, and it's worked pretty well for me,
so perhaps my naivete is showing a little... That being said, as far as I
know my work doesn't form a fairly important part of *any* distribution
(Debian or otherwise).

There's something I haven't seen answered in this thread or the other
recurring ones on the same topic: have you ever actually made a formal
request to any of the distributions which have butchered your credits to
reinstate them?  If so, what was the response?  If not, why not, especially
since you advocate distributors asking authors what is appropriate?

- Matt

Re: reiser4 non-free?

[Raul Miller]

On Fri, May 07, 2004 at 09:23:10AM +1000, Matthew Palmer wrote:
> Q: Where is the limit between displaying the credits where the user won't
> necessarily see them, and forcing the user to read them?
> 
> Likely Answer: Umm...
> 
> Actual Answer: ???

Other things to consider:  how long must they be displayed?  What fonts
can be used?  What colors?  What orientations are allowed for the text?
What sort of display devices or mechanisms are ok to use (imagine systems
with no monitor and no serial terminal, or systems with a 3d interface
and not text)?

Or imagine systems for the blind -- what volume must these credits be
played at?  What speech rates are ok to use?  What quality of rendition
to phonemes is required?

Just scratching the surface, ...

-- 
Raul Miller

Re: reiser4 non-free?

[Stefan Traby]

On Thu, May 06, 2004 at 07:40:15PM -0400, Raul Miller wrote:

> Other things to consider:  how long must they be displayed?  What fonts

0 seconds. Just choose the correct locale. :)

-- 

  ciao - 
    Stefan

Re: reiser4 non-free?

[Jeremy Hankins]

Brian Thomas Sniffen <bts@alum.mit.edu> writes:
> Hans Reiser <reiser@namesys.com> writes:

>> A: No, credits describe the contribution made to a project. Ads
>> describe a product someone wants you to buy. Ads are not the same as
>> credits, and their preservation is not protected by this license.
>
> Debian's going to have to look really, really closely at every release
> of every piece of software under this license, then, and risk an
> argument -- in a courtroom -- with a copyright holder who considers
> some line to be a credit, or insufficiently prominent in its modified
> form.

Fuzzy lines in a license are not a new thing.  Debian isn't in the
litigation business, so we're not going to be trying to push the
boundaries anyway.  Respecting the wishes of the author/licensor is a
policy of ours -- remember the pine business.

>> Q: What in this license prevents persons from making their name
>> display excessively annoyingly throughout the running of the program?
>> Isn't that a flaw in the license?
>>
>> A: The shovel doesn't stop the digger from creating a pit in the road
>> that endangers other people. The license is a tool. Whether you make
>> an ass out of yourself using it on the software you write is up to
>> you. No compiler makes broken programs work....
>
> In other words, some works under this license are free (for example,
> one containing no credits but the copyright notice) and others are
> non-free.

Wouldn't such a work still be non-free?  At the least, it definitely
goes much farther than the analogous clause in the GPL.  You can't
include code (even optionally executed code) to suppress it, for
example.

-- 
Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

Re: reiser4 non-free?

[Brian Thomas Sniffen]

Jeremy Hankins <nowan@nowan.org> writes:

> Brian Thomas Sniffen <bts@alum.mit.edu> writes:
>> Hans Reiser <reiser@namesys.com> writes:
>
>>> A: No, credits describe the contribution made to a project. Ads
>>> describe a product someone wants you to buy. Ads are not the same as
>>> credits, and their preservation is not protected by this license.
>>
>> Debian's going to have to look really, really closely at every release
>> of every piece of software under this license, then, and risk an
>> argument -- in a courtroom -- with a copyright holder who considers
>> some line to be a credit, or insufficiently prominent in its modified
>> form.
>
> Fuzzy lines in a license are not a new thing.  Debian isn't in the
> litigation business, so we're not going to be trying to push the
> boundaries anyway.  Respecting the wishes of the author/licensor is a
> policy of ours -- remember the pine business.
>
>>> Q: What in this license prevents persons from making their name
>>> display excessively annoyingly throughout the running of the program?
>>> Isn't that a flaw in the license?
>>>
>>> A: The shovel doesn't stop the digger from creating a pit in the road
>>> that endangers other people. The license is a tool. Whether you make
>>> an ass out of yourself using it on the software you write is up to
>>> you. No compiler makes broken programs work....
>>
>> In other words, some works under this license are free (for example,
>> one containing no credits but the copyright notice) and others are
>> non-free.
>
> Wouldn't such a work still be non-free?  At the least, it definitely
> goes much farther than the analogous clause in the GPL.  You can't
> include code (even optionally executed code) to suppress it, for
> example.

If there are no credits, the prohibition on removing credits is null.

-- 
Brian Sniffen                                       bts@alum.mit.edu

Re: reiser4 non-free?

[Hans Reiser]

Brian Thomas Sniffen wrote:

>Hans Reiser <reiser@namesys.com> writes:
>
>  
>
>>I just modified the Reiser4 license to be the following:
>>
>>The License: The Anti-plagiarism license is the Gnu Public License
>>Version 2 with the following modification: you may not modify,
>>remove, or obscure any credits in the software unless your
>>modification causes those credits to remain equally prominent and to
>>retain their wording. You are not required to display the credits if
>>the computer has no effective display mechanism, or if you do not
>>distribute the software to others.
>>    
>>
>
>You do realize that this is not GPL compatible, and so works
>derivative of the Linux kernel cannot be meaningfully licensed
>under it, and works licensed under it cannot be shipped linked to any
>GPL'd works, right?
>  
>
It is the license for reiser4progs and not reiser4 in the kernel.

>That's not the end of the world, but it's worth making clear. 
>There are a couple of other problems with this license.  For example,
>what if there is a display mechanism but I must pay an exorbitant
>amount to use it?  Say, I'm doing mkreiserfs on the London Stock
>Exchange ticker's main display.  Sure, that's a ridiculous case, but
>a teletype where the user pays by the byte is not.  Can you restrict
>this to works used interactively?  That's an intentionally different
>phrasing than the GPLv2's -- and intentionally captures programs like
>mkfs, which are not themselves interactive, but which are used in an
>interactive way.
>  
>
Don't use the license for every piece of software, or contact the author 
for that case.  What makes you guys think one license should bind them all?

>Also, as written the license prohibits me from stripping the credits
>out of my own copy if I also, separately, distribute the unmodified
>code.  I don't think that's what you meant -- is it?
>  
>
Seems an obscure point, but I welcome suggestions on fixing obscure 
points of that kind.

>Also, I may not, as written, translate the credits into another
>language, since that changes their wording.
>  
>
Interesting point.

>With those serious questions about the license out of the way, I
>descend to the Faq, which obscures more than it clarifies:
>
>  
>
>>FAQ:
>>
>>Q: Will this license lead to ads?
>>
>>A: No, credits describe the contribution made to a project. Ads describe a
>>product someone wants you to buy. Ads are not the same as credits, and their
>>preservation is not protected by this license.
>>    
>>
>
>Debian's going to have to look really, really closely at every release
>of every piece of software under this license, then, and risk an
>argument -- in a courtroom -- with a copyright holder who considers
>some line to be a credit, or insufficiently prominent in its modified
>form.
>
>For example, moving a credit from mkfs to an installer reduces its
>frequency, as at least one fs is made per install, but other
>filesystems may be made.
>  
>
Talking to the author when you change the crediting is not such a bad 
thing.  It avoids situations like ReiserFS and debian/suse, or KDE and 
Redhat.

>  
>
>>Q: Can we the distro preserve the credits but send the credits to /dev/null.
>>
>>A: No. How can you even ask such a question?
>>    
>>
>
>How about e-mailing them to root?
>
? 

That sound awful.  Why would you want to do that?

>  How about providing a --no-credits switch?
>How about making it on by default?
>
>I expect the answers to be Yes, Yes, No, but I certainly can't read
>your mind.  This license is very, very vague about what is allowed and
>what is not -- normally not so bad, since there's a big clear zone of
>what's allowed, but the line of what's Free and what's not is right
>through the middle of the murky zone.  Whether this is a Free license,
>then, depends very heavily on the licensor.  That's awfully
>inconvenient, from a distributor's point of view.
>  
>
Yeah, governments hate art/porn/nudity for the same reason.  I like art, 
and consider Maplethorpe to be artistically educational and his show was 
a good use of my time.  That he inconvenienced the US government does 
not make me upset with him.

Let me make it simple for you.  When mkreiserfs  is run, let it print 
its credits and let them reach the screen.  That works, and should make 
everyone happy.

All this other stuff, like sending email to root instead of printing the 
credits to the screen, you don't really need to do it, so don't worry 
about whether you can.  Whether you can do stuff you don't need to do is 
not as important as the license ensuring that the people who contributed 
get credited for it. 

Hans

Re: reiser4 non-free?

[Hans Reiser]

Matthew Palmer wrote:

>
> Do you really want
>N+1 distributions all e-mailing you for every release with their credits
>questions?
>  
>
Yes.  Not such a burden, much less than explaining that write caching is 
badly done in most linux distros and kernels.

>You could go GFDL and define the exact wording of your desired credits in
>the licence, but then it would involve a licence change to change the
>credits -- which if you've got parts licenced by different people under a
>particular form of credits in the work, will require a new licence grant by
>them, unless you word the licence in such a way that new credits can be
>added to the licence without mucking up old ones.
>  
>
Oh, I always get full rights to licensing ReiserFS stuff routinely.  
Remember, I sell proprietary licenses once every year or two that pay 
the bills for a year.

>  
>
>>Q: Can we the distro preserve the credits but send the credits to /dev/null.
>>
>>A: No. How can you even ask such a question?
>>    
>>
>
>Q: Can we the distro send the credits to another virtual console other than
>the one the user is currently looking at?
>
>Likely Answer: No.  How can you even ask such a question?
>
>Actual answer: ???
>
>Q: Must we then force the user to stay on the virtual console which the
>credits are displayed until the notice has finished displaying?
>
>Likely Answer: No.
>
>Actual Answer: ???
>  
>
the current credits do not prevent console switching, though they do 
print to the one the user interacted with when he caused the mkreiserfs 
to occur.  why would you want to change that?

>Q: Where is the limit between displaying the credits where the user won't
>necessarily see them, and forcing the user to read them?
>
>Likely Answer: Umm...
>
>Actual Answer: ???
>  
>
Display the credits at the same times that running the tool without the 
wrapper would display them, and the license is satisfied.  If you want 
to improve the credit presentation, involve the author in it. If you 
don't like the excessive credits, use other software.   I dislike Disney 
dvds because they don't let me fast forward past the disney castle, but 
my kids and I like their movies (especially the old ones) more than I 
hate their credits so I survive ok....

>These are all "line in the sand" questions which need to be answered.  If
>distros are desiring to re-brand you (or rather, your contibutors) out of
>the equation, they will likely be looking for where the line is, and how far
>they can redraw it in their favour while you're not looking.  I'd imagine
>that if you don't embed the line in concrete and bolt it down, it'll end up
>somewhere you don't expect.  So you really have to tighten up your wording.
>
>I'm not against what you're trying to accomplish - I like to be attributed
>for my work, too.  I've never noticed any instances where I've not been
>properly attributed in my work on an OSS project, and in fact I've been
>surprised several times by the prominence others have given my name for work
>I have done.
>  
>
The persons I put in the credits didn't ask for it.  The distros are 
however stripping out the credits for various projects, and unless they 
are stopped this will accellerate.

>I've relied on human kindness thus far, and it's worked pretty well for me,
>so perhaps my naivete is showing a little... That being said, as far as I
>know my work doesn't form a fairly important part of *any* distribution
>(Debian or otherwise).
>
>There's something I haven't seen answered in this thread or the other
>recurring ones on the same topic: have you ever actually made a formal
>request to any of the distributions which have butchered your credits to
>reinstate them?  If so, what was the response?
>
I did not make a formal request first before changing the license.  
Maybe you have a point there.  I was pretty pissed when they removed the 
credits without even mentioning that they had done so....  You see, that 
is part of the problem.  I won't know about all the times the credits 
get removed if it is not in the license.....  but you are right that I 
missed the chance to see if the top level of the distros could be talked 
out of their actions.

>  If not, why not, especially
>since you advocate distributors asking authors what is appropriate?
>  
>

Re: reiser4 non-free?

[Raul Miller]

On Thu, May 06, 2004 at 11:59:23AM -0700, Hans Reiser wrote:
> The kernel portion is GPL V2, this is the progs license.....

Does this mean that the reiser progs are merely aggregated with the
kernel, and that there is no functional relationship?

[Because the GPL does provide an explicit exception for that case.]

Linus has stated that he's providing an additional exception for
user-space programs which use the standard system call interfaces,
and maybe the reiser progs just use standard system calls (as opposed
to custom calls that do things specific to the reiser file system)?

Anyways, it's probably not really all that important [and there are plenty
of alternate file systems if debian decides not to support this one].

-- 
Raul

Re: reiser4 non-free?

[Richard Stallman]

    > It's the same case as Windows NDIS drivers loading on linux. They were 
    > created in a different environment, and would exist as they are even if 
    > linux did not exist. Provided GPL'd glue code, you can load them in the 
    > linux kernel, and they are _not_ derivative works.

The idea that "glue code" makes it ok to combine GPL-covered code with
non-free code has no basis in the GPL.  The GPL applies to the entire
combination of code that is combined into a larger program.  If a.o is
under the GPL and talks to b.o which talks to c.o, the GPL covers all
three files, if all three are combined as one program.

Linus has implicitly and sometimes explicitly given permission for
some kinds of non-free dynamically loaded modules; perhaps the concept
of "glue code" is relevant in terms of the permission he has given.
I'm not the one to ask about that kind of issue.

Re: reiser4 non-free?

[Sami Liedes]

[Sorry if I messed up the reply somehow, I wasn't subscribed and that
made replying difficult. Now I am (to d-l). Couldn't these be archived
somewhere in mbox format?]

Hans Reiser wrote:

> It is the license for reiser4progs and not reiser4 in the kernel.

At least the kernel patches in the Debian package
kernel-patch-2.6-reiser4 state the license is the modified
("clarified") GPL in the file linux/fs/reiser4/README.

	Sami

Re: reiser4 non-free?

[Humberto Massa]

Mr. Stallman:

First of all, I would like to state that I have nothing but deep respect
and admiration for your ideals, and all your work. Thank you for
everything.

That said, I humbly disagree with your e-mail:

RMS wrote:
>> It's the same case as Windows NDIS drivers loading on linux. They
>> were created in a different environment, and would exist as they are
>> even if linux did not exist. Provided GPL'd glue code, you can load
>> them in the linux kernel, and they are _not_ derivative works.
>
>The idea that "glue code" makes it ok to combine GPL-covered code with
>non-free code has no basis in the GPL. The GPL applies to the entire
>combination of code that is combined into a larger program. If a.o is
>under the GPL and talks to b.o which talks to c.o, the GPL covers all
>three files, if all three are combined as one program.
>
>Linus has implicitly and sometimes explicitly given permission for some
>kinds of non-free dynamically loaded modules; perhaps the concept of
>"glue code" is relevant in terms of the permission he has given.  I'm
>not the one to ask about that kind of issue.

No, this idea has basis in copyright law. I specifically mentioned
Brazilian copyright laws in my e-mails, because that's what I have some
knowledge of, but the Berne convention is also reasonably clear, if you
think about it.

Brazilian copyright (author's rights, in truth) law says: a derived work
is the result of the transformation of an original work, that is an
intellectual creation on its own standing (best translation I can do).
So, a good rule of thumb a Brazilian copyright lawyer would use to
eliminate the possibility of a work be derived for another is to ask
himself: would work D exist (in the same form it currently exists) if
work O did not exist? Ellaborating a little bit more than I did in my
previous e-mails, if the answer is _yes_, it would exist, in the same
form it exists currently, even if work O did not exist, then D _IS_
_NOT_ a derived work from O. If the answer is _no_, it would not exist
in the same current form, then you'll have to dig deeper.

In the case of a NDIS driver, the driver itself is without doubt NOT a
derived work on the linux kernel. It would exist as-is even if linux did
not exist; the glue code IS (also without doubt) a derived work on the
linux kernel. The question is: "is there any license/copyright
infringement?". The answer is: no, under no circumstances. When the glue
code writer wrote the glue code, he was making a permitted modification
on the linux kernel (of which he had a GPL license), and of course I
suppose he is abiding the other terms of the GPL for distribution of the
glue code (p.ex., distributing it under the terms of the GPL also). When
the user linked the glue code with the NDIS driver code, he was doing
something inherent to the *use* of the kernel, the glue code, and the
NDIS driver code, which we know is quite out of reach of copyright law.
In the worst case, he would be in violation of some EULA for the NDIS
driver code.

This is not a Linus/Linux exemption, is just the application of the law.
What Linus did was to dig into copyright law (USofAn copyright law - USC
17) and find out the following (excerpt from Linus' lkml post):

>There's a clarification that user-space programs that use the standard
>system call interfaces aren't considered derived works, but even that
>isn't an "exception" - it's just a statement of a border of what is
>clearly considered a "derived work". User programs are _clearly_ not
>derived works of the kernel, and as such whatever the kernel license is
>just doesn't matter.
>
>And in fact, when it comes to modules, the GPL issue is exactly the
>same.  The kernel _is_ GPL. No ifs, buts and maybe's about it. As a
>result, anything that is a derived work has to be GPL'd. It's that
>simple.
>
>Now, the "derived work" issue in copyright law is the only thing that
>leads to any gray areas. There are areas that are not gray at all: user
>space is clearly not a derived work, while kernel patches clearly _are_
>derived works.
>
>But one gray area in particular is something like a driver that was
>originally written for another operating system (ie clearly not a
>derived work of Linux in origin). At exactly what point does it become
>a derived work of the kernel (and thus fall under the GPL)?
>
>THAT is a gray area, and _that_ is the area where I personally believe
>that some modules may be considered to not be derived works simply
>because they weren't designed for Linux and don't depend on any special
>Linux behaviour.
>
>Basically:
> - anything that was written with Linux in mind (whether it then _also_
>   works on other operating systems or not) is clearly partially a
>   derived work.
> - anything that has knowledge of and plays with fundamental internal
>   Linux behaviour is clearly a derived work. If you need to muck
>   around with core code, you're derived, no question about it.
>
>Historically, there's been things like the original Andrew filesystem
>module: a standard filesystem that really wasn't written for Linux in
>the first place, and just implements a UNIX filesystem. Is that derived
>just because it got ported to Linux that had a reasonably similar VFS
>interface to what other UNIXes did? Personally, I didn't feel that I
>could make that judgment call. Maybe it was, maybe it wasn't, but it
>clearly is a gray area.
>
>Personally, I think that case wasn't a derived work, and I was willing
>to tell the AFS guys so.
>
>Does that mean that any kernel module is automatically not a derived
>work?  HELL NO! It has nothing to do with modules per se, except that
>non-modules clearly are derived works (if they are so central to the
>kenrel that you can't load them as a module, they are clearly derived
>works just by virtue of being very intimate - and because the GPL
>expressly mentions linking).
>
>So being a module is not a sign of not being a derived work. It's just
>one sign that _maybe_ it might have other arguments for why it isn't
>derived.
>
Now, Linus is NAL, nor am I, and absolutely TINLA, but, I think it's not
up to the GPL (or any other license) to decide what is a derived work; a
license can clarify, for instance, like the kernel clarification, what
the copyright holder _exempts_ from being a derived work. That is, a
license can _relax_ what copyright law would consider a derived work,
not _tighten_ it. The process of "relaxing" the definition goes more or
less like "yeah, I know X _could_ be considered a derived work on my
work, but I am promising I do not consider it to be, meaning basically I
will not sue over this". IIRC, this is where *estoppel* applies.

I hope I have contributed to this discussion,

Humberto Massa

-- 
http://www.fastmail.fm - Does exactly what it says on the tin

Re: reiser4 non-free?

[Matthew Palmer]

On Fri, May 07, 2004 at 09:14:06AM -0700, Hans Reiser wrote:
> Matthew Palmer wrote:
> > Hans Reiser:
> >>Q: Can we the distro preserve the credits but send the credits to 
> >>/dev/null.
> >>
> >>A: No. How can you even ask such a question?
> >
> >Q: Can we the distro send the credits to another virtual console other than
> >the one the user is currently looking at?
> >
> >Likely Answer: No.  How can you even ask such a question?
> >
> >Actual answer: ???
> >
> >Q: Must we then force the user to stay on the virtual console which the
> >credits are displayed until the notice has finished displaying?
> >
> >Likely Answer: No.
> >
> >Actual Answer: ???
>
> the current credits do not prevent console switching, though they do 
> print to the one the user interacted with when he caused the mkreiserfs 
> to occur.  why would you want to change that?

I'm not thinking in terms of modifying mkreiserfs directly, although that is
a possible option.  I was trundling along the installer thought path, and
having noted that you dismissed redirecting the credits to /dev/null, I
thought about a GUI installer, which invokes mkreiserfs in the background,
and the user doesn't see any of the output under normal circumstances.  It
probably isn't redirected to /dev/null, but it would be printed on the VC
which invoked the X session, not in the GUI, which would mean that it would
be *very* unlikely that the user would ever see the credits messages. 
That's very, very close to sending the output to /dev/null.  So I was just
interested in where you thought the line-in-the-sand would be.

If it's permissible to cause the credits not to appear in the user's
ordinary line of view, as long as they appear *somewhere*, I can imagine
that the credits will appear in all sorts of unlikely places.  That way the
distributors will always be following the letter of your licence, and can
still play their branding games[1].

> >Q: Where is the limit between displaying the credits where the user won't
> >necessarily see them, and forcing the user to read them?
> >
> >Likely Answer: Umm...
> >
> >Actual Answer: ???
>
> Display the credits at the same times that running the tool without the 
> wrapper would display them, and the license is satisfied.  If you want 

Now that is a fairly explicit description of what the terms of the licence
are.  I would respectfully suggest that become an integral part of the
licence -- preferably with the exact description of the credits to be
displayed, so that differing interpretations of the term "credits" and
confusion with "adverts" (which even dictionaries can't agree on) don't get
in the way.

> >There's something I haven't seen answered in this thread or the other
> >recurring ones on the same topic: have you ever actually made a formal
> >request to any of the distributions which have butchered your credits to
> >reinstate them?  If so, what was the response?
>
> I did not make a formal request first before changing the license.  
> Maybe you have a point there.  I was pretty pissed when they removed the 
> credits without even mentioning that they had done so....  You see, that 
> is part of the problem.  I won't know about all the times the credits 

Understandably.

> get removed if it is not in the license.....  but you are right that I 
> missed the chance to see if the top level of the distros could be talked 
> out of their actions.

I'm not sure that your chance has been missed.  A nicely worded letter
(probably hard copy, for surety) to appropriate places at the major
distribution vendors would probably get a few "oops, didn't realise"
responses.

I'm a great believer in discussion to settle problems, rather than trying to
play legal games -- and your attempts at an Anti-plagiarism licence are a
good demonstration of why.  If you write a licence which people want to get
around, it's fairly hard to stop them.  Your typical human-readable
languages aren't real good at comprehensively eliminating all grey areas --
they're too open to interpretation.

So, in a battle of licencing, you write your terms, and your "opponents"
read those terms, find the loopholes, and keep doing what they're doing. 
You write a new licence, they find new loopholes, and keep going.  Lather,
rinse, repeat.  They keep doing this because you're hoping that they'll
stick to the spirit of the licence, but they've no reason to because they're
opponents.

If you don't treat the distributors as "opponents", but rather as allies in
the world of software, you'll probably get a lot further.  True allies will
generally stick to the spirit of licencing, because they don't want to annoy
you - you're a friend.  But without any friendly relationship there,
distributors can't know what your desires are, and you can't see what the
distributor's desires are.  You've attributed shady motives when, in my
experience, it's usually just overzealousness or some other form of innocent
misunderstanding.  This is the reason, IMO, why Debian encourages developers
to get to know the upstreams of their packages.

- Matt

[1] Are you familiar with the game of brandings?  Group of (usually young,
stupid) kids line up against a wall, one person with a tennis ball some
distance away, tries to hit someone with the ball, keeps trying until they
succeed, when the thrower becomes the hit person?  Painful and pointless
game, really.  Don't know why I thought of it.  <grin>

Re: reiser4 non-free?

[Richard Stallman]

I think we are having two misunderstandings at the same time.

You seem to be talking about the specific case of modules for Linux,
based on the specifics of the extra permission that Linus gave.
That case is different and what I say does not apply to it.

You are focusing on the definition of "derived work", but that is not
really the issue.  Copyright also covers use of a work as part of a
larger combined work.

Re: reiser4 non-free?

[Humberto Massa]

>> In the case of a NDIS driver, the driver itself is without doubt NOT
>> a derived work on the linux kernel.
>
>Yes, but the combination of the driver with the kernel is a derived
>work of the kernel, and it's not a case of "mere aggregation", which
>the GPL permits.

people here are not understanding me at all. I'll try to be more clear:

My position about Mr. Reiser's change of licensing:

1. The new license is GPL-incompatible. This is not a problem. He said
-- and I'll believe in his good faith -- that the kernel patch is not to
be licensed according to it, but GPL'd. OK.
1 (a) reiser4progs can be considered to be derivative of the reiser4
patch, but not a derivative of the kernel. I repeat: this is OK.

2. The new license has the possibility of being considered a
non-DFSG-free license because he is -- not really severely, but
seriously -- stopping creation of /some/ derived works. He does it to
stop
what he -- erroneously, IMHO -- called "plagiarism". I'll refer to it as
"aggressive rebranding". This is an unfortunate problem, in that would
get reiser4progs (and maybe reiserfsprogs) out of main, with all the
disadvantages that incur.
2 (a) Now, we should think: does Debian /need/ to aggresively rebrand,
removing the credits -- which Mr. Reiser state are part of his revenue
generation? Take in consideration the excellent work namesys has been
doing before answering.
2 (b) If the credits are to be considered for some reson prohibitively
extensive, what could we do to continuing their display, summarizing
them, to a point where it should be acceptable to Mr. Reiser?
2 (c) It has being a policy of the Debian Project, AFAIK, to comply
with the wishes of upstream (and *not* gratuitously fork projects)...

3. In the light of what I consider in good faith answer to the points
above, 
I suggest we politely request from Mr. Reiser that reverts his license to 
the GPL, with a request attached to it, whose terms would be something
like:

	"altough this license grants you the rights to modify the
	package, according to your wishes, the original copyright holder
	requests that you don't modify the credits printed at [[insert
	the occasions when they are printed here]], or the code that
	makes them being printed, or obfuscate their output in any way.
	This is because those credits are part of our revenue stream
	generation, and only by preserving them you would assure that we
	can continue to produce and improve the high-quality software
	you are using. For the record, for this version the referred
	credits are:

	  [[copy *all* of the credits here]] "

This request would be honored, IMHO, by the Debian Project, and I think
even RedHat and others would consider (after having their attention
called to this discussion) including the full Namesys branding as
opposed to losing reiserfs in the longer run. Besides, the full credits
will be a *legitimate* part of the license text -- and as such, it would
not be possible to ditch them anyway.

In a more technical point, some Makefile magic should be enough to
keep the copies of the credits in sync. :-)

4. The suggestion (3) above is the reason why I'm e-mailing this to the
reiser*progs maintainers.

5. Now back to the top and the NDIS driver thingy:

the combination of the NDIS driver and the kernel happens only
in the user's machine... the NDIS driver is certainly undistributable
by debian, it's in the disc present in the hardware box... and
copyright gives the user the possibility of combining them.

Hope to have helped,

--
br, M



-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free

Re: reiser4 non-free?

[mjt]

On Mon, May 10, 2004 at 08:22:32AM -0300, Humberto Massa wrote:
>
>	"altough this license grants you the rights to modify the
>	package, according to your wishes, the original copyright holder
>	requests that you don't modify the credits printed at [[insert
>	the occasions when they are printed here]], or the code that
>	makes them being printed, or obfuscate their output in any way.
>	This is because those credits are part of our revenue stream
>	generation, and only by preserving them you would assure that we
>	can continue to produce and improve the high-quality software
>	you are using. For the record, for this version the referred
>	credits are:
>
>	  [[copy *all* of the credits here]] "

This would be by far the best solution, at least for the time being.
The time being hectic.

Also the creditsd system sounded cool, I hope it becomes something.

I'd like to hear official distro statements, as well as Hans', for
this. Maybe if the distros say they're down with this, like their
word of honor, Hans would agree too.

Still a company's word of honor does not have to count for much,
people have been screwed over before, but now there's an inherent
means for backing this up; the community.

-- 
mjt

Re: reiser4 non-free?

[Hans Reiser]

Raul Miller wrote:

>On Fri, May 07, 2004 at 09:23:10AM +1000, Matthew Palmer wrote:
>  
>
>>Q: Where is the limit between displaying the credits where the user won't
>>necessarily see them, and forcing the user to read them?
>>
>>Likely Answer: Umm...
>>
>>Actual Answer: ???
>>    
>>
>
>Other things to consider:  how long must they be displayed?  What fonts
>can be used?  What colors?  What orientations are allowed for the text?
>What sort of display devices or mechanisms are ok to use (imagine systems
>with no monitor and no serial terminal, or systems with a 3d interface
>and not text)?
>
>Or imagine systems for the blind -- what volume must these credits be
>played at?  What speech rates are ok to use?  What quality of rendition
>to phonemes is required?
>
>Just scratching the surface, ...
>
>  
>
You eagerly imagine problems where there are none. mkreiserfs does not 
specify any font or color, it lets bash do that. Adhere to the spirit of 
the license and you will be ok.

Re: reiser4 non-free?

[Raul Miller]

> >Just scratching the surface, ...

On Mon, May 10, 2004 at 10:15:40AM -0700, Hans Reiser wrote:
> You eagerly imagine problems where there are none. mkreiserfs does not 
> specify any font or color, it lets bash do that. Adhere to the spirit of 
> the license and you will be ok.

I'm thinking about derivative works (kfslint, ferinstance), and alternate
environments (such as those tailored for disabled people).

It's pretty clear that a verbatim copy would not have any problems.

-- 
Raul

Re: reiser4 non-free?

[Walter Landry]

This just caught my eye

"Humberto Massa" <humberto.massa@almg.gov.br> wrote:
> 2 (a) Now, we should think: does Debian /need/ to aggresively rebrand,
> removing the credits -- which Mr. Reiser state are part of his revenue
> generation? Take in consideration the excellent work namesys has been
> doing before answering.

The question is rarely what Debian needs to do, but rather what Debian
promises that the users will be able to do.  Suppose that someone
wanted to use Reiser4 on a miniature burnable CD for elections.  The
mini-CD holds the person's vote, but it has to be initialized before
it can be used.

So whenever the poll worker initializes the mini-CD, they have to
mentally remove the credits before they can parse the results of the
filesystem initialization.  Poll workers are more likely to make
mistakes if they have to do this, so the only sensible thing to do is
to remove the credits.  The credits can still be in the documentation,
but if the license doesn't allow you to remove the credits, then it is
not DFSG-free.

Regards,
Walter Landry
wlandry@ucsd.edu

Re: reiser4 non-free?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Mon, 10 May 2004 21:49:15 EDT, Walter Landry said:

> The question is rarely what Debian needs to do, but rather what Debian
> promises that the users will be able to do.  Suppose that someone
> wanted to use Reiser4 on a miniature burnable CD for elections.  The
> mini-CD holds the person's vote, but it has to be initialized before
> it can be used.
> 
> So whenever the poll worker initializes the mini-CD, they have to
> mentally remove the credits before they can parse the results of the
> filesystem initialization.

If you're giving a poll worker (or any similar usage - a kiosk, a point-of-sale
terminal, etc) a machine, and they have to do that, you're doing something
Very Wrong.

If it requires any more intelligence than "turn it on, if a big RED circle
comes up, yell for help, if a big GREEN square with a check box comes up,
you're ready to go", you've failed your class in GUI Design 101. ;)






[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: reiser4 non-free?

[Walter Landry]

Valdis.Kletnieks@vt.edu wrote:
> On Mon, 10 May 2004 21:49:15 EDT, Walter Landry said:
> 
> > The question is rarely what Debian needs to do, but rather what Debian
> > promises that the users will be able to do.  Suppose that someone
> > wanted to use Reiser4 on a miniature burnable CD for elections.  The
> > mini-CD holds the person's vote, but it has to be initialized before
> > it can be used.
> > 
> > So whenever the poll worker initializes the mini-CD, they have to
> > mentally remove the credits before they can parse the results of the
> > filesystem initialization.
> 
> If you're giving a poll worker (or any similar usage - a kiosk, a
> point-of-sale terminal, etc) a machine, and they have to do that,
> you're doing something Very Wrong.
> 
> If it requires any more intelligence than "turn it on, if a big RED circle
> comes up, yell for help, if a big GREEN square with a check box comes up,
> you're ready to go", you've failed your class in GUI Design 101. ;)

I think you're agreeing with me.  I can't make it a simple red circle
or green square.  I have to spit out the credits _and_ the
circle/square.

Regards,
Walter Landry
wlandry@ucsd.edu

Re: reiser4 non-free?

[Raul Miller]

On Mon, May 10, 2004 at 10:33:29PM -0400, Walter Landry wrote:
> I think you're agreeing with me.  I can't make it a simple red circle
> or green square.  I have to spit out the credits _and_ the
> circle/square.

No, the point here is that this is a bad example.

It's more contrived than extreme ironing, and less useful.

-- 
Raul

Re: reiser4 non-free?

[Hans Reiser]

On Monday 10 May 2004 18:49, Walter Landry wrote:

> So whenever the poll worker initializes the mini-CD, they have to
> mentally remove the credits before they can parse the results of the
> filesystem initialization.  Poll workers are more likely to make
> mistakes if they have to do this, so the only sensible thing to do is
> to remove the credits.  The credits can still be in the documentation,
> but if the license doesn't allow you to remove the credits, then it is
> not DFSG-free.
Frankly I think you should worry more about reiser4 destroying your home 
directory than about such artificially constructed scenarios....

Re: reiser4 non-free?

[mjt]

On Tue, May 11, 2004 at 12:10:37AM -0700, Hans Reiser wrote:

>Frankly I think you should worry more about reiser4 destroying your home 
>directory than about such artificially constructed scenarios....

Current behavior of Reiser4 on my desktop pretty much annulls this worry ;)

Still, let's hope these scenarios are solved before Reiser4 is branded
100% fit-for-duty development stable, The Default FS For All Installations.

-- 
mjt

Re: reiser4 non-free?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Mon, 10 May 2004 22:33:29 EDT, Walter Landry <wlandry@ucsd.edu>  said:

> I think you're agreeing with me.  I can't make it a simple red circle
> or green square.  I have to spit out the credits _and_ the
> circle/square.

No, what's happening is that the mkfs program is spitting out the credits,
which are being read by a Perl/tktcl/python/whatever script which is then
parsing it and deciding whether to show the user a circle or a square.

The concept that the user would actually see the program output during system
bootup died when the Bell Lab guys first put 'foo > /dev/null' into a /etc/rc
script back in the late 60s.

For that matter, it probably died in late 1963, when Fred Brooks was steering
the IBM team that produced (among other things) JCL, and the team thought that
coding:

//GO.SYSPRINT DD DUMMY

was something reasonable to support (that's the JCL equiv of "> /dev/null").

I pondered the whole "credits" question for a bit last night, and I realized
that (a) I could account for at least the last 75 'mkfs' commands I had caused
to run, and (b) of those 75, exactly *one* did *not* have all of its output
swallowed by 'anaconda' during a RedHat or Fedora install.....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: reiser4 non-free?

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>
>
>I pondered the whole "credits" question for a bit last night, and I realized
>that (a) I could account for at least the last 75 'mkfs' commands I had caused
>to run, and (b) of those 75, exactly *one* did *not* have all of its output
>swallowed by 'anaconda' during a RedHat or Fedora install.....
>
>  
>
Yes, I believe that, and that is my concern. 

Re: reiser4 non-free?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On Tue, 11 May 2004 09:03:11 PDT, Hans Reiser said:
> Valdis.Kletnieks@vt.edu wrote:

> >I pondered the whole "credits" question for a bit last night, and I realized
> >that (a) I could account for at least the last 75 'mkfs' commands I had caused
> >to run, and (b) of those 75, exactly *one* did *not* have all of its output
> >swallowed by 'anaconda' during a RedHat or Fedora install.....

> Yes, I believe that, and that is my concern. 

Unfortunately, this way lies madness - the IBM AIX install stuff *does* scroll
the copyrights for every single program as it installs.

It *sucks*.  Badly.

I've had system upgrades that have had 12 *thousand* lines of output from
copyright notices - and the way IBM makes sure that you see them is by
outputting them to the same place as the error messages, so you can't just
redirect the notices.

And yes, at least twice I've managed to render a system unbootable because I
missed something important scrolling by....

The problem isn't "What do we do if Hans does this?".. The problem is that
Fedora Core 2 is coming in at just under 1,700 RPMs, of which some 750 are
installed in a default "workstation" install.

What happens when the *other* 749 do it too?  You end up with a tragedy
of the commons - *none* of the 750 get read, and the installer becomes
unusable....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: reiser4 non-free?

[Burnes, James]

Hans Reiser wrote:

> >
> >
> Yes, I believe that, and that is my concern.

I can understand that.  That's why I'm working on the 'creditsd'
infrastructure.  Decoupling the credit content from the visual aspect of
the program's performance makes the following possible...

1. It makes it possible for people that created your system to achieve
notoriety.  This is very important for people that are rarely paid
directly for their contributions.  If the credits achieve a relatively
fine granularity, it could create a workable 'credits' currency.  A
currency where egoboo has a tangible metric.  From a systems and
cybernetics viewpoint it creates a more rapid feedback loop.  More
egoboo.  More "free" code.  Faster.  In economics I believe that's
called 'velocity'.

2. You'd have to go to extreme and undeniable lengths to re-brand and
remove attribution from those who deserve it.  You will be shunned by
most of the engineering community.  It would be very black-and-white.
No chance for  "he said, she said" equivocation.

3. It takes credits out-of-band, so you don't have to worry if
displaying a credit message will:

   a. annoy or confuse the end-user at the wrong moment (not what we are
trying to do)
   b. negatively affect performance
   c. risk the chance that a well-intentioned credit at startup will be
buried because the programming that displays the credit lives at a
completely different level. (ie: shell command being invoked from a GUI,
or a web page served by apache/linux/reiser4).

4. No need for "...and then you go to jail".  If developers are getting
attribution in proportion to their efforts -- gaining notoriety and
generally feeling good about their contributions, there will be no need
to modify the GPL v2.  The occasional transgressor, a pariaha in the
community will have little to no effect on the economics of the
situation.

Economics, like physics, is not an option.  There is an economy of free
software.  We can either work with it or against it.  Perhaps this is a
step towards that goal.

(BTW: Has anyone actually written a formal book on the economics of free
software?  I know about the Cathedral and the Bazaar, but that's more
about the philosophy and the environment.  I want to see supply, demand,
Laffer curves, etc...) 


I'll try to forward some rough ascii art later....


jim burnes
security engineer
great-west, denver
 

Re: reiser4 non-free?

[Hans Reiser]

Burnes, James wrote:

>Hans Reiser wrote:
>
>  
>
>>>      
>>>
>>Yes, I believe that, and that is my concern.
>>    
>>
>
>I can understand that.  That's why I'm working on the 'creditsd'
>infrastructure.  Decoupling the credit content from the visual aspect of
>the program's performance makes the following possible...
>
>  
>
My main concern is how you make the credits not annoying.  Making them 
relevant is a big part of making them not annoying, or at least I think 
that is an advantage of displaying them on program entry (which for 
reiser4 is mkreiser4 invocation or boot (I chose mkreiser4 time instead 
of boot time because distros have all thoroughly monopolized the credits 
at boot time).

Re: reiser4 non-free?

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>On Tue, 11 May 2004 09:03:11 PDT, Hans Reiser said:
>  
>
>>Valdis.Kletnieks@vt.edu wrote:
>>    
>>
>
>  
>
>>>I pondered the whole "credits" question for a bit last night, and I realized
>>>that (a) I could account for at least the last 75 'mkfs' commands I had caused
>>>to run, and (b) of those 75, exactly *one* did *not* have all of its output
>>>swallowed by 'anaconda' during a RedHat or Fedora install.....
>>>      
>>>
>
>  
>
>>Yes, I believe that, and that is my concern. 
>>    
>>
>
>Unfortunately, this way lies madness - the IBM AIX install stuff *does* scroll
>the copyrights for every single program as it installs.
>
>It *sucks*.  Badly.
>  
>
Random credits are the elegant answer.  Displaying only the distro name 
at boot time is morally wrong.

>I've had system upgrades that have had 12 *thousand* lines of output from
>copyright notices - and the way IBM makes sure that you see them is by
>outputting them to the same place as the error messages, so you can't just
>redirect the notices.
>
>And yes, at least twice I've managed to render a system unbootable because I
>missed something important scrolling by....
>
>The problem isn't "What do we do if Hans does this?".. The problem is that
>Fedora Core 2 is coming in at just under 1,700 RPMs, of which some 750 are
>installed in a default "workstation" install.
>
>What happens when the *other* 749 do it too?  You end up with a tragedy
>of the commons - *none* of the 750 get read, and the installer becomes
>unusable....
>
>  
>
If you display a short blurb explaining what each program does and who 
wrote it, most users will find it interesting as they sit there boredly 
waiting.  If the speed of install is too fast, make them randomly 
selected samples.

Re: reiser4 non-free?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Tue, 11 May 2004 10:57:01 PDT, Hans Reiser said:

> Random credits are the elegant answer.  Displaying only the distro name 
> at boot time is morally wrong.

Would be nice - the RedHat/Fedora GUI installer already supports showing the
current install status in one pane, and scrolling through a bunch of blurbs
in another.  It might be possible to get (at least) the Fedora side of the fence
to include blurbs for the package contributors as well...

I'm uncomfortable with the very large leap between "a request for the distro
to do the morally right thing" and "required by license" however.  As the old
saying goes: "Don't let you mouth write no check your butt can't cash" - a
distro could very well be willing to accept something under a "good faith
best effort" basis, but be unwilling to commit to "required to under all
circumstances"....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: reiser4 non-free?

[Jeremy Hankins]

Brian Thomas Sniffen <bts@alum.mit.edu> writes:
> Jeremy Hankins <nowan@nowan.org> writes:
>> Brian Thomas Sniffen <bts@alum.mit.edu> writes:

>>> In other words, some works under this license are free (for example,
>>> one containing no credits but the copyright notice) and others are
>>> non-free.
>>
>> Wouldn't such a work still be non-free?  At the least, it definitely
>> goes much farther than the analogous clause in the GPL.  You can't
>> include code (even optionally executed code) to suppress it, for
>> example.
>
> If there are no credits, the prohibition on removing credits is null.

Yes, but there's still the format & placement of the copyright notice.
E.g., the fact that it's printed regardless of input and interactivity.

-- 
Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

Re: reiser4 non-free?

[Hans Reiser]

Valdis.Kletnieks@vt.edu wrote:

>On Tue, 11 May 2004 10:57:01 PDT, Hans Reiser said:
>
>  
>
>>Random credits are the elegant answer.  Displaying only the distro name 
>>at boot time is morally wrong.
>>    
>>
>
>Would be nice - the RedHat/Fedora GUI installer already supports showing the
>current install status in one pane, and scrolling through a bunch of blurbs
>in another.  It might be possible to get (at least) the Fedora side of the fence
>to include blurbs for the package contributors as well...
>  
>
That would be really nice.