Questions on SMR

2 views
Skip to first unread message

Matt Taylor

unread,
Aug 5, 2004, 4:24:28 PM8/5/04
to
So, I've read a bit of the information that was posted in my last
question -- many thanks to all who replied! I was looking at SMR,
particularly because the guarantees it makes are attractive and because the
performance is good. I pulled up a paper by Maged M. Michael on SMR ("Hazard
Pointers: Safe Memory Reclamation for Lock-Free Objects") and have a
rudimentary understanding of how it works now.

SMR cannot ever free hazard pointer structures, right? If I hit a degenerate
case and have to allocate a large number of these, then they are permanently
locked in.

Also, perhaps my understanding is flawed, but does SMR put no bound on the
amount of time before memory is reclaimed in the absense of thread failures?
What I mean is that it seems that an object may be marked for deletion and
still not deleted even if all hazard pointers to it are released. If hazard
pointers still point to the object when it is marked for deletion, then it
is only queued for deletion. Until the thread that marked it for deletion
returns to re-evaluate the object, it will not be deleted. If the thread
does not return to re-evaluate the object for deletion, then its deletion
may be postponed indefinitely, even though the maximum number of objects for
which this can occur is bounded.

-Matt


Joe Seigh

unread,
Aug 5, 2004, 5:38:35 PM8/5/04
to

Matt Taylor wrote:
>
> So, I've read a bit of the information that was posted in my last
> question -- many thanks to all who replied! I was looking at SMR,
> particularly because the guarantees it makes are attractive and because the
> performance is good. I pulled up a paper by Maged M. Michael on SMR ("Hazard
> Pointers: Safe Memory Reclamation for Lock-Free Objects") and have a
> rudimentary understanding of how it works now.
>
> SMR cannot ever free hazard pointer structures, right? If I hit a degenerate
> case and have to allocate a large number of these, then they are permanently
> locked in.
>

No, there's no reason you cannot deallocate them if no threads are going to
use them any more. Whether you have a mechanism to do it and whether it's
worth it is another matter. It would depend on your implementation.


> Also, perhaps my understanding is flawed, but does SMR put no bound on the
> amount of time before memory is reclaimed in the absense of thread failures?
> What I mean is that it seems that an object may be marked for deletion and
> still not deleted even if all hazard pointers to it are released. If hazard
> pointers still point to the object when it is marked for deletion, then it
> is only queued for deletion. Until the thread that marked it for deletion
> returns to re-evaluate the object, it will not be deleted. If the thread
> does not return to re-evaluate the object for deletion, then its deletion
> may be postponed indefinitely, even though the maximum number of objects for
> which this can occur is bounded.
>

Just for that object. You have the same problem with Boehm GC. That's not
considered a big problem. It is a problem for proxy GC schemes like RCU
which has various schemes to deal with it.

Joe Seigh

SenderX

unread,
Aug 5, 2004, 8:56:57 PM8/5/04
to
> No, there's no reason you cannot deallocate them if no threads are going
to
> use them any more. Whether you have a mechanism to do it and whether it's
> worth it is another matter. It would depend on your implementation.

If you delete a hazard pointer record, a thread could crash. This is only
true if you use the HelpScan function the paper describes.

Multiple threads can be iterating the global lock-free list of hazards. The
list is suppose to be lock-free ( for the HelpScan function ), so locks are
out of the question... you could protect the list with a lock-free proxy gc,
or atomic_ptr each of the hazard pointer records.


Joe Seigh

unread,
Aug 5, 2004, 9:39:38 PM8/5/04
to

I'm not sure what Michael does in his implementation but you can coordinate
the hazard pointers any way you want. Just register the hazard pointers
before you use them and unregister them when you are finished. Normal locking
will work. I'm refering to the structures that the threads store their
references in so the GC routine knows what's being referenced, not the potential
references themselves.

Joe Seigh

Matt Taylor

unread,
Aug 6, 2004, 12:01:44 PM8/6/04
to
"Joe Seigh" <jsei...@xemaps.com> wrote in message
news:4112AB12...@xemaps.com...

>
>
> Matt Taylor wrote:
> >
> > So, I've read a bit of the information that was posted in my last
> > question -- many thanks to all who replied! I was looking at SMR,
> > particularly because the guarantees it makes are attractive and because
the
> > performance is good. I pulled up a paper by Maged M. Michael on SMR
("Hazard
> > Pointers: Safe Memory Reclamation for Lock-Free Objects") and have a
> > rudimentary understanding of how it works now.
> >
> > SMR cannot ever free hazard pointer structures, right? If I hit a
degenerate
> > case and have to allocate a large number of these, then they are
permanently
> > locked in.
> >
> No, there's no reason you cannot deallocate them if no threads are going
to
> use them any more. Whether you have a mechanism to do it and whether it's
> worth it is another matter. It would depend on your implementation.

Wouldn't that run into the same memory management problems that plague
lockless structures in general? Either one would have to lock the hazard
list or use a scheme like RCU.

> > Also, perhaps my understanding is flawed, but does SMR put no bound on
the
> > amount of time before memory is reclaimed in the absense of thread
failures?
> > What I mean is that it seems that an object may be marked for deletion
and
> > still not deleted even if all hazard pointers to it are released. If
hazard
> > pointers still point to the object when it is marked for deletion, then
it
> > is only queued for deletion. Until the thread that marked it for
deletion
> > returns to re-evaluate the object, it will not be deleted. If the thread
> > does not return to re-evaluate the object for deletion, then its
deletion
> > may be postponed indefinitely, even though the maximum number of objects
for
> > which this can occur is bounded.
> >
>
> Just for that object. You have the same problem with Boehm GC. That's
not
> considered a big problem. It is a problem for proxy GC schemes like RCU
> which has various schemes to deal with it.

I know it is not considered a big problem; however, it would be desirable to
collect objects when they are freed and not delay (possibly infinitely).
This is especially true for me since each object may be quite large. The
structures holds per-thread data for a debugger that is similar to valgrind
in function, except it is completely threaded. The per-thread structure
holds an instruction backtrace cache of user configurable size. (I typically
set this to 1 million which is 44MB *per* thread.) There are some other
structures which are managed in a similar fashion and can grow quite large.
Thus it is rather important to me to free these in a timely manner lest I
exhaust memory.

This is also why I asked about the inability to free HPs. If HPs can be
freed, then I can simply allocate a few as part of my thread structure and
free them when the thread cleans itself up. This element is not as
important: since HPs are small, it is of minor consequence if they stick
around. I only need to protect thread creation/deletions, so unless the app
is something akin to a fork() bomb, I shouldn't need many HPs.

I am thinking that there should exist some method of extension to SMR with
R=1 that, in the absense of thread delays/crashes, would guarantee bounded
time before an object is considered available for reuse. Have none been
documented? I have a rough idea of how it might be done.

-Matt


Joe Seigh

unread,
Aug 6, 2004, 12:31:03 PM8/6/04
to

Matt Taylor wrote:
>
> "Joe Seigh" <jsei...@xemaps.com> wrote in message
> news:4112AB12...@xemaps.com...
> >
> >

> > No, there's no reason you cannot deallocate them if no threads are going
> to
> > use them any more. Whether you have a mechanism to do it and whether it's
> > worth it is another matter. It would depend on your implementation.
>
> Wouldn't that run into the same memory management problems that plague
> lockless structures in general? Either one would have to lock the hazard
> list or use a scheme like RCU.

I'm not sure what everyone thinks is the problem here. There's nothing that
says you can't use locks as part of an SMR implementation. I use locks
in my RCU implementations to manage a list of per thread data structures.
The locks aren't used in RCU read critical regions so there is no performance
issues because of them.

...

> > Just for that object. You have the same problem with Boehm GC. That's
> not
> > considered a big problem. It is a problem for proxy GC schemes like RCU
> > which has various schemes to deal with it.
>
> I know it is not considered a big problem; however, it would be desirable to
> collect objects when they are freed and not delay (possibly infinitely).

With time sliced threading you have that problem with any scheme that allows
a thread to get suspended while accessing a resource. There are various schemes
that have been used to try to deal with it like priority inheritance for locks
or disabling interrupts.

You don't notice the problem with conventional locking because what happens is that
if most of the threads end up blocking on the lock, it's more likely the thread
holding the lock will get dispatched again simply because there are no other threads
for the dispatcher to run.

RCU in the kernel doesn't have this problem since for the most part, RCU quiescent
states happen quite frequently. There are some kernel threads that run longer than
they should but I believe they are working on voluntary preemption to help deal with
that since it causes other problems for the kernel.

There are other ways of dealing with the problem but it would probably require
modifications to the kernel.

Joe Seigh

Ronald Landheer-Cieslak

unread,
Aug 6, 2004, 4:35:40 PM8/6/04
to
Joe Seigh wrote:

IIRC, MM Micheal has a static amount of hazard pointers - bound to the
maximal number of threads he will use.

My implementation (libmemory, CVS at
http://cvs.sourceforge.net/viewcvs.py/jail-ust/libmemory/) uses a
singly-linked list of hazard pointer-containing structures (one
structure per thread, a fixed number of hazard pointers per structure -
the number to use is passed as an argument to the library initialisation
routine)

Also, on thread death, my implementation will try to delete every
remaining queued deletion. I'm actually not sure that that's a good
idea, but I guess it seemed so at the time ;)

rlc

Ronald Landheer-Cieslak

unread,
Aug 6, 2004, 4:46:42 PM8/6/04
to
Matt Taylor wrote:

> So, I've read a bit of the information that was posted in my last
> question -- many thanks to all who replied! I was looking at SMR,
> particularly because the guarantees it makes are attractive and because the
> performance is good. I pulled up a paper by Maged M. Michael on SMR ("Hazard
> Pointers: Safe Memory Reclamation for Lock-Free Objects") and have a
> rudimentary understanding of how it works now.
>
> SMR cannot ever free hazard pointer structures, right? If I hit a degenerate
> case and have to allocate a large number of these, then they are permanently
> locked in.

The per-thread hazard pointers can be deleted when the thread dies (when
there is no longer any need for them) - though that depends on how you
implement them. In MM Micheal's proposed implementation, IIRC, they're
in a static array, so their life-time would be the same as the process'

As for whatever those pointers point to - as long as there are hazardous
references to an object, the object's memory can not be freed.

> Also, perhaps my understanding is flawed, but does SMR put no bound on the
> amount of time before memory is reclaimed in the absense of thread failures?
> What I mean is that it seems that an object may be marked for deletion and
> still not deleted even if all hazard pointers to it are released. If hazard
> pointers still point to the object when it is marked for deletion, then it
> is only queued for deletion. Until the thread that marked it for deletion
> returns to re-evaluate the object, it will not be deleted. If the thread
> does not return to re-evaluate the object for deletion, then its deletion
> may be postponed indefinitely, even though the maximum number of objects for
> which this can occur is bounded.

The only way you could "fix" this is by allowing other threads to access
the same dlist - i.e. make it a single, global list. It's possible, but
it presents a chicken-and-egg problem if you want that list to be
dynamic and non-blocking.. (I.e. how are you going to handle its memory
- with SMR?)

Of course, you could use an rw-lock on the global dlist and w-lock it
only when you resize it - e.g. for starting a new thread, which would
allocate new hptrs.

Or, you could do what I do in my smr implementation for the local lists
- i.e. check their size when they fill up and swap for a new one - it
should be rather trivial to change that to doing it on a global list.
I.e., if you want, you can write the patch and I'll write you a GPL
waiver :)

rlc

Matt Taylor

unread,
Aug 8, 2004, 6:49:19 PM8/8/04
to
"Ronald Landheer-Cieslak" <ron...@landheer.com> wrote in message
news:2ni98gF...@uni-berlin.de...

> Matt Taylor wrote:
>
> > So, I've read a bit of the information that was posted in my last
> > question -- many thanks to all who replied! I was looking at SMR,
> > particularly because the guarantees it makes are attractive and because
the
> > performance is good. I pulled up a paper by Maged M. Michael on SMR
("Hazard
> > Pointers: Safe Memory Reclamation for Lock-Free Objects") and have a
> > rudimentary understanding of how it works now.
> >
> > SMR cannot ever free hazard pointer structures, right? If I hit a
degenerate
> > case and have to allocate a large number of these, then they are
permanently
> > locked in.
> The per-thread hazard pointers can be deleted when the thread dies (when
> there is no longer any need for them) - though that depends on how you
> implement them. In MM Micheal's proposed implementation, IIRC, they're
> in a static array, so their life-time would be the same as the process'

He also mentions a linked list extension but gives no information with
regard to freeing the HPs in the list. His pseudocode only allocates and
releases them; it never frees.

So in your libmemory, the relevant functions are hptr_register and
hptr_free? What would happen if a thread were exiting as other threads were
traversing the HP list? Seems to me that it's possible to crash if a thread
was switched out while traversing the HP list and another thread exited.

[...]

What I was thinking was to have threads pass off responsibility for the
object. HPs would be extended with an ownership tag. If the tag is set, the
thread that owns the HP has to execute a scan on the object when the HP is
cleared. The maximum time complexity for deletion of one object is linear --
it is equal to the length of the HP list at the time the object was marked
for deletion.

Upon finding an HP that referenced an object pending deletion, the thread
would test-and-set its ownership tag and then verify that the HP was still
active. If not, then the ownership tag is checked to see whether or not the
other thread saw the test-and-set before it freed the HP. If still set, then
the search continues as the HP has been freed and the object has not. In the
other two cases, the responsibility of deleting the object has been
successfully passed to the thread that owns the HP.

While I have talked of test-and-set and an ownership flag, I suspect a
working implementation would need to use CAS or possibly a double-width CAS
in order to prevent race conditions on the hand-off. The problem is, of
course, that an object can be passed off to an HP that is in the middle of
being recycled (though not yet seen by the thread). I have a few ideas on
alternate ways to implement this (perhaps an auxillary pointer that is set
to point to the object to indicate possession), but as of yet none that
would actually work.

-Matt


Joe Seigh

unread,
Aug 9, 2004, 8:11:07 AM8/9/04
to

Matt Taylor wrote:
>
> "Ronald Landheer-Cieslak" <ron...@landheer.com> wrote in message
> news:2ni98gF...@uni-berlin.de...

> > The per-thread hazard pointers can be deleted when the thread dies (when
> > there is no longer any need for them) - though that depends on how you
> > implement them. In MM Micheal's proposed implementation, IIRC, they're
> > in a static array, so their life-time would be the same as the process'
>
> He also mentions a linked list extension but gives no information with
> regard to freeing the HPs in the list. His pseudocode only allocates and
> releases them; it never frees.
>
> So in your libmemory, the relevant functions are hptr_register and
> hptr_free? What would happen if a thread were exiting as other threads were
> traversing the HP list? Seems to me that it's possible to crash if a thread
> was switched out while traversing the HP list and another thread exited.
>


You'd need two hazard pointers per thread for scanning the hazard pointer
list. These hazard pointers could themselves never be deleted.

Other than those two special hazard pointers, you can't have any other
hazard pointers set when you scan the list as you would risk deadlock.

Joe Seigh

Joe Seigh

unread,
Aug 9, 2004, 12:47:41 PM8/9/04
to


> You'd need two hazard pointers per thread for scanning the hazard pointer
> list. These hazard pointers could themselves never be deleted.
>
> Other than those two special hazard pointers, you can't have any other
> hazard pointers set when you scan the list as you would risk deadlock.
>

It would be easier to set up the permannent hazard pointers in a separate
list. You wouldn't need hazard pointers to scan that list.

I don't think it's worth all that trouble. Just don't decallocate hazard
pointers ever. End of problem.

Joe Seigh

Ronald Landheer-Cieslak

unread,
Aug 9, 2004, 2:04:31 PM8/9/04
to
Matt Taylor wrote:
> "Ronald Landheer-Cieslak" wrote
(please don't quote raw E-mail addresses in your "blah wrote" line: I
get enough spam as is - thanks :)

>> The per-thread hazard pointers can be deleted when the thread dies
>> (when there is no longer any need for them) - though that depends
>> on how you implement them. In MM Micheal's proposed implementation,
>> IIRC, they're in a static array, so their life-time would be the
>> same as the process'
> He also mentions a linked list extension but gives no information
> with regard to freeing the HPs in the list. His pseudocode only
> allocates and releases them; it never frees.
>
> So in your libmemory, the relevant functions are hptr_register and
> hptr_free? What would happen if a thread were exiting as other
> threads were traversing the HP list? Seems to me that it's possible
> to crash if a thread was switched out while traversing the HP list
> and another thread exited.

It looks like you've found a bug :|

A solution would be to do as Joe Seigh said elsethread (i.e. in response
to your post) to use hazard pointers and have them point to the hptr
structure. Another would be to use a refcount, which shouldn't actually
cost too much because the structure is local anyway, so the risk of
contention on the counter is minimal..

Another possibility would be to simply not delete the structure but put
it in a "free list", available for use by another thread when a new one
starts. That would pool the hptr objects or create new ones if one is
not available..

I've jotted this down as a bug to fix - patches will be rewarded with a
GPL waiver :)

I think the approach is a bit elaborate: why not just NULL out the hptrs
when the thread dies, put them in a shared list of recycle-able hptrs
and let them be re-used by other threads? If a thread comes accross an
orphined hptr, it is either already nulled out or still holding its old
value. If holding its old value, the hazardous reference is technically
still there and will be until the nulling-out is done. The patch to
libmemory would be minimal: just a change to hptr_cleanup_local_data()
to null out and put in the smr_global_data->hptr_pool in stead of
deleting; hptr_get_local_data() to look at smr_global_data->hptr_pool to
see if something is available there in stead of always creating a new
hptr set and the smr_global_data_t structure to add an hptr_pool field.

I don't really see the need of an hptr "knowing" whom it belongs to..

As for DCAS: I try to avoid them as much as possible, because many
processors don't have such an instruction..

rlc

Matt Taylor

unread,
Aug 10, 2004, 1:46:32 PM8/10/04
to
"Ronald Landheer-Cieslak" wrote in message
news:2npsscF...@uni-berlin.de...
> Matt Taylor wrote:
[...]

There were two separate ideas I was persuing. I'm not talking about
allocating/freeing HPs here. I'm talking about reclaiming the memory they
point to. M. Michael's presentation of SMR bounds the maximum number of
unfreed objects, but it doesn't bound the amount of time before they are
freed. It is very important for my purposes that objects be freed as soon as
all references to them have expired.

> I don't really see the need of an hptr "knowing" whom it belongs to..

It doesn't. I'm referring to an object in SMR having some associated thread
which is allowed to free it. The idea isn't expressed explicitly in the
paper, but that is, of course, what rlist is for. No two threads can
simultaneously contend to free the same object. What I am talking about is
the ability for threads in SMR to pass the buck to other threads. Threads
releasing HPs check to see whether or not they have been made responsible
for freeing the object, and if so, they have to execute the scan algorithm.

> As for DCAS: I try to avoid them as much as possible, because many
> processors don't have such an instruction..

[Aside: I've seen the acronym DCAS seemingly refer both to a double-width
CAS and to a double CAS; is there any "standard" terminology that
disambiguates the two?]

It would be nice indeed to only need CAS. Every solution I can think of
inevitably requires a double-width CAS.

-Matt


SenderX

unread,
Aug 10, 2004, 7:24:40 PM8/10/04
to
> There were two separate ideas I was persuing. I'm not talking about
> allocating/freeing HPs here. I'm talking about reclaiming the memory they
> point to. M. Michael's presentation of SMR bounds the maximum number of
> unfreed objects, but it doesn't bound the amount of time before they are
> freed. It is very important for my purposes that objects be freed as soon
as
> all references to them have expired.

SMR is really designed to reclaim the memory of lock-free nodes, which are
very small objects... Not the objects, which may be huge, that a node may
point to.

So, using SMR for large objects would require modifications that would
probably reduce its efficiency.

You could try Joe's atomic_ptr:

http://groups.google.com/groups?selm=3FDE3890.79C24B88%40xemaps.com&rnum=12

This is a real beauty!


>
> [Aside: I've seen the acronym DCAS seemingly refer both to a double-width
> CAS and to a double CAS; is there any "standard" terminology that
> disambiguates the two?]

I don' think so... I am going to start using DWCAS for double-width and DCAS
for double.

;)


Ronald Landheer-Cieslak

unread,
Aug 11, 2004, 10:56:33 AM8/11/04
to
Matt Taylor wrote:

In that case, I think SMR is not what you want: looks like you need a
proxy gc, reference counter or some such idiom: SMR doesn't guarantee
anything about the timing..

You could adapt it a bit, though: launch a separate thread that
periodically scans a global dlist and the hptrs and frees whatever it
can free..

>>I don't really see the need of an hptr "knowing" whom it belongs to..
> It doesn't. I'm referring to an object in SMR having some associated thread
> which is allowed to free it. The idea isn't expressed explicitly in the
> paper, but that is, of course, what rlist is for. No two threads can
> simultaneously contend to free the same object. What I am talking about is
> the ability for threads in SMR to pass the buck to other threads. Threads
> releasing HPs check to see whether or not they have been made responsible
> for freeing the object, and if so, they have to execute the scan algorithm.

You could do that, but you'd fall into the same trap as I did: my
threads try to free the contents of their dlists at thread exit and
block if they can't - another reason to have only one global dlist..

>>As for DCAS: I try to avoid them as much as possible, because many
>>processors don't have such an instruction..
> [Aside: I've seen the acronym DCAS seemingly refer both to a double-width
> CAS and to a double CAS; is there any "standard" terminology that
> disambiguates the two?]

Eh, perhaps we should say WCAS for "wide" CAS and DCAS for double CAS?
In that case, I try avoiding WCAS and definitely avoid DCAS :)

> It would be nice indeed to only need CAS. Every solution I can think of
> inevitably requires a double-width CAS.

The shared dlist solution I have in mind requires only a normal CAS: the
logic of replacing the shared dlist if the number of threads changes
(already implemented in libmemory) only requires a single CAS as well..

rlc

Ronald Landheer-Cieslak

unread,
Aug 11, 2004, 10:56:57 AM8/11/04
to
Matt Taylor wrote:

In that case, I think SMR is not what you want: looks like you need a
proxy gc, reference counter or some such idiom: SMR doesn't guarantee
anything about the timing..

You could adapt it a bit, though: launch a separate thread that
periodically scans a global dlist and the hptrs and frees whatever it
can free..

>>I don't really see the need of an hptr "knowing" whom it belongs to..


> It doesn't. I'm referring to an object in SMR having some associated thread
> which is allowed to free it. The idea isn't expressed explicitly in the
> paper, but that is, of course, what rlist is for. No two threads can
> simultaneously contend to free the same object. What I am talking about is
> the ability for threads in SMR to pass the buck to other threads. Threads
> releasing HPs check to see whether or not they have been made responsible
> for freeing the object, and if so, they have to execute the scan algorithm.

You could do that, but you'd fall into the same trap as I did: my
threads try to free the contents of their dlists at thread exit and
block if they can't - another reason to have only one global dlist..

>>As for DCAS: I try to avoid them as much as possible, because many


>>processors don't have such an instruction..
> [Aside: I've seen the acronym DCAS seemingly refer both to a double-width
> CAS and to a double CAS; is there any "standard" terminology that
> disambiguates the two?]

Eh, perhaps we should say WCAS for "wide" CAS and DCAS for double CAS?
In that case, I try avoiding WCAS and definitely avoid DCAS :)

> It would be nice indeed to only need CAS. Every solution I can think of


> inevitably requires a double-width CAS.

The shared dlist solution I have in mind requires only a normal CAS: the
logic of replacing the shared dlist if the number of threads changes

(already partially implemented in libmemory) only requires a single CAS
as well..

rlc

Ronald Landheer-Cieslak

unread,
Aug 11, 2004, 11:17:00 AM8/11/04
to
SenderX wrote:

>> There were two separate ideas I was persuing. I'm not talking about
>> allocating/freeing HPs here. I'm talking about reclaiming the
>> memory they point to. M. Michael's presentation of SMR bounds the
>> maximum number of unfreed objects, but it doesn't bound the amount
>> of time before they are freed. It is very important for my purposes
>> that objects be freed as soon as all references to them have
>> expired.
> SMR is really designed to reclaim the memory of lock-free nodes,
> which are very small objects... Not the objects, which may be huge,
> that a node may point to.

Very true, but it'll work just as well if adapted a bit to make the
latency between the time smr_free() is called and the time the object is
actually deleted is diminished a bit - e.g. by using a single, shared
dlist and (optionally) having a gc thread check it against the hptrs
regularly. The impact of such a patch wouldn't be all that big/bad and
I'd guess the performance for the operation SMR was designed for
wouldn't suffer too much either - although the dlist being local may
help with caching.. (i.e. it avoids contention on a global dlist).

> So, using SMR for large objects would require modifications that would
> probably reduce its efficiency.

> You could try Joe's atomic_ptr:
> http://groups.google.com/groups?selm=3FDE3890.79C24B88%40xemaps.com&rnum=12
> This is a real beauty!

So this is the famous atomic_ptr ? ;)
I really should take a closer look at it - looks like a good candidate
for inclusion in libmemory or libcontain :)

rlc

ron...@landheer.com

unread,
Aug 11, 2004, 11:51:11 AM8/11/04
to
This message was cancelled from within Mozilla.

Joe Seigh

unread,
Aug 11, 2004, 1:32:06 PM8/11/04
to

Ronald Landheer-Cieslak wrote:
>
> SenderX wrote:

> > http://groups.google.com/groups?selm=3FDE3890.79C24B88%40xemaps.com&rnum=12
> > This is a real beauty!
> So this is the famous atomic_ptr ? ;)
> I really should take a closer look at it - looks like a good candidate
> for inclusion in libmemory or libcontain :)
>

I've gotten rid of that atomic_pool and gone with a "unsafe" C type
interface for putting things into the pool, currently "void (*)(void *)"
which is just a static free/delete type interface but will probably go
to a pseudo functor interface (pool object + static method to invode
pool objects method). It doesn't seem worth it to go through all the
trouble with derived C++ classes with virtual methods just to simulate
what you can do with Java interfaces.

But not significant enough to repost yet. Kind of a work in progress
but mostly not in progress unless I need to do something with it like
I did recently with the mutex vs. atomic_ptr vs. various RCU implementations.

Joe Seigh

Ronald Landheer-Cieslak

unread,
Aug 11, 2004, 1:31:13 PM8/11/04
to
Have you thought of/considered to put it on a site like SourceForge and
license it with a MIT or BSD-like license?

rlc

Joe Seigh

unread,
Aug 11, 2004, 1:47:09 PM8/11/04
to

Ronald Landheer-Cieslak wrote:
>
> Have you thought of/considered to put it on a site like SourceForge and
> license it with a MIT or BSD-like license?
>

Probably GPL just to annoy Alexander. :)

Actually which license doesn't matter to me since there's not enough code
to worry about w.r.t. copyright and the algorithms is in public domain.
I'm not sure it would go out as a "project". I make no claims that is
production quality and have done tool projects where people with way
more time than you have and for whom no function is too trivial to put
in will add in a zillion lines of code, send you the update and ask you
to put it in. But with a license on it, you could always fork it off
as a separate project.

Joe Seigh

Alexander Terekhov

unread,
Aug 11, 2004, 2:03:36 PM8/11/04
to

Joe Seigh wrote:
[...]

> Probably GPL just to annoy Alexander. :)

Apart from Munich district (possible appeal in the Sitecom case
aside for a moment), the GPL is preempted by The First Sale (aka
"community exhaustion for the distribution right" in the EU).

regards,
alexander.

Joe Seigh

unread,
Aug 11, 2004, 2:37:35 PM8/11/04
to

Preempt? What does "preempting" a copyright mean?

Joe Seigh

Alexander Terekhov

unread,
Aug 11, 2004, 2:53:29 PM8/11/04
to

It means that the statute gives the permission to distribute --
the thing that the GPL purports to restrict (condition it). One
can "preempt"[1] 17 USC 109 using a binding contract... but the
GPL is NOT a binding contract (you'd need things like "I accept"
buttons[2] in addition to a clear formulation of contract
restrictions and waive of rights[3]).

regards,
alexander.

[1] The Libraries say that

http://www.copyright.gov/reports/studies/dmca/reply/Reply008.pdf

<quote>

Copyright Act should state unambiguously that non-negotiated
license terms are pre-empted to the extent that they conflict
with the Act. Consistent with the model from the Boucher-
Campbell Bill cited above (in Section II of these comments)
and supported by the Libraries and a broad coalition of
interested parties, H.R. 3048, section 301(a) of the title 17,
United States Code should be amended by adding the following
at the end thereof:

When a work is distributed to the public subject to non-
negotiable license terms, such terms shall not be enforceable
under the common law or statutes of any state to the extent
that they:

(1) limit the reproduction, adaptation, distribution,
performance, or display, by means of transmission or otherwise,
of material that is uncopyrightable under section 102(b) or
otherwise; or

(2) abrogate or restrict the limitations on exclusive rights
specified in sections 107 through 114 and sections 117, 118
and 121 of this title.”

</quote>

That would mean that "I accept" buttons (and things like
that) won't work with respect to waiving 17 USC 109 right.
That would be great.

[2] http://www.rosenlaw.com/html/GL19.pdf

[3] For example,

http://www.opensource.org/licenses/cpl.php

<quote>

No party to this Agreement will bring a legal action under
this Agreement more than one year after the cause of action
arose. Each party waives its rights to a jury trial in any
resulting litigation.

</quote>

Joe Seigh

unread,
Aug 11, 2004, 3:33:33 PM8/11/04
to

Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> >
> > Alexander Terekhov wrote:
> > >
> > > Joe Seigh wrote:
> > > [...]
> > > > Probably GPL just to annoy Alexander. :)
> > >
> > > Apart from Munich district (possible appeal in the Sitecom case
> > > aside for a moment), the GPL is preempted by The First Sale (aka
> > > "community exhaustion for the distribution right" in the EU).
> > >
> >
> > Preempt? What does "preempting" a copyright mean?
>
> It means that the statute gives the permission to distribute --
> the thing that the GPL purports to restrict (condition it). One
> can "preempt"[1] 17 USC 109 using a binding contract... but the
> GPL is NOT a binding contract (you'd need things like "I accept"
> buttons[2] in addition to a clear formulation of contract
> restrictions and waive of rights[3]).


The GPL is not a contract. Not being a contract, there is no
requirement for anyone to accept it. It merely states the
conditions under which the copyrighted work may be redistributed.

Joe Seigh

Joe Seigh

unread,
Aug 11, 2004, 7:40:35 PM8/11/04
to

But don't hold your breath. I was just doing it for entertainment value.
It doesn't really have any other value. And pasting a copyright on it
is too much trouble. It's not that high on my list of priorities.
Sorry, but that's the way things are these days.

Joe Seigh

Alexander Terekhov

unread,
Aug 12, 2004, 4:46:50 AM8/12/04
to

Joe Seigh wrote:
[...]

> The GPL is not a contract. Not being a contract, there is no
> requirement for anyone to accept it. It merely states the
> conditions under which the copyrighted work may be redistributed.

It's really simple. There's no exclusive "redistribution" right.
Exclusive *distribution* right is severly severely by 17 USC 109.

http://groups.google.com/groups?selm=4108B748.256EF70D%40web.de
http://groups.google.com/groups?selm=410B9768.CA12F19E%40web.de
http://groups.google.com/groups?selm=410E3052.289B4CD5%40web.de

regards,
alexander.

Alexander Terekhov

unread,
Aug 12, 2004, 4:48:23 AM8/12/04
to
Joe Seigh wrote:
[...]
> The GPL is not a contract. Not being a contract, there is no
> requirement for anyone to accept it. It merely states the
> conditions under which the copyrighted work may be redistributed.

It's really simple. There's no exclusive "redistribution" right.

Exclusive *distribution* right is severely limited by 17 USC 109.

Joe Seigh

unread,
Aug 12, 2004, 6:56:07 AM8/12/04
to

That's transfer of a copy, not copying. You're quibbling of the
meaning of "redistribution".

There was an analysis of the GPL by one of the EFF lawyers I think
that went over all of this. Don't know where that was. I thought
it was on Groklaw but I don't see it there now.

Joe Seigh

Joe Seigh

unread,
Aug 12, 2004, 7:01:36 AM8/12/04
to

This particular instance has nothing to do with copyright.
It's purely an economic issue. T.A.N.S.T.A.F.S.
There ain't no such thing as free software. You have to pay
for it. You think NPTL or NGTL was done for free? That was
paid for.

Joe Seigh

Alexander Terekhov

unread,
Aug 12, 2004, 8:01:21 AM8/12/04
to

Joe Seigh wrote:
>
> This particular instance has nothing to do with copyright.

What particular instance? Windows OEM case in Germany aside for a
moment, I've referred you to the following cases:

http://www.nysd.uscourts.gov/courtweb/pdf/D02NYSC/01-07482.PDF
http://www.cacd.uscourts.gov/cacd/RecentPubOp.nsf/0/1c0109b1a49387b288256b48007a04cd/$FILE/CV00-04161DDP.pdf

> It's purely an economic issue. T.A.N.S.T.A.F.S.
> There ain't no such thing as free software. You have to pay
> for it.

Really? How many copies do you need?

> You think NPTL or NGTL was done for free? That was paid for.

Yes. And?

regards,
alexander.

Alexander Terekhov

unread,
Aug 12, 2004, 8:05:57 AM8/12/04
to

Joe Seigh wrote:
[...]

> That's transfer of a copy, not copying. You're quibbling of the
> meaning of "redistribution".

Lawfully made copies don't become illegal just because they change
owners.

>
> There was an analysis of the GPL by one of the EFF lawyers I think
> that went over all of this. Don't know where that was. I thought
> it was on Groklaw but I don't see it there now.

There's none. Well, apart from

http://groups.google.com/groups?selm=410BBE36.E287428%40web.de

;-)

regards,
alexander.

Joe Seigh

unread,
Aug 12, 2004, 8:25:45 AM8/12/04
to

Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> [...]
> > That's transfer of a copy, not copying. You're quibbling of the
> > meaning of "redistribution".
>
> Lawfully made copies don't become illegal just because they change
> owners.
>

Your allowed to make as many exact copies as you like and there is
no restriction on how you may redistribute those copies. There is
a restriction on conditions for making derivative works of the the
orginal copy.

Joe Seigh

Joe Seigh

unread,
Aug 12, 2004, 8:35:31 AM8/12/04
to

Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> >
> > This particular instance has nothing to do with copyright.
>
> What particular instance? Windows OEM case in Germany aside for a
> moment, I've referred you to the following cases:
>
> http://www.nysd.uscourts.gov/courtweb/pdf/D02NYSC/01-07482.PDF
> http://www.cacd.uscourts.gov/cacd/RecentPubOp.nsf/0/1c0109b1a49387b288256b48007a04cd/$FILE/CV00-04161DDP.pdf

That has nothing to do with GPL. If you wish to debate GPL do
it on Groklaw.

>
> > It's purely an economic issue. T.A.N.S.T.A.F.S.
> > There ain't no such thing as free software. You have to pay
> > for it.
>
> Really? How many copies do you need?

That first copy costs.


>
> > You think NPTL or NGTL was done for free? That was paid for.
>
> Yes. And?

You'd better review the so called Open Source business/economic model.
It comes pretty close to voodoo economics. It's not sustainable
in the long run.

Joe Seigh

Alexander Terekhov

unread,
Aug 12, 2004, 8:37:07 AM8/12/04
to

Joe Seigh wrote:
[...]

> Your allowed to make as many exact copies as you like and there is
> no restriction on how you may redistribute those copies. There is
> a restriction on conditions for making derivative works of the the
> orginal copy.

Read the GPL, Joe. It purports to restrict the distribution of both.

As for the FSF's SCOish notion of "derivative work", take this:

http://groups.google.com/groups?selm=40EDB041.E681930C%40web.de

You might also want to spend 12 bucks and buy westlaw.com's copy of

"Christian H. Nadan, Note, A Proposal to Recognize Component
Works: How a Teddy Bears on the Competing Ends of Copyright
Law, 78 Cal.L.Rev."

It talks about Whelan (SCO's beef), etc. BTW, it's cited in

http://courses.cs.vt.edu/~cs4984/computerlaw/lewis.doc
("LEWIS GALOOB TOYS, INC. v. NINTENDO OF AMERICA, INC.")

<quote>

Some time ago, for example, computer companies began marketing
spell-checkers that operate within existing word processors by
signalling the writer when a word is misspelled. These
applications, as well as countless others, could not be produced
and marketed if courts were to conclude that the word processor
and spell-checker combination is a derivative work based on the
word processor alone. The Game Genie is useless by itself, it
can only enhance, and cannot duplicate or recaste, a Nintendo
game[... "output" ...] nor does it supplant demand for Nintendo
game cartridges. Such innovations rarely will constitute
infringing derivative works under the Copyright Act. See
generally Nadan, supra, at 1667-72.

</quote>

The authour is probably the same "Christian H. Nadan" who wrote
the devastating "legal review" of the idiotic FSF's interpetation
of the GPL:

http://groups.google.com/groups?selm=40EE8CDC.977AE902%40web.de

Hth.

regards,
alexander.

Alexander Terekhov

unread,
Aug 12, 2004, 8:44:54 AM8/12/04
to

Joe Seigh wrote:
[...]

> If you wish to debate GPL do it on Groklaw.

http://tinyurl.com/49r2u
http://tinyurl.com/5kjdf

among others.

regards,
alexander.

Alexander Terekhov

unread,
Aug 12, 2004, 9:08:38 AM8/12/04
to

Joe Seigh wrote:
[...]

> You'd better review the so called Open Source business/economic model.

I've "reviewed" a lot of stuff on this topic. For example, (among
others)

http://www.charvolant.org/~doug/gpl/gpl.pdf
http://www.softpanorama.org/People/Stallman/index.shtml
http://www.softpanorama.org/People/Torvalds/index.shtml
http://www.softpanorama.org/Copyright/License_classification/social_roots_of_GPL.shtml

etc.

Here's a few quotes...

<quote>

IBM "100 featherless penguins
in the steel VM cage" road show

Although Linux put some pressure on AIX, IBM was able much better
capitalize on it than Sun (or HP) and not only sustained much less
damage but even managed to get some ground from both Sun and HP.

The main difference was that Samuel Palmisano saw the possibility
of using Linux as a powerful unifier of desperately different and
sometimes even competing with each other IBM's hardware product
lines as well as for saving VM/CMS. That was a brilliant idea. VM-
based "software partitioning" technology that for many years were
developed in VM/CMS was really unique technology that IBM never
was able to market properly. That might help to explains why IBM
brass closed eyes on potential problems with GPL license and
"crazy guy from Boston". ...

</quote>

Now,

http://news.com.com/IBM%27s+mainframe+momentum+continues/2100-7337_3-5304705.html
(IBM's mainframe momentum continues)

<quote>

During each of the last three quarters, IBM's mainframe revenue
has grown more than 30 percent on a year-over-year basis.

</quote>

;-) ;-)

regards,
alexander.

Ronald Landheer-Cieslak

unread,
Aug 12, 2004, 9:19:19 AM8/12/04
to
Joe Seigh wrote:
> Joe Seigh wrote:
>>Ronald Landheer-Cieslak wrote:
>>> Have you thought of/considered to put it on a site like
>>> SourceForge and license it with a MIT or BSD-like license?
>> Probably GPL just to annoy Alexander. :)
>> Actually which license doesn't matter to me since there's not
>> enough code to worry about w.r.t. copyright and the algorithms is
>> in public domain. I'm not sure it would go out as a "project". I
>> make no claims that is production quality and have done tool
>> projects where people with way more time than you have and for whom
>> no function is too trivial to put in will add in a zillion lines of
>> code, send you the update and ask you to put it in. But with a
>> license on it, you could always fork it off as a separate project.
> But don't hold your breath.
I won't ;)

> I was just doing it for entertainment value. It doesn't really have
> any other value. And pasting a copyright on it is too much trouble.
> It's not that high on my list of priorities. Sorry, but that's the
> way things are these days.

For now, I've just put made a bookmark to the original version and I'll
keep it in mind if I ever have an immediate need for something closely
like it. By that time, I'll probably get back to this group with it..

Thx

rlc

PS: isn't there a GPL advocacy group for hashing out whether the GPL is
a contract and whether it is binding for redistributions?

Joe Seigh

unread,
Aug 12, 2004, 9:55:18 AM8/12/04
to

Ronald Landheer-Cieslak wrote:
>

> > I was just doing it for entertainment value. It doesn't really have
> > any other value. And pasting a copyright on it is too much trouble.
> > It's not that high on my list of priorities. Sorry, but that's the
> > way things are these days.
> For now, I've just put made a bookmark to the original version and I'll
> keep it in mind if I ever have an immediate need for something closely
> like it. By that time, I'll probably get back to this group with it..
>
> Thx

SenderX has a munged copy of it. That's probably okay for most purposes.
If you are a commercial enterprise you'd need to have IP lawyers to check
it out. Not because I really care because I don't, but just to CYA as
a matter of business prudence. And at least somebody (lawyers) will make
money off of open source.


>
> rlc
>
> PS: isn't there a GPL advocacy group for hashing out whether the GPL is
> a contract and whether it is binding for redistributions?

The FSF (Free Software Foundation) and EFF (Electronic Frontier Foundation?)
Alexander is not a lawyer and the law does not submit to rational analysis,
even if we give Alexander the benefit of the doubt.

Joe Seigh

Ronald Landheer-Cieslak

unread,
Aug 12, 2004, 10:58:42 AM8/12/04
to
Joe Seigh wrote:
> Ronald Landheer-Cieslak wrote:
>>> I was just doing it for entertainment value. It doesn't really
>>> have any other value. And pasting a copyright on it is too much
>>> trouble. It's not that high on my list of priorities. Sorry, but
>>> that's the way things are these days.
>> For now, I've just put made a bookmark to the original version and
>> I'll keep it in mind if I ever have an immediate need for something
>> closely like it. By that time, I'll probably get back to this group
>> with it..
> SenderX has a munged copy of it. That's probably okay for most
> purposes. If you are a commercial enterprise you'd need to have IP
> lawyers to check it out. Not because I really care because I don't,
> but just to CYA as a matter of business prudence. And at least
> somebody (lawyers) will make money off of open source.
I don't do commerce - neither with my code nor anyone else's. I know of
at least two companies that use my code for commercial purposes (and a
third that has since gone down the drain - independantly of using code I
wrote) but the IP problems are *their* problems in that case :)

I do try to avoid copying code from others without at least
acknowledging the original author - e.g. your rw-spinlock algo is now
used in commercial software with an implementation I wrote (not the
libthread implementation, though). The comments have a reference to your
original post where you posted the fetch-and-add and fetch-and-increment
versions, even if the implementation is not quite the same - seems like
the right thing to do IMHO.

Anyways: if/when I need something like atomic_ptr, I'll still have the
bookmark to your post and do some munching of my own :)

thx

rlc

Alexander Terekhov

unread,
Aug 13, 2004, 4:24:00 PM8/13/04
to

Joe Seigh wrote:
[...]

> Alexander is not a lawyer and the law does not submit to rational analysis,
> even if we give Alexander the benefit of the doubt.

I'm not a lawyer. But you don't need to be a lawyer to see that when
it comes to copyright, Stallman (one who wrote the GPL) is a moron.

http://www.stallman.org

<quote>

copyright (c) 1996, [...] 2004 Richard Stallman
Verbatim copying and redistribution of this entire page ...
^^^^^^^^^^^^^^
</quote>

17 USC 109.

regards,
alexander.

Joe Seigh

unread,
Aug 19, 2004, 1:47:27 PM8/19/04
to

Well, IBM is sueing SCO for copyright infringement as reported here
http://www.theregister.co.uk/2004/08/19/ibm_sco_gpl/
and as reported on GrokLaw.

Joe Seigh

Alexander Terekhov

unread,
Aug 19, 2004, 2:14:14 PM8/19/04
to

Joe Seigh

unread,
Aug 19, 2004, 3:14:08 PM8/19/04
to

You must be flush from those 2 patent filings. I'm still waiting for Microsoft
to show up waving handfuls of money.

Joe Seigh

Matt Taylor

unread,
Aug 23, 2004, 4:44:35 AM8/23/04
to
"Joe Seigh" <jsei...@xemaps.com> wrote in message
news:4113B485...@xemaps.com...
>
> Matt Taylor wrote:
> >
[...]
> > I know it is not considered a big problem; however, it would be
desirable to
> > collect objects when they are freed and not delay (possibly infinitely).
>
> With time sliced threading you have that problem with any scheme that
allows
> a thread to get suspended while accessing a resource. There are various
schemes
> that have been used to try to deal with it like priority inheritance for
locks
> or disabling interrupts.
>
> You don't notice the problem with conventional locking because what
happens is that
> if most of the threads end up blocking on the lock, it's more likely the
thread
> holding the lock will get dispatched again simply because there are no
other threads
> for the dispatcher to run.
[...]

Or priority inversion will kick in.

Anyway, over the past 2 weeks I've implemented the solution which I was
talking about before. The time required to free an object is O(n) instead of
O(1) as in traditional SMR, but it also guarantees timely reclaimation of
objects during normal processing. I've got a proof-of-concept implementation
for x86 Windows. The implementation is a bit slow, but it demonstrates that
it is very possible.

I've uploaded the proof-of-concept code:
http://my.fit.edu/~mtaylor/smr/

Comments are welcome. :-)

-Matt


SenderX

unread,
Sep 10, 2004, 2:18:45 AM9/10/04
to
> I've uploaded the proof-of-concept code:
> http://my.fit.edu/~mtaylor/smr/

Nice. dwcas + smr = wow!

:)


SenderX

unread,
Sep 10, 2004, 2:20:36 AM9/10/04
to
> I've uploaded the proof-of-concept code:
> http://my.fit.edu/~mtaylor/smr/
>
> Comments are welcome. :-)

Nice. smr + dwcas = wow!!!

:)


Joe Seigh

unread,
Sep 10, 2004, 8:56:12 AM9/10/04
to

The DCAS is probably not so great a mnemonic given it means
something else.

Pretty slow on c.p.t. if you're going that far back. Even
the other ng's are pretty slow. c.a. doing it's SMP is
Bad, MPI is good for everything. And c.l.c++.m. again
proving that they will never understand threading.

Joe Seigh

Alexander Terekhov

unread,
Nov 23, 2004, 11:33:19 AM11/23/04
to

Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> [...]

> > Probably GPL just to annoy Alexander. :)
>
> Apart from Munich district (possible appeal in the Sitecom case
> aside for a moment), the GPL is preempted by The First Sale (aka
> "community exhaustion for the distribution right" in the EU).

http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL3_20040903.pdf
(The first-ever ruling on the legal validity of the GPL - A Critique
of the Case By Professor Dr Thomas Hoeren, Visiting Fellow at the
Oxford Internet Institute)

<quote>

1. The decision of the District Court of Munich is celebrated as the
first-ever judgement on the validity of the GPL. That is surprising.
The decision is the judgement of only a single district court in
Germany. And it is only a summary and preliminary decision based on
injunctive remedies. Furthermore, the judgement refers to only one
special case within the Open Source scene. There was only one main
developer involved in this project, so there was no need to decide,
for example, on the complicated questions of rights ownership
involved in Linux.

2. Given the high importance that the Open Source community
attributed to the judgement, the Court’s legal arguments are
extremely poor. I do not want to deal with the many spelling and
grammatical mistakes in the original version of the decision; such
things happen in the heat of the moment. But it is even more
astonishing that most of the relevant legal literature has not been
considered. The Court essentially refers only to an essay from
Metzger/Jäger written in 1999, apart from two essays from Omsels and
Plaß. None of the critical voices about the effectiveness of the GPL
have been heard.

3. Apart from these formalities, the argumentation of the judges
raises many questions and prompts many criticisms.

a. The homepage of the plaintiff included a link to the GPL version 2
(June 1991), an American document of the FSF. However, the US version
of the GPL was not considered by the Court. Instead the Court used an
unofficial German translation without devoting even a single sentence
to justifying this approach. The judges also did not mention the
history of the GPL, nor did they ask how the GPL might be interpreted
under US rules on the interpretation of contractual documents. They
simply applied German methodology and concepts to a document whose
legal roots are deeply intermingled with US law and the US Open Source
mentality.

b. The court interpreted the GPL in the light of the German model of
“condition subsequent” based upon Sect. 158 of the German Civil Act
(BGB). The court argued that infringements of the GPL would lead to an
automatic loss of rights, based upon a condition subsequent. The user
of open source products gets the license to use the product only on the
condition that, and as long as, he sticks to the rules of the GPL. The
Court held that this extremely tight link between the use right and the
GPL would not prevent the software product from being marketed, as a
third party would be able at any time to re-acquire the rights from the
software developer. However, sects. 2 and 4 of the GPL do not refer to
the German concept of conditions. Sect. 4 refers to particular rights
“provided that”. Sect. 2 uses the term “conditions”, but in a very
broad and general sense, such as a contractual term which has to be
met. It might well be that a violation of the GPL leads to contractual
remedies for non-performance, but not to an automatic loss of use rights.

c. To operate with a condition subsequent is “beating the devil with
the devil”. If I were a producer of proprietary software products, I
would be very happy with the judgement of the district court because
nobody can prevent the producers of proprietary software from likewise
using a condition subsequent. They can now restrict the transfer of
sold software to third persons or the use of a programme on different
computers by combing these (invalid) contractual restrictions with a
condition subsequent related to the “license”. If you pass software to
anybody else or use it in another computer, you (and the third person)
automatically lose your right to use the software. Everything courts
had said on the (in-) validity of contractual use restrictions in the
software business is now going to be undermined by the model of the
condition subsequent.

d. Why does the GPL call itself a “license”? The term “license” is
not used in the German Copyright Act and is not known in Continental
European copyright law. That is good: the term “license” is nebulous
and has been used in business as a smokescreen to mask the invalidity
of “license” restrictions. In recent years the license model has been
efficiently refuted by European courts and traced back to traditional
concepts such as the purchase of rights or a legal lease. The district
court should have dealt with this opinio communis. But what happened
in Munich?

e. The ignorance of the Munich court as to the opinio communis can
also be demonstrated in connection with the problem of exhaustion. If
the GPL is regarded to be binding even in cases of the transfer of
software to a third person, the concept of exhaustion might be
violated. The European Software Directive has provided that the
exhaustion of the copy of a program is applied Community-wide by a
first sale of that copy in the Community with the consent of the right-
holder; once an author has sold a copy of a work, he or she loses the
exclusive distribution right with respect to that work. A contractual
limitation of this principle is held to be invalid, at least in
Germany and Austria. The Munich court obviously did not know of these
developments; instead it simply stated that the German copyright
legislator had once expressed its support for Open Source. However,
this support has been given only in other legislative debates
regarding mandatory rights of creators to adequate remuneration. But
even if the legislator generally likes Open Source, it does not at all
mean that the legislator supports and considers every rule of the GPL
as legally effective.

f. En passant, the Court raised some more radical questions without
giving good arguments. For instance, the Court claimed that a non-
exclusive license gives a right in rem; this contradicts the
interpretation of the Federal Supreme Court, which held that non-
exclusive use rights are not property rights but contractual rights
(BGH, GRUR 1959, 201, 202 – Heiligenhof). The court has not really
discussed rules relating to the conflict of laws. Of course, copyright
law is governed by the principle of territoriality. But what about the
relevant rules for contractual aspects, as with the interpretation of
the GPL (see above) or the applicability of regulations concerning
unfair contract terms?

g. Finally, there is the important question of the consequences of the
assumed invalidity of the GPL. The Munich court argued that the
question of the enforceability of the GPL was in no way relevant.
According to the Bavarian judges, if the GPL is legally ineffective,
the user does not have a license and is thus violating copyright law.
On the face of it, that sounds plausible, but it is not. If somebody
offers software on the Internet for downloading and links the download
with invalid general terms, he can hardly sue for copyright
infringement. Instead, the validity of the standard terms is a matter
for the software distributor: if he wants to use invalid contractual
terms, he bears the risk of their use. It would violate equity and
good faith if he were allowed to sue others merely on the grounds that
his license terms were invalid.

</quote>

regards,
alexander.

--
http://groups.google.com/groups?selm=41055C8A.3D4940B7%40web.de

Joe Seigh

unread,
Nov 23, 2004, 12:05:41 PM11/23/04
to

Alexander Terekhov wrote:
>
> Alexander Terekhov wrote:
> >
> > Joe Seigh wrote:
> > [...]
> > > Probably GPL just to annoy Alexander. :)
> >
> > Apart from Munich district (possible appeal in the Sitecom case
> > aside for a moment), the GPL is preempted by The First Sale (aka
> > "community exhaustion for the distribution right" in the EU).
>
> http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL3_20040903.pdf
> (The first-ever ruling on the legal validity of the GPL - A Critique
> of the Case By Professor Dr Thomas Hoeren, Visiting Fellow at the
> Oxford Internet Institute)
>
> <quote>

[...]
> </quote>
>

I'm not going to try to second guess European law. Though there does seem to
be some confusion between making a copy of something and transfering a copy of
something. My understanding of GPL is that it applies to the former. Even
if GLP is invalid, GPL'd software wouldn't fall into the public domain.

Anyway this is moot for me as I can't figure out how to put a international
copyright notice in an ascii text file. While US law allows the term "copyright"
or the copyright symbol, the letter c inside a circle, the internation convention
is to only allow the copyright symbol. IANAL, but as far as I know and from the
one time I was told by a lawyer, "(C)" is not the legal equivalent of the copyright
symbol. And if you don't have a valid copyright notice then I would think the attached
terms and conditions would be meaningless.

Joe Seigh

Alexander Terekhov

unread,
Nov 23, 2004, 12:28:37 PM11/23/04
to

Joe Seigh wrote:
[...]

> I'm not going to try to second guess European law. Though there does seem to
> be some confusion between making a copy of something and transfering a copy of
> something. My understanding of GPL is that it applies to the former.

http://groups.google.com/groups?selm=410E2979.B0055E86%40web.de

> Even
> if GLP is invalid, GPL'd software wouldn't fall into the public domain.

Except that in the US, the penalty for copyright misuse IS (quasi)
"public domain" (imposed copyright impotence, so to say).

>
> Anyway this is moot for me as I can't figure out how to put a international
> copyright notice in an ascii text file. While US law allows the term "copyright"
> or the copyright symbol, the letter c inside a circle, the internation convention
> is to only allow the copyright symbol. IANAL, but as far as I know and from the
> one time I was told by a lawyer, "(C)" is not the legal equivalent of the copyright
> symbol. And if you don't have a valid copyright notice then I would think the attached
> terms and conditions would be meaningless.

No symbols and/or notices needed. Even in the US. Your as-far-as-I-know
is outdated (I mean old UCC Article 3).

See <http://www.templetons.com/brad/copymyths.html>.

regards,
alexander.

Joe Seigh

unread,
Nov 23, 2004, 12:52:25 PM11/23/04
to

Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> [...]
> > I'm not going to try to second guess European law. Though there does seem to
> > be some confusion between making a copy of something and transfering a copy of
> > something. My understanding of GPL is that it applies to the former.
>
> http://groups.google.com/groups?selm=410E2979.B0055E86%40web.de

There's some confusion over the term distribution.


>
> > Even
> > if GLP is invalid, GPL'd software wouldn't fall into the public domain.
>
> Except that in the US, the penalty for copyright misuse IS (quasi)
> "public domain" (imposed copyright impotence, so to say).

No, where do you get that?


>
> >
> > Anyway this is moot for me as I can't figure out how to put a international
> > copyright notice in an ascii text file. While US law allows the term "copyright"
> > or the copyright symbol, the letter c inside a circle, the internation convention
> > is to only allow the copyright symbol. IANAL, but as far as I know and from the
> > one time I was told by a lawyer, "(C)" is not the legal equivalent of the copyright
> > symbol. And if you don't have a valid copyright notice then I would think the attached
> > terms and conditions would be meaningless.
>
> No symbols and/or notices needed. Even in the US. Your as-far-as-I-know
> is outdated (I mean old UCC Article 3).
>
> See <http://www.templetons.com/brad/copymyths.html>.
>


Having copyright and the copyright notice are two different things. See
http://www.copyright.gov/help/faq/ and
http://www.copyright.gov/circs/circ03.html

Joe Seigh

Alexander Terekhov

unread,
Nov 23, 2004, 1:46:07 PM11/23/04
to

Joe Seigh wrote:
[...]

> > http://groups.google.com/groups?selm=410E2979.B0055E86%40web.de
>
> There's some confusion over the term distribution.

Not in my head. ;-)

> >
> > > Even
> > > if GLP is invalid, GPL'd software wouldn't fall into the public domain.
> >
> > Except that in the US, the penalty for copyright misuse IS (quasi)
> > "public domain" (imposed copyright impotence, so to say).
>
> No, where do you get that?

Try digital-law-online. Well, {re-}try

http://groups.google.com/groups?selm=411B6473.E32A1721%40web.de

[...]


> Having copyright and the copyright notice are two different things. See

http://www.nationmaster.com/encyclopedia/Universal-Copyright-Convention
http://groups.google.com/groups?selm=18Z302bN43SM01%40JUTS.ccc.amdahl.com

regards,
alexander.

Reply all
Reply to author
Forward
0 new messages