[RFC 0/1] Contributing a compound object to the libpthread

[RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

Hi Carlos,

On Wed, Jan 13, 2016 at 5:55 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 01/06/2016 06:38 AM, Oleh Derevenko wrote:
> > Hi All,
> >
> > Sorry for a somewhat unusual question.
> >
> > I have a devised a compound synchronization object approximately of
> > the rwlock's level which helps with some aspects of data queue
> > handling and provider-consumer interactions between threads. One of
> > particular uses - it allows to wait for a worker to complete a
> > specific work item with priority inheritance from the waiting thread
> > (if the OS provides the priority inheritance feature at all, of
> > course). If I would like to contribute this object to the libpthread,
> > what would be the best way/place to do it?
>
> At present libpthread implements the POSIX Threads functions and some
> additional non-portable extenions. We don't deviate much from pthreads.
> If your new feature is quite different then it might not be a match for
> libpthread or glibc.
>
> You should start by making your code available perhaps in a distinct
> project or as a glibc add-on and discussing further once you have more
> concrete information to present. Consider carefully the license of your
> code and all things you'll need for a good contribution:
> https://sourceware.org/glibc/wiki/Contribution%20checklist
>
> I know it's quite a lot to review, but license and copyright assignment
> are the top two things to get out of the way if you're looking to
> contribute to the project at any level.
>
> We are also starting to discuss a non-pthread experimental library
> for exposing executaion agent interfaces to be used by higher level
> frameworks whose requirements don't directly map well onto POSIX
> threads. Your synchronization object might be suited to such an
> experimental library, but again it's hard to say without any more
> information.
>
> Cheers,
> Carlos.
>

Sorry for a kind of necroposting -- it has been quite long since I
started this topic.
So, having considered what I had, I decided to apply for a patent on
the synchronization technique I mentioned. After all, it's not every
day you come up with ideas like that.
Now the application has been published and is available at
http://appft.uspto.gov/netahtml/PTO/search-adv.html (use
“DN/20170329652” for the search) and thus I can present the related
implementation here, following in the next e-mail fragment. The
functions and the synchronization objects themselves were formatted in
the style and with naming conventions of libpthread (merely for sake
of convenience). There are descriptive commentaries in the code and a
few usage examples written as C pseudocode in a commentary at the end
of the header file.
I could provide these objects free for GPL licensed projects (and
probably for LGPL applications as well -- all, but libraries, to avoid
misuse within commercial sotware), if the public is interested in it.
I'm not generally following the discussions here but throwing a quick
glance now and then I saw people trying to get priority inheritance
with pthread_cond_wait(). My synchronization objects are a readily
available alternative. And though requiring somewhat advanced
synchronization skills and proper thread hierarchy design, they cover
all my needs for event waits requiring priority inheritance.

-- 

Oleh Derevenko
 -- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

Hi All,

Well guys, really! This is a cool thing!
With a mutex wheel a master thread can wait for a slave thread to
complete an operation (the slave thread "signals" after the
completion). And with yet an additional mutex, the slave thread can
know that the master thread has finished waiting for the signal (this
may be needed to make sure that the shared synchronization objects are
safe to be reused/deleted and that the threads do not reference each
other anymore). And all this — with full priority inheritance. This is
a kind of "provider-consumer" problem with event-like synchronization
objects (e.g. condvars) completely eliminated.

Oleh Derevenko
-- Skype with underscore


On Thu, Dec 14, 2017 at 1:35 AM, Oleh Derevenko
<oleh.derevenko@gmail.com> wrote:
> Hi Carlos,
>
> On Wed, Jan 13, 2016 at 5:55 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 01/06/2016 06:38 AM, Oleh Derevenko wrote:
>> > Hi All,
>> >
>> > Sorry for a somewhat unusual question.
>> >
>> > I have a devised a compound synchronization object approximately of
>> > the rwlock's level which helps with some aspects of data queue
>> > handling and provider-consumer interactions between threads. One of
>> > particular uses - it allows to wait for a worker to complete a
>> > specific work item with priority inheritance from the waiting thread
>> > (if the OS provides the priority inheritance feature at all, of
>> > course). If I would like to contribute this object to the libpthread,
>> > what would be the best way/place to do it?
>>
>> At present libpthread implements the POSIX Threads functions and some
>> additional non-portable extenions. We don't deviate much from pthreads.
>> If your new feature is quite different then it might not be a match for
>> libpthread or glibc.
>>
>> You should start by making your code available perhaps in a distinct
>> project or as a glibc add-on and discussing further once you have more
>> concrete information to present. Consider carefully the license of your
>> code and all things you'll need for a good contribution:
>> https://sourceware.org/glibc/wiki/Contribution%20checklist
>>
>> I know it's quite a lot to review, but license and copyright assignment
>> are the top two things to get out of the way if you're looking to
>> contribute to the project at any level.
>>
>> We are also starting to discuss a non-pthread experimental library
>> for exposing executaion agent interfaces to be used by higher level
>> frameworks whose requirements don't directly map well onto POSIX
>> threads. Your synchronization object might be suited to such an
>> experimental library, but again it's hard to say without any more
>> information.
>>
>> Cheers,
>> Carlos.
>>
>
> Sorry for a kind of necroposting -- it has been quite long since I
> started this topic.
> So, having considered what I had, I decided to apply for a patent on
> the synchronization technique I mentioned. After all, it's not every
> day you come up with ideas like that.
> Now the application has been published and is available at
> http://appft.uspto.gov/netahtml/PTO/search-adv.html (use
> “DN/20170329652” for the search) and thus I can present the related
> implementation here, following in the next e-mail fragment. The
> functions and the synchronization objects themselves were formatted in
> the style and with naming conventions of libpthread (merely for sake
> of convenience). There are descriptive commentaries in the code and a
> few usage examples written as C pseudocode in a commentary at the end
> of the header file.
> I could provide these objects free for GPL licensed projects (and
> probably for LGPL applications as well -- all, but libraries, to avoid
> misuse within commercial sotware), if the public is interested in it.
> I'm not generally following the discussions here but throwing a quick
> glance now and then I saw people trying to get priority inheritance
> with pthread_cond_wait(). My synchronization objects are a readily
> available alternative. And though requiring somewhat advanced
> synchronization skills and proper thread hierarchy design, they cover
> all my needs for event waits requiring priority inheritance.
>
> --
>
> Oleh Derevenko
>  -- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Ben Hutchings]

On Tue, 2018-04-03 at 02:07 +0300, Oleh Derevenko wrote:
> Hi All,
> 
> Well guys, really! This is a cool thing!
[...]

Maybe, but unless you are prepared to license your code and patent
under LGPL 2.1+ terms then there is no point in bringing it up here.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

Ben,

LGPL in this case is just the same as freeware. You simply create a
LGPL shared library, export functionality from it, and use it
absolutely for whatever you want.

Regarding the patent, I'm not sure it will be approved at all yet. Of
course, I'll do my best but there is some amount of bureaucracy one
has to overcome and there is no certainty who will win. I fully
realize that options available to me are very limited and I'm on mercy
of examiners.
In any case the patent is not for money. So far I have invested about
$700 into it and it is yet going to additionally cost at minimum about
$2500 for 20 years of patent validity period. If I'll be able to earn
that money back that'll already be a big achievement. :-)
All this is more to get a publication and to have a new life experience.

-- 
Oleh Derevenko

On Tue, Apr 3, 2018 at 4:41 PM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Tue, 2018-04-03 at 02:07 +0300, Oleh Derevenko wrote:
>> Hi All,
>>
>> Well guys, really! This is a cool thing!
> [...]
>
> Maybe, but unless you are prepared to license your code and patent
> under LGPL 2.1+ terms then there is no point in bringing it up here.
>
> Ben.
>
> --
> Ben Hutchings
> Software Developer, Codethink Ltd.
>

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

 Hi everyone,

Could it be that a project like libc does not have a group of people
eligible for making decisive judgements and saying "yes" or "no" on
behalf of it? Or do you need more time?

Believe me, would it be some junk I would not be pushing it here. I'm
42, I'm in software development since year 1995 and coding in C/C++ since
year 2000. I understand what kind of thing the C library is pretty well. In
my opinion there will be absolutely no harm to have some code people
would be free to include and redistribute while it is not used, or if
it is used in free software. And if they would want to make a
commercial product they will always have a choice to stay with
condvars or to pay a small premium to the author for using the
invention if they would see that benefitial for themselves. For
anything serious, benefits will greatly outweight those several cents
it will cost.

I could provide use examples with detailed explanations if you need
that. And I can also contribute to references/manuals.
I need a general decision: either "yes" or "no".

On Thu, May 31, 2018 at 1:10 AM, Oleh Derevenko
<oleh.derevenko@gmail.com> wrote:
> Hi everyone!
>
> So, as an update, the patent has been granted. I had to amend the
> claims as the initial ones in the application were not acceptable. You
> can view the final text from the search page
> (http://patft.uspto.gov/netahtml/PTO/search-adv.htm) having entered
> "PN/9983913" in the field there.
>
> My initial offer remains valid. I could release the thing for GPL. As
> for the rest, the idea is to license for something like 0.2% of
> product price; 0.01USD minimum; 1.00USD maximum; free for free
> software (including free exclusions of paid software for user
> groups/regions and similar free programs). I will work on exact
> wordings but this should describe the general approach and I believe
> it should be compatible with the principles you guys work by. If you
> find this acceptable I believe lots of software could benefit from the
> synchronization approach/objects I developed.
>
> The implementation sources were posted here on December 14th, 2017. I
> can re-send if they are not accessible for whatever reason anymore.
>
> Open for discussion and waiting for your commentaries.
>
-- 
Oleh Derevenko

-- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Florian Weimer]

On 06/15/2018 04:05 PM, Oleh Derevenko wrote:
> Could it be that a project like libc does not have a group of people
> eligible for making decisive judgements and saying "yes" or "no" on
> behalf of it? Or do you need more time?

You said you want to avoid “misuse within commercial so[f]tware”.  I 
don't see how you can do that while still contributing to glibc, so I 
didn't look at your proposal in detail.

Thanks,
Florian

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

 Hi Florian,

Would not it work if a warning and a license text would be put in the
header and in respective manual pages to declare and explain what are
the use conditions/restrictions? That would be a kind of offer the
public could accept and it would provide them legal grounds. Of
course, I will have little (if any) means to verify and control. But
this is more a honesty oriented approach and I guess I'll be fine with
that.

On Fri, Jun 15, 2018 at 5:30 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/15/2018 04:05 PM, Oleh Derevenko wrote:
>>
>> Could it be that a project like libc does not have a group of people
>> eligible for making decisive judgements and saying "yes" or "no" on
>> behalf of it? Or do you need more time?
>
>
> You said you want to avoid “misuse within commercial so[f]tware”.  I don't
> see how you can do that while still contributing to glibc, so I didn't look
> at your proposal in detail.
>
> Thanks,
> Florian



-- 
Oleh Derevenko

-- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Adhemerval Zanella]

As Ben Hutchings has noted, new code additions are expected to have be
licensed with LGPL 2.1+ following the default FSF copyright assignment
(as Carlos has noted in previously message). You seemed to not be in 
accord on such criteria, so I think we won't be able to take your 
contribution.


On 16/06/2018 15:37, Oleh Derevenko wrote:
>  Hi Florian,
> 
> Would not it work if a warning and a license text would be put in the
> header and in respective manual pages to declare and explain what are
> the use conditions/restrictions? That would be a kind of offer the
> public could accept and it would provide them legal grounds. Of
> course, I will have little (if any) means to verify and control. But
> this is more a honesty oriented approach and I guess I'll be fine with
> that.
> 
> On Fri, Jun 15, 2018 at 5:30 PM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 06/15/2018 04:05 PM, Oleh Derevenko wrote:
>>>
>>> Could it be that a project like libc does not have a group of people
>>> eligible for making decisive judgements and saying "yes" or "no" on
>>> behalf of it? Or do you need more time?
>>
>>
>> You said you want to avoid “misuse within commercial so[f]tware”.  I don't
>> see how you can do that while still contributing to glibc, so I didn't look
>> at your proposal in detail.
>>
>> Thanks,
>> Florian
> 
> 
> 

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

Hi Adhemerval,

Just out of curiosity, may I ask why? Just to blindly obey the rules?
My code is not going to conflict with general LGPL license. It is a
client level only feature which is not needed unless you have
server/worker threads. The library itself will not depend on it. From
library's perspective that'll be a kind of dead code inclusion.
It's only when user decides to use (invoke) the code - that'll be
his/her deliberate decision and his/her deliberate obligation in
addition to LGPL.

After all, I would judge based on the feature's benefits or lack of those first.


On Mon, Jun 18, 2018 at 4:22 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> As Ben Hutchings has noted, new code additions are expected to have be
> licensed with LGPL 2.1+ following the default FSF copyright assignment
> (as Carlos has noted in previously message). You seemed to not be in
> accord on such criteria, so I think we won't be able to take your
> contribution.
>
>
> On 16/06/2018 15:37, Oleh Derevenko wrote:
>>  Hi Florian,
>>
>> Would not it work if a warning and a license text would be put in the
>> header and in respective manual pages to declare and explain what are
>> the use conditions/restrictions? That would be a kind of offer the
>> public could accept and it would provide them legal grounds. Of
>> course, I will have little (if any) means to verify and control. But
>> this is more a honesty oriented approach and I guess I'll be fine with
>> that.
>>
>> On Fri, Jun 15, 2018 at 5:30 PM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 06/15/2018 04:05 PM, Oleh Derevenko wrote:
>>>>
>>>> Could it be that a project like libc does not have a group of people
>>>> eligible for making decisive judgements and saying "yes" or "no" on
>>>> behalf of it? Or do you need more time?
>>>
>>>
>>> You said you want to avoid “misuse within commercial so[f]tware”.  I don't
>>> see how you can do that while still contributing to glibc, so I didn't look
>>> at your proposal in detail.
>>>
>>> Thanks,
>>> Florian
>>
>>
>>



-- 
Oleh Derevenko

-- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Adhemerval Zanella]

My understanding is GLIBC is a GNU project and it should follow the
guideline for GNU projects [1]. It is an issue, both practically and
philosophically [2], if we add incompatible code regarding licensing
in GNU project.

And although it was not clear to me exactly how you do intend to make
your suggestion available, previous messages hints me that you want 
something like this [3]. So what exactly is preventing you do distribute
your patch in a GPL-compatible way? If your strong unwilling to do so,
one option would be to just create an external library with your
preferred license.

[1] https://www.gnu.org/licenses/license-list.html
[2] https://www.gnu.org/philosophy/philosophy.html
[3] https://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowRequireFee

On 18/06/2018 16:52, Oleh Derevenko wrote:
> Hi Adhemerval,
> 
> Just out of curiosity, may I ask why? Just to blindly obey the rules?
> My code is not going to conflict with general LGPL license. It is a
> client level only feature which is not needed unless you have
> server/worker threads. The library itself will not depend on it. From
> library's perspective that'll be a kind of dead code inclusion.
> It's only when user decides to use (invoke) the code - that'll be
> his/her deliberate decision and his/her deliberate obligation in
> addition to LGPL.
> 
> After all, I would judge based on the feature's benefits or lack of those first.
> 
> 
> On Mon, Jun 18, 2018 at 4:22 PM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> As Ben Hutchings has noted, new code additions are expected to have be
>> licensed with LGPL 2.1+ following the default FSF copyright assignment
>> (as Carlos has noted in previously message). You seemed to not be in
>> accord on such criteria, so I think we won't be able to take your
>> contribution.
>>
>>
>> On 16/06/2018 15:37, Oleh Derevenko wrote:
>>>  Hi Florian,
>>>
>>> Would not it work if a warning and a license text would be put in the
>>> header and in respective manual pages to declare and explain what are
>>> the use conditions/restrictions? That would be a kind of offer the
>>> public could accept and it would provide them legal grounds. Of
>>> course, I will have little (if any) means to verify and control. But
>>> this is more a honesty oriented approach and I guess I'll be fine with
>>> that.
>>>
>>> On Fri, Jun 15, 2018 at 5:30 PM, Florian Weimer <fweimer@redhat.com> wrote:
>>>> On 06/15/2018 04:05 PM, Oleh Derevenko wrote:
>>>>>
>>>>> Could it be that a project like libc does not have a group of people
>>>>> eligible for making decisive judgements and saying "yes" or "no" on
>>>>> behalf of it? Or do you need more time?
>>>>
>>>>
>>>> You said you want to avoid “misuse within commercial so[f]tware”.  I don't
>>>> see how you can do that while still contributing to glibc, so I didn't look
>>>> at your proposal in detail.
>>>>
>>>> Thanks,
>>>> Florian
>>>
>>>
>>>
> 
> 
> 

Re: [RFC 0/1] Contributing a compound object to the libpthread

[DJ Delorie]

Adding my not-a-lawyer two cents...

Oleh Derevenko <oleh.derevenko@gmail.com> writes:
> Just out of curiosity, may I ask why? Just to blindly obey the rules?

Consider that the GNU C Library is... GNU.  It's owned by the FSF, and
they make the rules when it comes to legalities, and they have lawyers
that have done all the hard work for us too.  And the project has to
have a consistent license to avoid ambiguity.  And the LGPL guarantees
freedoms that other licenses might not.

But in general, yes, we obey the rules as laid out by the copyright
holder.

> After all, I would judge based on the feature's benefits or lack of
> those first.

Unfortunately, because of the copyright and patent issues, we really
can't even *look* at your code yet.  If we did look at your code, and
your license ended up not changing, we would be unable to be fair about
writing similar code in the future and cleanly licensing it with a
different license.  Anyone who read your code would be "tainted".

I admit this makes "just writing code" a bit more difficult and
cumbersome, but that's what we have to do to protect our investments in
our own code in today's legal environment.

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

 Allright gentlemen,

I see your concerns and I accept that.
Just two notes I would like to add.

Regarding the links Adhemerval included -- those are the rules of GPL,
not the LGPL license. I did initially mention I have no problems
distrbuting free with GPL license. I was only speaking for custom
licensing in paid software which cannot be GPL.

Regarding the note of DJ Delorie -- the patent covers the
synchronization method (the approach), not a particular
implementation. You will not be able to create an implementation of
yours without violating the patent anyway. So, don't worry about the
effects of looking in the code.

That said, I understand that my idea is not going to be accepted at
this time. I would like to apoligize for you time I have taken. In
case anyone is going to change their opinions on the matter feel free
to contact me.


On Tue, Jun 19, 2018 at 12:06 AM, DJ Delorie <dj@redhat.com> wrote:
>
> Adding my not-a-lawyer two cents...
>
> Oleh Derevenko <oleh.derevenko@gmail.com> writes:
>> Just out of curiosity, may I ask why? Just to blindly obey the rules?
>
> Consider that the GNU C Library is... GNU.  It's owned by the FSF, and
> they make the rules when it comes to legalities, and they have lawyers
> that have done all the hard work for us too.  And the project has to
> have a consistent license to avoid ambiguity.  And the LGPL guarantees
> freedoms that other licenses might not.
>
> But in general, yes, we obey the rules as laid out by the copyright
> holder.
>
>> After all, I would judge based on the feature's benefits or lack of
>> those first.
>
> Unfortunately, because of the copyright and patent issues, we really
> can't even *look* at your code yet.  If we did look at your code, and
> your license ended up not changing, we would be unable to be fair about
> writing similar code in the future and cleanly licensing it with a
> different license.  Anyone who read your code would be "tainted".
>
> I admit this makes "just writing code" a bit more difficult and
> cumbersome, but that's what we have to do to protect our investments in
> our own code in today's legal environment.



-- 
Oleh Derevenko

-- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Adhemerval Zanella]

On 18/06/2018 19:26, Oleh Derevenko wrote:
>  Allright gentlemen,
> 
> I see your concerns and I accept that.
> Just two notes I would like to add.
> 
> Regarding the links Adhemerval included -- those are the rules of GPL,
> not the LGPL license. I did initially mention I have no problems
> distrbuting free with GPL license. I was only speaking for custom
> licensing in paid software which cannot be GPL.

Afaik the rules I linked are also valid for LGPL (specially the fee one
you seemed to suggest to use).

> 
> Regarding the note of DJ Delorie -- the patent covers the
> synchronization method (the approach), not a particular
> implementation. You will not be able to create an implementation of
> yours without violating the patent anyway. So, don't worry about the
> effects of looking in the code.
> 
> That said, I understand that my idea is not going to be accepted at
> this time. I would like to apoligize for you time I have taken. In
> case anyone is going to change their opinions on the matter feel free
> to contact me.

To be clear: it is not your idea that is being rejected, but rather 
your imposing rules we need to accept so you can disclosure your idea.

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

Adhemerval,


On Tue, Jun 19, 2018 at 3:07 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:

>> Regarding the note of DJ Delorie -- the patent covers the
>> synchronization method (the approach), not a particular
>> implementation. You will not be able to create an implementation of
>> yours without violating the patent anyway. So, don't worry about the
>> effects of looking in the code.
>>
>> That said, I understand that my idea is not going to be accepted at
>> this time. I would like to apoligize for you time I have taken. In
>> case anyone is going to change their opinions on the matter feel free
>> to contact me.
>
> To be clear: it is not your idea that is being rejected, but rather
> your imposing rules we need to accept so you can disclosure your idea.

All the patent texts (except for those that contain sectecy matter)
are publicly available from the USPTO or similar corresponding
national/international patent management offices. In particular, there
is a search form at the USPTO website you can use to view any present
or past patents and published applications. The sole idea of patents
is to create and save descriptions any other skilled individuals can
later use to re-create the inventions. Just, an exclusive use period
is granted to authors as a reward for their binging the inventions to
public. Later, after patents expire, they can (and should) be used to
advance everyday life of all the humanity (or other more humble
purposes -- whatever they are good for). In my opinion, most of the
patents in the database are good for nothing and are just wasted
money. Or they can be treated as enforced losses businesses have to
take due to the competitive environment they exist in. But sometimes
there are things that are worth the application/maintenance fees paid.

So to resume, there is no problem in disclosing the idea. And it
already was disclosed here and is permanently being disclosed at the
USPTO website. I posted a link to it.

-- 
Oleh Derevenko
-- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Adhemerval Zanella]

On 19/06/2018 09:42, Oleh Derevenko wrote:
> Adhemerval,
> 
> 
> On Tue, Jun 19, 2018 at 3:07 PM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
> 
>>> Regarding the note of DJ Delorie -- the patent covers the
>>> synchronization method (the approach), not a particular
>>> implementation. You will not be able to create an implementation of
>>> yours without violating the patent anyway. So, don't worry about the
>>> effects of looking in the code.
>>>
>>> That said, I understand that my idea is not going to be accepted at
>>> this time. I would like to apoligize for you time I have taken. In
>>> case anyone is going to change their opinions on the matter feel free
>>> to contact me.
>>
>> To be clear: it is not your idea that is being rejected, but rather
>> your imposing rules we need to accept so you can disclosure your idea.
> 
> All the patent texts (except for those that contain sectecy matter)
> are publicly available from the USPTO or similar corresponding
> national/international patent management offices. In particular, there
> is a search form at the USPTO website you can use to view any present
> or past patents and published applications. The sole idea of patents
> is to create and save descriptions any other skilled individuals can
> later use to re-create the inventions. Just, an exclusive use period
> is granted to authors as a reward for their binging the inventions to
> public. Later, after patents expire, they can (and should) be used to
> advance everyday life of all the humanity (or other more humble
> purposes -- whatever they are good for). In my opinion, most of the
> patents in the database are good for nothing and are just wasted
> money. Or they can be treated as enforced losses businesses have to
> take due to the competitive environment they exist in. But sometimes
> there are things that are worth the application/maintenance fees paid.
> 
> So to resume, there is no problem in disclosing the idea. And it
> already was disclosed here and is permanently being disclosed at the
> USPTO website. I posted a link to it.
> 

I am far from Copyright and patent expert and correct if I am wrong,
but my understanding is for GNU projects all your description does not
mean anything if you, the one holding the patent, do not sign a 
Copyright assignment for FSF so any projects which the idea or code
derived from it are protected for Copyright enforcements by third 
parties (you inclusive).

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Patrick McGehearty]

On 6/19/2018 8:09 AM, Adhemerval Zanella wrote:
>
> On 19/06/2018 09:42, Oleh Derevenko wrote:
>> Adhemerval,
>>
>>
>> On Tue, Jun 19, 2018 at 3:07 PM, Adhemerval Zanella
>> <adhemerval.zanella@linaro.org> wrote:
>>
>>>> Regarding the note of DJ Delorie -- the patent covers the
>>>> synchronization method (the approach), not a particular
>>>> implementation. You will not be able to create an implementation of
>>>> yours without violating the patent anyway. So, don't worry about the
>>>> effects of looking in the code.
>>>>
>>>> That said, I understand that my idea is not going to be accepted at
>>>> this time. I would like to apoligize for you time I have taken. In
>>>> case anyone is going to change their opinions on the matter feel free
>>>> to contact me.
>>> To be clear: it is not your idea that is being rejected, but rather
>>> your imposing rules we need to accept so you can disclosure your idea.
>> All the patent texts (except for those that contain sectecy matter)
>> are publicly available from the USPTO or similar corresponding
>> national/international patent management offices. In particular, there
>> is a search form at the USPTO website you can use to view any present
>> or past patents and published applications. The sole idea of patents
>> is to create and save descriptions any other skilled individuals can
>> later use to re-create the inventions. Just, an exclusive use period
>> is granted to authors as a reward for their binging the inventions to
>> public. Later, after patents expire, they can (and should) be used to
>> advance everyday life of all the humanity (or other more humble
>> purposes -- whatever they are good for). In my opinion, most of the
>> patents in the database are good for nothing and are just wasted
>> money. Or they can be treated as enforced losses businesses have to
>> take due to the competitive environment they exist in. But sometimes
>> there are things that are worth the application/maintenance fees paid.
>>
>> So to resume, there is no problem in disclosing the idea. And it
>> already was disclosed here and is permanently being disclosed at the
>> USPTO website. I posted a link to it.
>>
> I am far from Copyright and patent expert and correct if I am wrong,
> but my understanding is for GNU projects all your description does not
> mean anything if you, the one holding the patent, do not sign a
> Copyright assignment for FSF so any projects which the idea or code
> derived from it are protected for Copyright enforcements by third
> parties (you inclusive).

I also am not a Copyright or Patent expert, but I can share
what corporate lawyers for multiple large companies tell engineers:

"Don't look at or search patent applications without direct
instructions from higher management."

It's due to the concept of "willful infringement". If it can
be shown that your company has "willfully infringed", any court
finding of patent infringement will result in "enhanced damages".
If I do a patent search that happens to include a patent which
some other engineer at my company coincidentally infringes
while producing a high value product, the patent holder might
claim my company willfully infringed, even if I never spoke
to the other engineer. It is difficult to prove the negative.
Given that some high profile patent cases have resulted in billion
dollar judgements, you can see the potential seriousness.
Willful violation of company policy that has such high
consequence is usually grounds for dismissal.

For me and most responsible engineers working large companies,
it means:  "I don't look at patent applications for fear of the
possible effect on future lawsuits."  Sad, but true.

- Patrick McGehearty

Re: [RFC 0/1] Contributing a compound object to the libpthread

[DJ Delorie]

The usual IANAL disclaimer applies :-)

Oleh Derevenko <oleh.derevenko@gmail.com> writes:
> All the patent texts (except for those that contain sectecy matter)
> are publicly available from the USPTO or similar corresponding
> national/international patent management offices.

As Adhemerval noted, it's not the idea we're running into issues with,
it's the legal framework under which we are allowed to learn about the
idea.  Welcome to the US legal system, it's a mess, but it's what we've
got to work with.

For starters, I'll point out that you, as a patent owner, are legally
allowed to sue anyone who re-creates your invention without your
permission.  I know this isn't your intent, but bear with me a moment,
as I'm describing a worst-case scenario.  So, you're allowed to sue.
Maybe they're using your invention to torture babies.  Maybe they're a
competitor.  Maybe you don't like the color of their logo.  It doesn't
matter, you're *allowed* to sue.

Worse, the US legal system will grant you triple damages if you can show
that the re-creation was done *knowing* you have a patent on it.
Because of this, it's in our best *legal* interests to not even look at
patents because of the added risk.

But, you say, you *want* people to use your inventions.  That's
wonderful, and we appreciate that, but unfortunately you have to say
that *legally* before we can act on it, and that means paperwork.

Likewise for copyright stuff.  We're happy you want to contribute, but
if you want to give us code to use, you have to give it to us legally so
we can protect ourselves against future legal problems.  We also use
this legal "muscle" to protect our code (and code you've contributed)
from being mis-used by "bad actors".  There have been instances in the
past where huge chunks of code had to be pulled out of non-GNU packages
because of copyright issues.  The FSF avoids this by legally owning the
code via copyright assignments.

So we ask for patent licenses and copyright assignments.  Because of our
legal system, this has to be a hard requirement, and there's little we
can do about it.

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Zack Weinberg]

On Tue, Jun 19, 2018 at 12:28 PM, DJ Delorie <dj@redhat.com> wrote:
> Oleh Derevenko <oleh.derevenko@gmail.com> writes:
>> All the patent texts (except for those that contain sectecy matter)
>> are publicly available from the USPTO or similar corresponding
>> national/international patent management offices.
>
> As Adhemerval noted, it's not the idea we're running into issues with,
> it's the legal framework under which we are allowed to learn about the
> idea.  Welcome to the US legal system, it's a mess, but it's what we've
> got to work with.
[...]

All that you say is true, but also there _is_ a problem with the idea
of adding a novel "compound" synchronization object to libpthread.
Once we add stuff to the GNU C Library, we can never take it out
again, so we actually try _not_ to add things, most of the time.  We
even drag our feet on adding stuff that we know people want!  This
invention of Oleh's, we don't know yet if anyone wants it.

Oleh, because of the legal headaches discussed upthread, I have not
looked at your code at all, so I don't know if it's practical to
distribute this invention of yours as an independent library.  If you
can do that, you should.  This will allow you to work directly and
rapidly with people who are interested in using it to solve problems.
After something like a decade - yes, ten years or more - of experience
with people using it in real applications, _then_ you could come back
and talk to us about boosting it into the C library and probably also
into POSIX.

The only reason not to go this route is if there is some concrete
reason why you _have_ to hook into the internals of libpthread, and in
that case the conversation we should be having is about why that's
necessary and how it could be avoided.

zw

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Joseph Myers]

On Tue, 19 Jun 2018, DJ Delorie wrote:

> So we ask for patent licenses and copyright assignments.  Because of our

And specifically, what I think is the current assignment 
(/gd/gnuorg/copyright/assign.future on fencepost) says:

  6. Developer hereby agrees that if he has or acquires hereafter any
  proprietary interest (including, without limitation, any patent or
  copyright interest) dominating the Works, the Program, the Program as
  enhanced by the Works, or other enhancements to the Program, or the
  use of any of those, such dominating interest will not be used to
  undermine the effect of this assignment, i.e. the Foundation and the
  general public will be licensed to use, in that program or programs
  and their derivative works, without royalty or limitation, the subject
  matter of the dominating interest.  This license provision will be
  binding on the assignees of, or other successors to, the dominating
  interest, as well as on Developer.  This license grant is
  nonexclusive, royalty-free and non-cancellable.

Note that users of glibc may use glibc facilities in proprietary programs 
if they follow the provisions of the LGPL (typically through dynamically 
linking to glibc).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC 0/1] Contributing a compound object to the libpthread

[DJ Delorie]

Joseph Myers <joseph@codesourcery.com> writes:
> And specifically, what I think is the current assignment 
> (/gd/gnuorg/copyright/assign.future on fencepost) says:

Heh, I was trying to avoid scaring anyone off with *actual* legalese,
but yeah, there are details which IMHO are best left to a lawyer.  If
Oleh has a patent, he probably has a lawyer too.

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Oleh Derevenko]

 Gentlemen,

Thank you for all your suggestions and explanations.
Generally, I understand what you say and I basically knew that. You
explain the standard approach and why it has happened that it is here.
Alas, as I already initially mentioned, for me accepting the standard
approach would be simply resigning everything and staying with fame
only.
Well, I don't have fame either yet.
Now I don't even know why could I think such a huge machine would
adapt for a single person. I wanted to be with the library, but not a
part of the library.
I understand this might look like a parasitic approach, but still... I
supposed there would be something I would be giving back to the
library as well.

I guess, I'll be thinking towards what Adhemerval Zanella and Zack
Weinberg suggested: distributing own library. Thank you, gentlemen,
for that — it might be really a thing I needed to be doing anyway, an
unavoidable step.
May I come here with an announcement when it will be ready?




On Tue, Jun 19, 2018 at 10:55 PM, DJ Delorie <dj@redhat.com> wrote:
> Joseph Myers <joseph@codesourcery.com> writes:
>> And specifically, what I think is the current assignment
>> (/gd/gnuorg/copyright/assign.future on fencepost) says:
>
> Heh, I was trying to avoid scaring anyone off with *actual* legalese,
> but yeah, there are details which IMHO are best left to a lawyer.  If
> Oleh has a patent, he probably has a lawyer too.



-- 
Oleh Derevenko

-- Skype with underscore

Re: [RFC 0/1] Contributing a compound object to the libpthread

[Carlos O'Donell]

On 06/19/2018 06:39 PM, Oleh Derevenko wrote:
> May I come here with an announcement when it will be ready?

Absolutely. Please feel free to post to libc-alpha when you release
your project. Particularly since it may be of interest to other glibc
developers.

As always, each developer has to make their own decision to read the
code you make available given the license, and the consequences of
reading that code (as several point out).

Cheers,
Carlos.