Closed jbeich closed 8 years ago
I don't have a freebsd machine, so I won't be apply this.
I need a CLA for accepting changes; sorry.
Please reopen when you have a patch and have signed the CLA.
What is the best way around this CLA problem?
If the issue is that the CLA is hosted on the Google platform, would it be best to move it to a non-Google platform to allow regular non-Google-people to contribute? Or (and I suspect more likely) if the CLA itself is the issue, can this be given some further consideration, and failing that, can the project be forked and remove the requirement for a CLA?
The CLA can be signed by anybody, provided their employer is OK with it. It does not require someone to be "Google-people".
The link you point to is written from the perspective of a well-willing contributor, but unfortunately contributors (or their employers) are not always well-willing. The CLA protects us against these people.
See https://opensource.google.com/docs/cla/policy/ for an in-depth discussion of what the CLA is. and why we require it. The case book (https://google.github.io/opencasebook/) has further legal analysis of the relevant topics, which you may find interesting.
It goes without saying that you are free to fork this project and go crazy (within the terms of the license) with it.
The CLA can be signed by anybody, provided their employer is OK with it. It does not require someone to be "Google-people".
I tried following the link but it requires a Google account sign in. Only Google-people may pass. Resistence is futile. etc. etc. Luckily I made it back alive.
The link you point to is written from the perspective of a well-willing contributor, but unfortunately contributors (or their employers) are not always well-willing. The CLA protects us against these people.
This is probably just theoretical, because from the looks of above, the issue @jbeich has is not the CLA per se but access to it. Could you maybe have a Google form/spreadsheet thing for people (both Google and normal) to fill out?
See https://opensource.google.com/docs/cla/policy/ for an in-depth discussion of what the CLA is. and why we require it. The case book (https://google.github.io/opencasebook/) has further legal analysis of the relevant topics, which you may find interesting.
That CLA looks like it's for contributing to Google's code... but https://github.com/hanwen/go-fuse#disclaimer says go-fuse is not Google code....?
My only interest is really just that go-fuse work on BSD....
It is likely that a Google Form would also require you to sign in with a google account. .
If you are concerned about privacy implications of using a Google account, you could use an incognito tab to create an account. Then again, if you are concerned about privacy, you should probably not record your name and email address in a version control log that is public and retained indefinitely in the first place.
regarding https://github.com/hanwen/go-fuse#disclaimer
go-fuse is written by me, and I work for Google, which makes it copyrighted by Google. It is not a Google product, in the sense that it has no dedicated staffing.
says go-fuse is not Google code....?
AFAIK go-fuse is produced in part on Google company time. The disadvantage is that it must use Google's legal framework. The advantage is that go-fuse exists.
I'm pretty okay with that tradeoff.
If you are concerned about privacy implications of using a Google account, you could use an incognito tab to create an account. Then again, if you are concerned about privacy, you should probably not record your name and email address in a version control log that is public and retained indefinitely in the first place.
It's more for the OP wishing to contribute.
Is @jbeich in Iran, Syria, North Korea which would preclude them having a google account? If no, I suggest they switch off TOR for signing the CLA.
Is @jbeich in Iran, Syria, North Korea which would preclude them having a google account? If no, I suggest they switch off TOR for signing the CLA.
Hahah so the only legit reason not to have a Google account is if you're living in Syria.... I have no idea what the story is, but I'm sure they have their reasons.
We're not programs Gerty, we're people.
I'm not sure this discussion is leading anywhere. It will certainly not lead to google changing their legal framework.
Just trying to find a pragmatic solution/middle-ground.
(Not a PR due to CLA -> Google Account -> failed signup over Tor.)
and lots of similar errors can be fixed by copying from:
s/\.O_LARGEFILE/_O_LARGEFILE/
FreeBSD uses libfuse but not fusermount binary. Instead, the library calls mount_fusefs(8) with special argument obtained via
open("/dev/fuse", ...)
. Playing withsyscall.Dup()
was enough for mounting to succeed but any VFS operation still hangs.Regular users only need to
sysctl vfs.usermount=1
before mount/umount.NetBSD folks had an interesting discussion. OS X may unintentionally use ENODATA for unionfs here despite it's never returned.
http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&i=ENODATA http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&i=ENOATTR
syscall.SYS_POSIX_FALLOCATE
syscall
package