* [RFC 0/1] Contributing a compound object to the libpthread
@ 2017-12-13 23:35 Oleh Derevenko
2018-04-02 23:07 ` Oleh Derevenko
0 siblings, 1 reply; 22+ messages in thread
From: Oleh Derevenko @ 2017-12-13 23:35 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2017-12-13 23:35 [RFC 0/1] Contributing a compound object to the libpthread Oleh Derevenko @ 2018-04-02 23:07 ` Oleh Derevenko 2018-04-03 13:41 ` Ben Hutchings 0 siblings, 1 reply; 22+ messages in thread From: Oleh Derevenko @ 2018-04-02 23:07 UTC (permalink / raw) To: Carlos O'Donell; +Cc: libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-04-02 23:07 ` Oleh Derevenko @ 2018-04-03 13:41 ` Ben Hutchings 2018-04-03 20:06 ` Oleh Derevenko 0 siblings, 1 reply; 22+ messages in thread From: Ben Hutchings @ 2018-04-03 13:41 UTC (permalink / raw) To: Oleh Derevenko, Carlos O'Donell; +Cc: libc-alpha 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-04-03 13:41 ` Ben Hutchings @ 2018-04-03 20:06 ` Oleh Derevenko [not found] ` <CAC1wWD0OwFLqUD2uXnavBzfEw=HCRn3fGW54zYfxRozxp8HsyA@mail.gmail.com> 0 siblings, 1 reply; 22+ messages in thread From: Oleh Derevenko @ 2018-04-03 20:06 UTC (permalink / raw) To: Ben Hutchings; +Cc: Carlos O'Donell, libc-alpha 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. > ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <CAC1wWD0OwFLqUD2uXnavBzfEw=HCRn3fGW54zYfxRozxp8HsyA@mail.gmail.com>]
* Re: [RFC 0/1] Contributing a compound object to the libpthread [not found] ` <CAC1wWD0OwFLqUD2uXnavBzfEw=HCRn3fGW54zYfxRozxp8HsyA@mail.gmail.com> @ 2018-06-15 14:05 ` Oleh Derevenko 2018-06-15 14:31 ` Florian Weimer 0 siblings, 1 reply; 22+ messages in thread From: Oleh Derevenko @ 2018-06-15 14:05 UTC (permalink / raw) To: libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-15 14:05 ` Oleh Derevenko @ 2018-06-15 14:31 ` Florian Weimer 2018-06-16 18:37 ` Oleh Derevenko 0 siblings, 1 reply; 22+ messages in thread From: Florian Weimer @ 2018-06-15 14:31 UTC (permalink / raw) To: Oleh Derevenko, libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-15 14:31 ` Florian Weimer @ 2018-06-16 18:37 ` Oleh Derevenko 2018-06-18 13:22 ` Adhemerval Zanella 0 siblings, 1 reply; 22+ messages in thread From: Oleh Derevenko @ 2018-06-16 18:37 UTC (permalink / raw) To: Florian Weimer; +Cc: libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-16 18:37 ` Oleh Derevenko @ 2018-06-18 13:22 ` Adhemerval Zanella 2018-06-18 19:52 ` Oleh Derevenko 0 siblings, 1 reply; 22+ messages in thread From: Adhemerval Zanella @ 2018-06-18 13:22 UTC (permalink / raw) To: libc-alpha 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 > > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-18 13:22 ` Adhemerval Zanella @ 2018-06-18 19:52 ` Oleh Derevenko 2018-06-18 21:03 ` Adhemerval Zanella 2018-06-18 21:06 ` DJ Delorie 0 siblings, 2 replies; 22+ messages in thread From: Oleh Derevenko @ 2018-06-18 19:52 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-18 19:52 ` Oleh Derevenko @ 2018-06-18 21:03 ` Adhemerval Zanella 2018-06-18 21:06 ` DJ Delorie 1 sibling, 0 replies; 22+ messages in thread From: Adhemerval Zanella @ 2018-06-18 21:03 UTC (permalink / raw) To: Oleh Derevenko; +Cc: libc-alpha 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 >>> >>> >>> > > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-18 19:52 ` Oleh Derevenko 2018-06-18 21:03 ` Adhemerval Zanella @ 2018-06-18 21:06 ` DJ Delorie 2018-06-18 22:26 ` Oleh Derevenko 1 sibling, 1 reply; 22+ messages in thread From: DJ Delorie @ 2018-06-18 21:06 UTC (permalink / raw) To: Oleh Derevenko; +Cc: libc-alpha 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-18 21:06 ` DJ Delorie @ 2018-06-18 22:26 ` Oleh Derevenko 2018-06-19 12:07 ` Adhemerval Zanella 0 siblings, 1 reply; 22+ messages in thread From: Oleh Derevenko @ 2018-06-18 22:26 UTC (permalink / raw) To: DJ Delorie, Adhemerval Zanella; +Cc: libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-18 22:26 ` Oleh Derevenko @ 2018-06-19 12:07 ` Adhemerval Zanella 2018-06-19 12:42 ` Oleh Derevenko 0 siblings, 1 reply; 22+ messages in thread From: Adhemerval Zanella @ 2018-06-19 12:07 UTC (permalink / raw) To: Oleh Derevenko, DJ Delorie; +Cc: libc-alpha 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 12:07 ` Adhemerval Zanella @ 2018-06-19 12:42 ` Oleh Derevenko 2018-06-19 13:09 ` Adhemerval Zanella 2018-06-19 16:28 ` DJ Delorie 0 siblings, 2 replies; 22+ messages in thread From: Oleh Derevenko @ 2018-06-19 12:42 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: DJ Delorie, libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 12:42 ` Oleh Derevenko @ 2018-06-19 13:09 ` Adhemerval Zanella 2018-06-19 15:36 ` Patrick McGehearty 2018-06-19 16:28 ` DJ Delorie 1 sibling, 1 reply; 22+ messages in thread From: Adhemerval Zanella @ 2018-06-19 13:09 UTC (permalink / raw) To: Oleh Derevenko; +Cc: DJ Delorie, libc-alpha 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). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 13:09 ` Adhemerval Zanella @ 2018-06-19 15:36 ` Patrick McGehearty 0 siblings, 0 replies; 22+ messages in thread From: Patrick McGehearty @ 2018-06-19 15:36 UTC (permalink / raw) To: libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 12:42 ` Oleh Derevenko 2018-06-19 13:09 ` Adhemerval Zanella @ 2018-06-19 16:28 ` DJ Delorie 2018-06-19 16:52 ` Zack Weinberg 2018-06-19 19:26 ` Joseph Myers 1 sibling, 2 replies; 22+ messages in thread From: DJ Delorie @ 2018-06-19 16:28 UTC (permalink / raw) To: Oleh Derevenko; +Cc: adhemerval.zanella, libc-alpha 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 16:28 ` DJ Delorie @ 2018-06-19 16:52 ` Zack Weinberg 2018-06-19 19:26 ` Joseph Myers 1 sibling, 0 replies; 22+ messages in thread From: Zack Weinberg @ 2018-06-19 16:52 UTC (permalink / raw) To: DJ Delorie; +Cc: Oleh Derevenko, Adhemerval Zanella, GNU C Library 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 16:28 ` DJ Delorie 2018-06-19 16:52 ` Zack Weinberg @ 2018-06-19 19:26 ` Joseph Myers 2018-06-19 19:55 ` DJ Delorie 1 sibling, 1 reply; 22+ messages in thread From: Joseph Myers @ 2018-06-19 19:26 UTC (permalink / raw) To: DJ Delorie; +Cc: Oleh Derevenko, adhemerval.zanella, libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 19:26 ` Joseph Myers @ 2018-06-19 19:55 ` DJ Delorie 2018-06-19 22:39 ` Oleh Derevenko 0 siblings, 1 reply; 22+ messages in thread From: DJ Delorie @ 2018-06-19 19:55 UTC (permalink / raw) To: Joseph Myers; +Cc: libc-alpha 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 19:55 ` DJ Delorie @ 2018-06-19 22:39 ` Oleh Derevenko 2018-06-20 13:14 ` Carlos O'Donell 0 siblings, 1 reply; 22+ messages in thread From: Oleh Derevenko @ 2018-06-19 22:39 UTC (permalink / raw) To: DJ Delorie; +Cc: Joseph Myers, libc-alpha 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC 0/1] Contributing a compound object to the libpthread 2018-06-19 22:39 ` Oleh Derevenko @ 2018-06-20 13:14 ` Carlos O'Donell 0 siblings, 0 replies; 22+ messages in thread From: Carlos O'Donell @ 2018-06-20 13:14 UTC (permalink / raw) To: Oleh Derevenko, DJ Delorie; +Cc: Joseph Myers, libc-alpha 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-06-20 13:14 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-13 23:35 [RFC 0/1] Contributing a compound object to the libpthread Oleh Derevenko 2018-04-02 23:07 ` Oleh Derevenko 2018-04-03 13:41 ` Ben Hutchings 2018-04-03 20:06 ` Oleh Derevenko [not found] ` <CAC1wWD0OwFLqUD2uXnavBzfEw=HCRn3fGW54zYfxRozxp8HsyA@mail.gmail.com> 2018-06-15 14:05 ` Oleh Derevenko 2018-06-15 14:31 ` Florian Weimer 2018-06-16 18:37 ` Oleh Derevenko 2018-06-18 13:22 ` Adhemerval Zanella 2018-06-18 19:52 ` Oleh Derevenko 2018-06-18 21:03 ` Adhemerval Zanella 2018-06-18 21:06 ` DJ Delorie 2018-06-18 22:26 ` Oleh Derevenko 2018-06-19 12:07 ` Adhemerval Zanella 2018-06-19 12:42 ` Oleh Derevenko 2018-06-19 13:09 ` Adhemerval Zanella 2018-06-19 15:36 ` Patrick McGehearty 2018-06-19 16:28 ` DJ Delorie 2018-06-19 16:52 ` Zack Weinberg 2018-06-19 19:26 ` Joseph Myers 2018-06-19 19:55 ` DJ Delorie 2018-06-19 22:39 ` Oleh Derevenko 2018-06-20 13:14 ` Carlos O'Donell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).