Date: Sun, 11 Dec 2016 23:16:09 +0100 From: Tijl Coosemans <tijl@FreeBSD.org> To: "Steven R. Loomis" <srl@icu-project.org> Cc: office@freebsd.org Subject: Re: ICU port? Message-ID: <20161211231609.1e352e65@kalimero.tijl.coosemans.org> In-Reply-To: <2A4B7B3F-3FEE-4E2D-99A7-FB23C15C4765@icu-project.org> References: <F4E3A872-A8CA-450C-BA0C-201C9C66B58F@icu-project.org> <20161210160419.79ade1e2@kalimero.tijl.coosemans.org> <2A4B7B3F-3FEE-4E2D-99A7-FB23C15C4765@icu-project.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Dec 2016 23:23:05 -0800 "Steven R. Loomis" <srl@icu-project.org>= wrote: > El 12/10/16 7:04 AM, "Tijl Coosemans" <tijl@freebsd.org> escribi=C3=B3: >> On Fri, 09 Dec 2016 15:44:47 -0800 "Steven R. Loomis" <srl@icu-project.o= rg> wrote: >>> I came across this address (though it seems to be a generic one) >>> on http://portsmon.freebsd.org/portoverview.py?category=3Ddevel&portnam= e=3Dicu >>> and https://svnweb.freebsd.org/ports/head/devel/icu/ >>>=20 >>> I work on ICU. 58.2 is shipping today (hopefully). >>>=20 >>> It seems there are a bunch of patches in >>> https://svnweb.freebsd.org/ports/head/devel/icu/files/ >>>=20 >>> It would be great to get these pushed upstream to ICU. >>>=20 >>> Any way we can try to do that? >>> ICU=E2=80=99s CLA is at https://ssl.icu-project.org/trac/wiki/IcuDownst= reams#cla >>> for accepting patches. >> >> Feel free to commit them. >=20 > Could you consider signing the CLA at the bottom of > http://icu-project.org/trac/#cla ? It=E2=80=99s 1-click if you have a Git= hub > id. I don't have a github account so I looked at the form. I'm sorry, but I'm not going to sign that. 1) I don't want to give you my address and phone number. I have no idea who you are. 2) If you want people to contribute don't make them jump through hoops like this. Imagine if all open source projects required this. 3) I'm not sure what your form is supposed to accomplish. I recently went through a similar process with the FSF, but their form is a transfer of copyright to them so they have standing in court to fight GPL violations. This is part of their mission and I respect that even though I'm no fan of the GPL. I understand that such a transfer requires a more formal process with a legal signature. I have no such understanding with your form. It just looks like a license agreement. Why do you need my personal details and signature? It is completely obvious to any open source developer that when they contribute code to an open source project it is going to be distributed openly under the terms of the project license. If, for some odd reason, this is not legally obvious in front of a judge then the next step would be to put this form on your website as a simple clickwrap agreement, and not to go full blown signature required. 4) Under "Rights affecting the use of a Contribution" it says I should let you know if I know of any rights (e.g. patents) covering the contribution. I can't assess the full legal consequences of signing this. What happens exactly if there are patents that I don't know of and somebody gets sued over them? Can they try to claim that I should have known and therefore should have informed you and that the fact I didn't was a violation or some form of negligence? I cannot sign this without contacting a lawyer which I'm not going to do. Projects should protect their contributors as much as possible from legal shit, not make them vulnerable to it, especially when these contributors are essentially doing volunteer work for free. 5) The patches are small and trivial bug fixes and don't add anything new or original. I doubt copyright can even be asserted over them. 6) I have nothing to gain and possibly something to lose by signing that form and nothing to lose if I don't sign. Why would I sign? Please don't take "you" above personally. I know you are just following project protocol. >> patch-common_umutex.cpp: >> This code is compiled conditionally and one of the cases is a c++11 >> compiler without <atomic> header. uio.fState is an atomic variable and >> cannot be read directly. I used umtx_loadAcquire in the patch because >> that's what's used elsewhere to read fState. =20 > > OK. Why would <atomic> not be available? I didn't remember correctly. The code isn't compiled conditionally. The fState field is declared differently depending on the availability of <atomic>. With <atomic> it is declared as a C++11 atomic integer. Accessing such a variable like the unchanged code does is implicitly atomic. Using umtx_loadAcquire just makes it explicit. The code output from the compiler is the same. Without <atomic>, e.g. when ICU is compiled with a C++98 compiler or with incomplete implementations of C++11 (e.g. FreeBSD 9 has a C++11 capable compiler, but no runtime libraries), fState is not declared as an integer that you can access like the unchanged code does. You must always use one of the functions like umtx_loadAcquire.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161211231609.1e352e65>