ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Hans Reiser]

This changeset is to fix several reiserfs problems which can be
fixed in non-intrusive way.

You can use bk receive to get it.

Diffstat:
 Makefile |    2 +-
 bitmap.c |    6 ++----
 dir.c    |    1 +
 inode.c  |   13 ++++++++-----
 super.c  |    2 +-
 5 files changed, 13 insertions(+), 11 deletions(-)

patch and changelog:

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.587   -> 1.588  
#	   fs/reiserfs/dir.c	1.12    -> 1.13   
#	 fs/reiserfs/inode.c	1.38    -> 1.41   
#	 fs/reiserfs/super.c	1.33    -> 1.34   
#	fs/reiserfs/Makefile	1.5     -> 1.6    
#	fs/reiserfs/bitmap.c	1.15    -> 1.16   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/04/05	green@angband.namesys.com	1.588
# bitmap.c:
#   fixed "unused variable" warning.
# super.c:
#   Fix a mispelling in info message.
# Makefile:
#   tail_conversion.o was specified twice in list of objects to build
# inode.c:
#   Add forgotten metadata journaling.
#   Fix a case where flag was not set at inode-read time which prevented
#   32bit uid/gid to work correctly.
#   Fix a lookup problem on big-endian platforms.
# dir.c:
#   Fix a case where atime were not updated when needed.
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/Makefile b/fs/reiserfs/Makefile
--- a/fs/reiserfs/Makefile	Fri Apr  5 14:16:14 2002
+++ b/fs/reiserfs/Makefile	Fri Apr  5 14:16:14 2002
@@ -9,7 +9,7 @@
 
 O_TARGET := reiserfs.o
 obj-y   := bitmap.o do_balan.o namei.o inode.o file.o dir.o fix_node.o super.o prints.o objectid.o \
-lbalance.o ibalance.o stree.o hashes.o buffer2.o tail_conversion.o journal.o resize.o tail_conversion.o item_ops.o ioctl.o procfs.o
+lbalance.o ibalance.o stree.o hashes.o buffer2.o tail_conversion.o journal.o resize.o item_ops.o ioctl.o procfs.o
 
 obj-m   := $(O_TARGET)
 
diff -Nru a/fs/reiserfs/bitmap.c b/fs/reiserfs/bitmap.c
--- a/fs/reiserfs/bitmap.c	Fri Apr  5 14:16:14 2002
+++ b/fs/reiserfs/bitmap.c	Fri Apr  5 14:16:14 2002
@@ -139,10 +139,8 @@
 /* preallocated blocks don't need to be run through journal_mark_freed */
 void reiserfs_free_prealloc_block (struct reiserfs_transaction_handle *th, 
                           unsigned long block) {
-    struct super_block * s = th->t_super;
-
-    RFALSE(!s, "vs-4060: trying to free block on nonexistent device");
-    RFALSE(is_reusable (s, block, 1) == 0, "vs-4070: can not free such block");
+    RFALSE(!th->t_super, "vs-4060: trying to free block on nonexistent device");
+    RFALSE(is_reusable (th->t_super, block, 1) == 0, "vs-4070: can not free such block");
     _reiserfs_free_block(th, block) ;
 }
 
diff -Nru a/fs/reiserfs/dir.c b/fs/reiserfs/dir.c
--- a/fs/reiserfs/dir.c	Fri Apr  5 14:16:14 2002
+++ b/fs/reiserfs/dir.c	Fri Apr  5 14:16:14 2002
@@ -180,6 +180,7 @@
     filp->f_pos = next_pos;
     pathrelse (&path_to_entry);
     reiserfs_check_path(&path_to_entry) ;
+    UPDATE_ATIME(inode) ;
     return 0;
 }
 
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c	Fri Apr  5 14:16:14 2002
+++ b/fs/reiserfs/inode.c	Fri Apr  5 14:16:14 2002
@@ -745,8 +745,12 @@
 		if (retval) {
 		    if ( retval != -ENOSPC )
 			printk("clm-6004: convert tail failed inode %lu, error %d\n", inode->i_ino, retval) ;
-		    if (allocated_block_nr)
+		    if (allocated_block_nr) {
+			/* the bitmap, the super, and the stat data == 3 */
+			journal_begin(&th, inode->i_sb, 3) ;
 			reiserfs_free_block (&th, allocated_block_nr);
+			transaction_started = 1 ;
+		    }
 		    goto failure ;
 		}
 		goto research ;
@@ -933,9 +937,6 @@
 	// (directories and symlinks)
 	struct stat_data * sd = (struct stat_data *)B_I_PITEM (bh, ih);
 
-	/* both old and new directories have old keys */
-	//version = (S_ISDIR (sd->sd_mode) ? ITEM_VERSION_1 : ITEM_VERSION_2);
-
 	inode->i_mode   = sd_v2_mode(sd);
 	inode->i_nlink  = sd_v2_nlink(sd);
 	inode->i_uid    = sd_v2_uid(sd);
@@ -956,6 +957,7 @@
 	else
 	    set_inode_item_key_version (inode, KEY_FORMAT_3_6);
 	REISERFS_I(inode)->i_first_direct_byte = 0;
+	set_inode_sd_version (inode, STAT_DATA_V2);
     }
 
     pathrelse (path);
@@ -1218,7 +1220,8 @@
     struct reiserfs_iget4_args *args;
 
     args = opaque;
-    return INODE_PKEY( inode ) -> k_dir_id == args -> objectid;
+    /* args is already in CPU order */
+    return le32_to_cpu(INODE_PKEY(inode)->k_dir_id) == args -> objectid;
 }
 
 struct inode * reiserfs_iget (struct super_block * s, const struct cpu_key * key)
diff -Nru a/fs/reiserfs/super.c b/fs/reiserfs/super.c
--- a/fs/reiserfs/super.c	Fri Apr  5 14:16:14 2002
+++ b/fs/reiserfs/super.c	Fri Apr  5 14:16:14 2002
@@ -765,7 +765,7 @@
     if ( rs->s_v1.s_root_block == -1 ) {
        brelse(bh) ;
        printk("dev %s: Unfinished reiserfsck --rebuild-tree run detected. Please run\n"
-              "reiserfsck --rebuild-tree and wait for a completion. If that fais\n"
+              "reiserfsck --rebuild-tree and wait for a completion. If that fails\n"
               "get newer reiserfsprogs package\n", s->s_id);
        return 1;
     }

BK changeset:

This BitKeeper patch contains the following changesets:
1.588
## Wrapped with gzip_uu ##


begin 664 bkpatch2245
M'XL(`&6WK3P``[58:V_CMA+]'/V*N2E0)&ULBR(I2RX2)-W-MD'Z"/91H$`!
M@9(HFXTL&J*<;'IU__L=4G(WWJ2)G:T=PV)L<G0X<V;.4%_!!R/KR=ZTEK+R
MOH(?M6DF>Z*:IJ+*AY682W-GAIF>XV]OM<;?1C,]ER,W?Y1>)[>ZOA[54J$5
M.BA5M?PX"(;<P^E7HLEF<"-K,]DC0_KW-\W=0D[VWI[_\.&GL[>>=WP,KV9X
M0_E.-G!\[#6ZOA%E;DY%,RMU-6QJ49FY;(1%T?X]M0U\/\`_3L;4YV%+0I^-
MVXSDA`A&9.X'+`J9YW">/K*?SRTQG_LQ(Y2T?A3'W'L-9,BC"/Q@Y+.1SX'0
M"?<G//C69Q/?AW\T#-]R&/C>]_#O;N25ET&JFKE8#+,)C@$*]5'FL+^LE@:O
M-Z)6(BWE/MR*NE+5=(B3S'(AZ]7\-^HC")@KLY`E!FH*JL)WH0&A&S&5=L'/
MXEH6JI3=BD:H,LET96.H<`<:;1O`]9DJ%-ZSN569M&9*91K0!>CT3YDU!K<.
MZ5*5.5I1E<[E"L)9GD.AZZEN&EF!]44N&@%_ZF5=B;('O4*:"2/A=B9K"44I
MIN[>E6[`($]$TQD>U%(@#C6W,Q62:U'+&UDU,G>&:(`N@Z7*1U.56U26K9#I
MND:8Y=W]NY5:7R\7N%ZC$^>@*_3V=""K7(D*%J5H$/?<V!6Y^LRE]X"*#HH=
M6JC+!>X/'84_5E!)F<M\Z%T"(73,O*M/O/<&6[X\SQ>^=P(+FU&/$ZPP?5KB
M8!76>USC/@U:ZOLQ;0N>QMDX8"DOHC0.TG_F]A-&N_SA)&X#'I#QYMA6I'Z(
M#7G?%BP:QR+F-)=Q5G"Q(;9UHPX;]X.@);AALCDV%^J'P&+"6QZ&<3QF:9K'
MM`A)L2&P>Q;[BL/"EL6!OP6J/J4>X`IX'+5Y+FD<9RR/\ZP@;--@KMGLD#'T
M%Z,LVH)G?;U91T9;']V.'DO#**<19UQ$8[_8%-F:S0Y9&/`V9&.?.O5XC)-6
M2':2&R^U&OH^B5C4!F,_($Y<PC5I87Q"XN>EA<"`[$1:OKS47T*7^+_"H+YU
M;RQ35X]&YP7E[C4)@'@7[K-,12FJ3")(]6EH&G0;7F?"S*096EA%(>L`1P\W
MURL.CFIIU%_.5"/GB5[8E4JC.N`5Q2`K\(L'-%N5ERUHMEV9\VY4K4_G:'6X
M,,NAS)=/&0LB_*`<RQL)0^K81<+/.Y=@@\XE@`';";V>[550%%UI?H(]JTV_
MB#TL`(;T81P"#X4;WKXY^^G=^<%_FMG@I$E<C3F"_1LS8)BJ$VCJ.]LA(;D+
M]!:DI<ZN;4]0Z4I^Q`S`%@-R>8,YL7_XW7V#RB2U7!J[.SA8,^YL'`$Y1-*`
MO[K9&&^6B<IU"^Y69HE=C)MK+7]./"<?6[!N"P'SND6G&RA70*PQSE`?QHS[
M'>'H>CTC$Q9N5,]VTRJ_L#/KE/@)$CHOO("!%R2RI<LRY</5Z[/WY\G9^XN?
MD2]6=P_A8:1[0=XBUENU!=Y<&%V=&LS'YWJ!@$2<4-YB@:&1BS6-UV,=3'R^
M47'Y][4KV[)]OP0:HZFG0MQO_V4B%9!.IO#:%9K1-R#JJ0%E0)3VM')G5?35
MU0?0=2YK^&;DIM6R046"4M(@:722+98'%[_\^OH\N;H\_[UGR>#D.D'^)2IW
M-<29'9ST2JQRY-"+>SWT<]LYQL:7^>OQ1?W8K#>A.XOO%Q\&GST*(C,HX]&.
MF!'3$*AW$?,(^;&'J!-G+#%YTG<ET$7Y"-Z]/WN?8(DX2WX+#K\DJ)3';;<G
M%U2R'E2V44?`=]5P;O`H`,NQ.W[L)B)C9D-Q82_4V]NS2:@*.!`E:J^5AL2)
M<%+5A_!?_'T/$[F9R?X9S)$;]\J.3NO^;9");A>8G=1F-B[K-Y2D<JJJ@Z^;
MV5%/UA.5F/0(J"W^B"+&>H'3G6,%IK.N$K176XTZ!H)S.HC_>R`4_?EH"Z'8
MZI2V(?T>.:59:R'C_;,TRM;I%TZ"#31C9^>=YQ^&74)WQ'R"??VF7\2^L&.?
MN\#::W]E'UO.`=8T=[P:V-.-8]JMP#J&F6.+HIXO2FFY,H2+`CF(_"OPK&/^
=J/8_/8'-9C*[-LOYL<`V+\K3POL_D.3+5_45````
`
end

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Linus Torvalds]

On Sat, 6 Apr 2002, Hans Reiser wrote:
> 
> This changeset is to fix several reiserfs problems which can be
> fixed in non-intrusive way.

Please don't use bk patches, they have turned out to be pretty much 
unusable.

Either make a (controlled) bk tree available for pulling, or just use 
old-fashioned patches.

		Linus

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Larry McVoy]

On Fri, Apr 05, 2002 at 01:48:30PM -0800, Linus Torvalds wrote:
> 
> On Sat, 6 Apr 2002, Hans Reiser wrote:
> > 
> > This changeset is to fix several reiserfs problems which can be
> > fixed in non-intrusive way.
> 
> Please don't use bk patches, they have turned out to be pretty much 
> unusable.

I suspect that the problem is that BK won't let you accept a patch unless
the receiving repository has the parent of the patch.  In other words,
this won't work:

	bk clone bk://linux.bkbits.net/linux-2.5
	<make some changes>
	bk commit (or bk citool)	# creates changeset 1.800
	<make some changes>
	bk commit (or bk citool)	# creates changeset 1.801

	# Now you want to send the second patch to Linus so you do a:
	bk send -r+ - | mail linux-kernel@vger.kernel.org

That will fail when Linus tries to accept the patch, because he doesn't
have your 1.800.

The easiest thing is to do what he suggests:

> Either make a (controlled) bk tree available for pulling, or just use 
> old-fashioned patches.

and if you want to go the "tree for pulling", you can either point him at
a BK url you maintain, or you are welcome to go grab resierfs.bkbits.net
and stash it there.  See http://www.bitkeeper.com/Hosted.html for information
on how to set up a project here.

At some point, we'll package up the whole bkbits.net infrastructure as an
installable RPM (not the project data, the infrastructure), and you'll be
able to do this at resierfs.bkbits.kernel.org or something like that, but
right now we're just too overworked to do so.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Hans Reiser]

I am confused, the bk patches look like they have normal patches at the 
top of them.  Does he just need to use patch -p1 or is there a deeper 
screwiness to these patches that he refers to?

We did this because my security/sysadmin specialist (flx) is not 
enthusiastic about having a semi-closed source network service offering 
process running on the machine which holds our source code and website 
without any IP filters guarding it.  Especially when it is as 
complicated as a version control system needs to be.

We were planning on setting up a clone for non-Namesys users outside our 
firewall, but we need for Linus's access to be just as secure as ours. 
 I am not sure what to do, let's see what flx says.

Hans

PS for Larry (Persons not interested in licensing issues should not read 
further)

Keeping source code secret is the worst part of the proprietary model. 
 It prevents knowledge from accumulating, and it is an abuse of the 
original intention of copyright law, which was to encourage people to 
not keep knowledge secret.  I know that piracy has caused you to keep 
the source code secret, but piracy is a problem for all software (even 
GPL software, as proprietary software vendors frequently steal it). 
 Please don't let a few bad experiences lead you down the trade secret 
route that copyright and patent laws were designed to let us escape from.

Secret source code is a form of social lockout, and avoiding that 
lockout is the civil rights issue of our day.  This will only become 
more and more important in the coming generations, as our shadows in 
cyberspace become more solid, and firmer in their replication of our 
evils.  Lockout of programs, and of persons who modify programs, is 
going to be the most important civil rights issue of your lifetime.  Are 
you sure you are standing where you want to stand on that issue?

Another model you might consider, one which would probably make you more 
money, make us happier, and better avoid "freeloaders", would be to make 
bitkeeper free for use with free software only.  This would be rather 
similar to what I use for reiserfs, which is free for use with free 
operating systems only, and available for a fee for all others.  It 
allows you to "do unto others as they would do unto you" (The Reiser 
Rule ;-) ).

Hans



Larry McVoy wrote:

>On Fri, Apr 05, 2002 at 01:48:30PM -0800, Linus Torvalds wrote:
>
>>On Sat, 6 Apr 2002, Hans Reiser wrote:
>>
>>>This changeset is to fix several reiserfs problems which can be
>>>fixed in non-intrusive way.
>>>
>>Please don't use bk patches, they have turned out to be pretty much 
>>unusable.
>>
>
>I suspect that the problem is that BK won't let you accept a patch unless
>the receiving repository has the parent of the patch.  In other words,
>this won't work:
>
>	bk clone bk://linux.bkbits.net/linux-2.5
>	<make some changes>
>	bk commit (or bk citool)	# creates changeset 1.800
>	<make some changes>
>	bk commit (or bk citool)	# creates changeset 1.801
>
>	# Now you want to send the second patch to Linus so you do a:
>	bk send -r+ - | mail linux-kernel@vger.kernel.org
>
>That will fail when Linus tries to accept the patch, because he doesn't
>have your 1.800.
>
>The easiest thing is to do what he suggests:
>
>>Either make a (controlled) bk tree available for pulling, or just use 
>>old-fashioned patches.
>>
>
>and if you want to go the "tree for pulling", you can either point him at
>a BK url you maintain, or you are welcome to go grab resierfs.bkbits.net
>and stash it there.  See http://www.bitkeeper.com/Hosted.html for information
>on how to set up a project here.
>
>At some point, we'll package up the whole bkbits.net infrastructure as an
>installable RPM (not the project data, the infrastructure), and you'll be
>able to do this at resierfs.bkbits.kernel.org or something like that, but
>right now we're just too overworked to do so.
>

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Larry McVoy]

On Sat, Apr 06, 2002 at 04:00:37PM +0400, Hans Reiser wrote:
> I am confused, the bk patches look like they have normal patches at the 
> top of them.  

If you just want to send him regular patches, use bk export -tpatch.
That's sort of a lame way to go if you are using BK on both ends,
you're going to end up merging your changes with your changes when
you pull from Linus' tree.  There are lots of reasons why this isn't
a good idea.

> We were planning on setting up a clone for non-Namesys users outside our 
> firewall, but we need for Linus's access to be just as secure as ours. 

bk help url, then look at 

       bk://<user>@<host>
	Connects to <host> using ssh, assumes that bkd is  the
	login shell.  The home directory of <user> must be the
	root of the repository.

then you can make a login shell that looks like

	#!/bin/sh
	exec bk bkd -xcd 

and you have an ssh based login which can only look at data in that
directory.  This is how the write path on bkbits.net works.

> Another model you might consider, one which would probably make you more 
> money, make us happier, and better avoid "freeloaders", would be to make 
> bitkeeper free for use with free software only.  This would be rather 
> similar to what I use for reiserfs, which is free for use with free 
> operating systems only, and available for a fee for all others.  It 
> allows you to "do unto others as they would do unto you" (The Reiser 
> Rule ;-) ).

We are dealing with various commercial organizations who play games
with the checkin comments so that they can use BK for free and not give
up any information.  Technically, it's a violation of the license if
they do that, but proving that they are doing it just isn't worth it.
What I'm tempted to do is to figure out a reasonable way to force free
uses to make their changes publically available.  More like sourceforge,
if you use their service, anyone can get at your source.  The problem
is that we can't force all the changes out into the open immediately,
people may have good reasons to hide (security changes, for example),
along with bad reasons (they're freeloaders).

Allowing free use of BK with free software only doesn't solve anything.
We have lots of people doing that and still hiding their changes
behind empty (or "fixed") checkin comments.  It's only the commercial
organizations who are a problem.  I'd really like to force those changes
out in the open if they aren't going to pay.  The whole point of the
openlogging stuff was to get people to work out in the open.

I've thought a bit about some sort of answer which addresses this and
I'm curious to see what people would think if the rule were that your
changes had to show up on a public server within a given time period
(a month? 2 months? 3 months?).  In other words, factor in a reasonable
ability to work in privacy but make it be limited enough that it only
works for truly free software.

My definition of free software is anything where the source is publically
available.  It's sometimes called "Open Source".  Open source software
where you can't get at the source is lame.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [reiserfs-dev] Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Oleg Drokin]

Hello!

On Sat, Apr 06, 2002 at 09:01:57AM -0800, Larry McVoy wrote:
> > I am confused, the bk patches look like they have normal patches at the 
> > top of them.  
> If you just want to send him regular patches, use bk export -tpatch.
> That's sort of a lame way to go if you are using BK on both ends,
> you're going to end up merging your changes with your changes when
> you pull from Linus' tree.  There are lots of reasons why this isn't
> a good idea.

In fact, per one of the original 'BK Patches sending' HOWTO,
we are including output of bk export -tpatch ... stuff prior to
bk send ... - stuff.
So that people who want to get the diff, can get it without silly tricks.

Bye,
    Oleg

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Hans Reiser]

Larry McVoy wrote:

>
>>Another model you might consider, one which would probably make you more 
>>money, make us happier, and better avoid "freeloaders", would be to make 
>>bitkeeper free for use with free software only.  This would be rather 
>>similar to what I use for reiserfs, which is free for use with free 
>>operating systems only, and available for a fee for all others.  It 
>>allows you to "do unto others as they would do unto you" (The Reiser 
>>Rule ;-) ).
>>
>
>We are dealing with various commercial organizations who play games
>with the checkin comments so that they can use BK for free and not give
>up any information.  Technically, it's a violation of the license if
>they do that, but proving that they are doing it just isn't worth it.
>What I'm tempted to do is to figure out a reasonable way to force free
>uses to make their changes publically available. 
>

This would be good to do.

> More like sourceforge,
>if you use their service, anyone can get at your source.  The problem
>is that we can't force all the changes out into the open immediately,
>people may have good reasons to hide (security changes, for example),
>along with bad reasons (they're freeloaders).
>
Better this inconvenience than hiding the source code....

>
>
>Allowing free use of BK with free software only doesn't solve anything.
>We have lots of people doing that and still hiding their changes
>behind empty (or "fixed") checkin comments.  It's only the commercial
>organizations who are a problem.  I'd really like to force those changes
>out in the open if they aren't going to pay.  The whole point of the
>openlogging stuff was to get people to work out in the open.
>
Umm, I usually use "comment" as my comment for anything not a bugfix, 
but it has nothing to do with your license and fear of people reading 
it, it is purely that my comments go into the source code unless it is a 
bugfix (bugfixes should have user emails attached to them, etc.).

>
>
>I've thought a bit about some sort of answer which addresses this and
>I'm curious to see what people would think if the rule were that your
>changes had to show up on a public server within a given time period
>(a month? 2 months? 3 months?).  In other words, factor in a reasonable
>ability to work in privacy but make it be limited enough that it only
>works for truly free software.
>
I'd be happy.

>
>
>My definition of free software is anything where the source is publically
>available.  It's sometimes called "Open Source".  Open source software
>where you can't get at the source is lame.
>
Call it accessible source, this is my term which allows for pay for use 
software whose source code is available for all to read.  If you want to 
require the software to be free as well, then call it free and 
accessible source.  (But please don't forbid it from being pay for use 
as well as free like reiserfs is.....)

I believe that the antitrust laws should be interpreted as requiring 
software source code to be accessible for any software for which there 
might be a market for improvements to it.  This of course assumes that 
the government has any intention of enforcing the anti-trust laws.... 
which the current administration surely does not.

Hans

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Florian Weimer]

Hans Reiser <reiser@namesys.com> writes:

> Another model you might consider, one which would probably make you
> more money, make us happier, and better avoid "freeloaders", would be
> to make bitkeeper free for use with free software only.  This would be
> rather similar to what I use for reiserfs, which is free for use with
> free operating systems only,

Really?  I thought ReiserFS was released under the GPL.  Is this no
longer the case?

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[James Simmons]

> > Another model you might consider, one which would probably make you
> > more money, make us happier, and better avoid "freeloaders", would be
> > to make bitkeeper free for use with free software only.  This would be
> > rather similar to what I use for reiserfs, which is free for use with
> > free operating systems only,
> 
> Really?  I thought ReiserFS was released under the GPL.  Is this no
> longer the case?

Because something is GPL doesn't mean it is free dollar wise. GPL is free
as in free speech not free beer.

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Florian Weimer]

James Simmons <jsimmons@transvirtual.com> writes:

>> > Another model you might consider, one which would probably make you
>> > more money, make us happier, and better avoid "freeloaders", would be
>> > to make bitkeeper free for use with free software only.  This would be
>> > rather similar to what I use for reiserfs, which is free for use with
>> > free operating systems only,
>> 
>> Really?  I thought ReiserFS was released under the GPL.  Is this no
>> longer the case?
>
> Because something is GPL doesn't mean it is free dollar wise. GPL is free
> as in free speech not free beer.

That's not my point.  Of course you can charge for GPLed software, or,
as the copyright holder, offer different licensing options for a fee.

However, if you release software under the GPL, you do not prevent
people from using it on proprietary operating systems.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

RE: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Torrey Hoffman]

Florian Weimer wrote:
[...]
> >> > rather similar to what I use for reiserfs, which is free 
> for use with
> >> > free operating systems only,
> >> 
> >> Really?  I thought ReiserFS was released under the GPL.  Is this no
> >> longer the case?
> >
> > Because something is GPL doesn't mean it is free dollar 
> wise. GPL is free
> > as in free speech not free beer.
> 
> That's not my point.  Of course you can charge for GPLed software, or,
> as the copyright holder, offer different licensing options for a fee.
> 
> However, if you release software under the GPL, you do not prevent
> people from using it on proprietary operating systems.

well, technically that's true.  However they would not be able to link 
it into the proprietary operating system and then distribute it without 
violating the GPL.  

So the only ways to put reiserFS on (say) Win2K would be to:

- Pay for and get a separate, non-GPL license from Hans Reiser and 
  his team, which is perfectly legitimate for them to do as the 
  copyright holders,

- or, implement it in _user-space_ as an entirely GPL'ed application.
  Obviously this second option would be difficult, I don't know 
  if Win2K supports user-space filesystems at all.  At the least, it 
  would have negative performance and reliability implications...

- or, do whatever you want but never distribute it at all.

Not to speak for Mr. Reiser, but I believe that's what he meant when
he said it's free for use with free operating systems only.

Finally, that second option could be even more difficult... I hear 
MS has recently changed the terms of their C run-time-library license
to forbid use by GPLed code. If so, you'd have to use a different C 
library for Windows...

Torrey Hoffman

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Florian Weimer]

"Torrey Hoffman" <Torrey.Hoffman@myrio.com> writes:

> well, technically that's true.  However they would not be able to link 
> it into the proprietary operating system and then distribute it without 
> violating the GPL.

Are you sure?  Here's a quote from the GPL:

| However, as a special exception, the source code distributed need not
| include anything that is normally distributed (in either source or
| binary form) with the major components (compiler, kernel, and so on)
| of the operating system on which the executable runs, unless that
| component itself accompanies the executable.

Modules for proprietary kernels seem to be okay, don't they?

> - or, implement it in _user-space_ as an entirely GPL'ed application.

I don't see the user space requirement.

> Finally, that second option could be even more difficult... I hear 
> MS has recently changed the terms of their C run-time-library license
> to forbid use by GPLed code.

This is extremely unlikely, as Microsoft is selling its own version of
an operation system with GNU components. ;-)

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: ReiserFS Bug Fixes 3 of 6 (Please apply all 6)

[Alan Cox]

> | binary form) with the major components (compiler, kernel, and so on)
> | of the operating system on which the executable runs, unless that
> | component itself accompanies the executable.
> 
> Modules for proprietary kernels seem to be okay, don't they?

It doesnt normally accompany the executable - thats an irrelevant ite,

> > Finally, that second option could be even more difficult... I hear 
> > MS has recently changed the terms of their C run-time-library license
> > to forbid use by GPLed code.
> 
> This is extremely unlikely, as Microsoft is selling its own version of
> an operation system with GNU components. ;-)

Microsoft are not required to obey their own licenses