hello, happybase author here.
the gcloud happybase port violates my software's license. i do not like this.
the happybase license (mit+apache) is quite clear:
the above copyright notice and this permission notice shall be
included in all copies or substantial portions of the software.
http://happybase.readthedocs.io/en/latest/license.html
however, i don't see my name, the required notice, or even a small "thanks" or whatever, anywhere, neither in the gcloud docs, nor in the distributed software package itself.
the happybase port that is distributed with hbase contains considerable amounts of code written by me (for instance the whole api, and the implementation of connection pooling and other features is the same). and even though various docstrings have been partially adapted, proper attribution is in order here as well.
please fix this ASAP since this is NOT ok at all.
@wbolster This is totally my fault. Sorry for the mess up. It's something I had planned to do but the implementation process / porting over from https://github.com/dhermes/gcloud-python-bigtable took quite some time.
We fully intended gcloud.bigtable.happybase to be a drop-in replacement for happybase, hence the interface matching ("for instance the whole api"). It is a quite good abstraction for a somewhat contrived HBase / Thrift / Google Cloud Bigtable API. I assure the majority of the code (beyond the interface) is novel to this library, though as you mentioned connection pooling (and some string helpers) are quite similar.
@jgeewax Can we put license info directly in modules or should it go in the project or maybe something else?
ok, thank your for acknowledging my objections.
please keep me posted about the resolution.
btw, regardless of the number of lines of code that are shared, the simple fact that this library tries to be a drop-in replacement (on top of a different technology stack), and even (re)uses the original name, obviously makes this part of gcloud libs a derivative work of happybase, and hence the original work deserves mentioning, as prescribed by its license.
btw, i'm totally fine with this library existing. i encourage derivative works. i open-source my work so that others can benefit from it. and it's good to see that exactly that is what's happening.
happybase's license is very permissive exactly for this reason, so please adhere to it. :)
Thanks for the clarification.
@jgeewax PTAL
@wbolster : First -- huge apology if we didn't go about this the right way. IANAL but we certainly didn't intend to violate the MIT license. Second, thanks so much for being understanding here. I was out on vacation otherwise I would've replied much more quickly... Sorry about that.
Again, IANAL, but it sounds like we should...
gcloud.bigtable.happybase module (along with a pointer to the Happybase library)@tseaver / @dhermes : Is it acceptable to do as @wbolster did where we say that gcloud-python is Apache 2.0 licensed, and implements the Happybase API surface which is MIT licensed in our LICENSE file?
Thanks for getting back to me.
The easiest way to get everything solved is to simply include a snippet like this in a "license" page of the docs, alongside other licenses, including gcloud-python's own license, and be done with it:
Happybase API emulation for BigTable
====================================
The Happybase API emulation for BigTable as distributed with
gcloud-python is based on Happybase, which is distributed under the
MIT license. The original license text is included below.
HappyBase License
Copyright © 2012 Wouter Bolsterlee
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
“Software”), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
That way everything is covered. You don't need to get into specifics about whether APIs are copied, (parts of the) code is reused, docs are (partially) rewritten, and you don't have to worry about that either from a legal perspective since the original license allows you to do whatever you want with it, as long as you put the above notice somewhere.
That sounds great. Thanks again @wbolster for being so accommodating -- I really really appreciate it.
@dhermes : Does this look good to you guys? Can you toss up a PR and CC everyone?
A PR would be great, but before we merge let's let our open-source people review and make sure we're doing the right thing for everyone. I've reached out to them.
<sarcasm>
i am very happy to see that google has taken appropriate steps to resolve this issue in such a timely manner. that "fix asap" label really helped.
</sarcasm>
to be clear: google is violating my software's license, and it can be fixed by JUST COPYING AND PASTING SOME TEXT INTO YOUR DOCS as i mentioned before in https://github.com/GoogleCloudPlatform/gcloud-python/issues/1762#issuecomment-216556428
very professional. great work. kudos.
ping @jgeewax @dhermes @jonparrott
@wbolster after some conversations with our lawyers, we need to actually split this into a completely separate package.
@jgeewax any reservations?
@dhermes @tseaver which of you wants to own doing this? Let me know if there's anything you need from our end to make this happen.
This is _highest priority_.
splitting code into separate packages is a purely technical choice. there is no need for it from a legal perspective as happybase's license allows you to simply copy/paste whatever parts you like... as long as you adhere to its license terms. :)
... and adhering to happybase's very permissive license really only requires mentioning its license information (see my earlier comment above) in the appropriate section of your own documentation.
@wbolster that may be the case, but our lawyers are the type to exercise an abundance of caution. So that there is no question, they would prefer we distribute the happybase portion of this separately and under the same license as the upstream happybase project. This is to protect both this project and your project.
We're trying to do the right thing here and it's sometimes difficult to make sure we're making the right move. I know we've asked a lot of your patience, please bear with us as we close this loop here.
@jgeewax needs to confirm he's fine with this approach and we can move forward.
I'm 100% fine with this. I thought we updated the license immediately...
Can we do that like.. now? And then worry about splitting out packages?
Just to be abundantly clear: this has a ticking clock starting now. If it's not resolved by Fri Aug 19th I'm going to fix it the shitty way by deleting a bunch of code. :(
@jgeewax @wbolster @jonparrott can we add this to the end of https://github.com/GoogleCloudPlatform/gcloud-python/blob/master/LICENSE?
@wbolster, @jonparrott @dhermes see https://github.com/GoogleCloudPlatform/gcloud-python/pull/2101
@daspecster that's insufficient according to our lawyers.
Ok, what's required to split it out?
On Monday, August 15, 2016, Jon Wayne Parrott [email protected]
wrote:
@daspecster https://github.com/daspecster that's insufficient according
to our lawyers.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-python/issues/1762#issuecomment-239833378,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALvyH2quYbAQc2Pmo9_wDYVEl-euMOcks5qgIX9gaJpZM4IRvVK
.
Tom Schultz
Separate repository. We can publish it as its own pypi package.
@jonparrott could we update the license for now and then work on splitting it out? Seems like that might make everyone happy. Unless the lawyers think that would create new problems?
@daspecster our lawyers told us we had two options: (1) relicense this entire project under HappyBase's license, or (2) split out the happybase portion into its own repository and library.
Ah ok, interesting. Thanks for the clarification!
On Mon, Aug 15, 2016 at 12:55 PM, Jon Wayne Parrott <
[email protected]> wrote:
@daspecster https://github.com/daspecster our lawyers told us we had
two options: (1) relicense this entire project under HappyBase's license,
or (2) split out the happybase portion into its own repository and library.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-python/issues/1762#issuecomment-239858887,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALvyFAW6JoD3b26Sv2xM2jJr4b7T7kRks5qgJnmgaJpZM4IRvVK
.
Tom Schultz
are you sure your lawyers understand that happybase is NOT under a viral license and hence never infects surrounding code?
i mean, it's all up to you, but to me it sounds like severe overkill and a huge effort, which is not required at all to address the issue at hand.
really, copy, paste, commit, and everybody will be happy.
are you sure your lawyers understand that happybase is NOT under a viral license and hence never infects surrounding code?
Within a reasonable margin of error, yes.
really, copy, paste, commit, and everybody will be happy.
Engineers, sure, but not the lawyers, who happen to be the deciders here.
I appreciate your patience and willingness to work with us. I don't anticipate the idea of having separate libraries that are built on top of gcloud-python to be unique to this happybase part. I'd anticipate us having several libraries like this before it's all said and done. So, we're just paving the way here.
So we need a new repo under GoogleCloudPlatform that is named something like google-cloud-python-bigtable-happybase? Which isn't a great name.
Not sure this would jive with https://github.com/GoogleCloudPlatform/gcloud-common/issues/159.
Since it assumes that the packages are still in the same language based repo.
i.e. https://github.com/GoogleCloudPlatform/gcloud-ruby
Should we just drop it from the codebase for now?
So we need a new repo under GoogleCloudPlatform that is named something like google-cloud-python-bigtable-happybase? Which isn't a great name.
Name is up to you guys.
Since it assumes that the packages are still in the same language based repo.
Not sure how it would mesh with that. You could make the a namespace package google.cloud.happybase and actually install it in this package's documentation dependencies. That's a little weird, but might be a decent short term solution.
@dhermes do you have permissions to create new repositories or maybe @omaray?
I don't have permission. @omaray can you go figure out who can create a new repo called google-cloud-python-bigtable-happybase ? (Yes, it's long, but most people will get it for free via pip install google-cloud or google-cloud-bigtable)
Is google-cloud-python-happybase not clear? Ditto on the PyPI package name?
I'm good with google-cloud-python-happybase.
The clock is almost out on this... Who is getting that new repo created ?
@omaray ?
I can work on setting up the new repository locally. I believe the repo name should be google-cloud-python-happybase, but the PyPI name should be google-cloud-happybase.
@tseaver, @dhermes sounded like him and @jonparrott had already started on this. Is there a confirmation?
I haven't started. Waiting for @omaray, @jonparrott or someone else with Google permission to create the new repo. (I used to be able to but no longer do.)
Just created https://pypi.python.org/pypi/google-cloud-happybase
I'm gonna reach out to our devrel github admin @elibixby to get it created.
@dhermes, @daspecster, @jgeewax I have a version pushed under my account, with the license text from the Happybase project. tox passes everything: I'm still waiting to see Travis green.
Thanks, @tseaver. Can you go ahead and add me and @elibixby as admins on that repo? We'll transfer it to GoogleCloudPlatform.
Thanks @jonparrott.
... for future reference I don't have permissions on the org to create repos... but we know who does.
@jonparrott I've sent invites to the two of you, and will make you admins as soon as they are completed.
@jonparrott I see you have accepted the invite, but I don't seem to have the ability to give you anything other than "Collaborator" access (no "Teams" on personal repos).
@tseaver yeah hang tight.
If I have push access to the new "canonical" repo, I can just push there and delete my repo.
Canonical repo is setup at https://github.com/GoogleCloudPlatform/google-cloud-python-happybase
All admins here should have admin there.
I synced the canonical one with yours, so feel free to go ahead and delete yours.
Thanks everyone!
PR #2109 removes the Happybase-related code from this repository.
I also created an issue in the new repo for the one open Happybase-releated issue here (#1546).
@wbolster thank you for your patience. Is everything acceptable to you? Please let us know if there's anything else you feel we should do.
@wbolster : Again, apologies for the lag on getting this done, and thank you for the patience. Can you let us know if this fixes things?
Thanks all (@tseaver, @jonparrott , @daspecster , and everyone else) who helped to resolve this. Let's try to speed up next time so it doesn't take so long...
yeah, as i said numerous times before, just include the license and point out that your package is an emulation of my happybase package. i think both are covered now in the new repo's README.
Most helpful comment
I'm gonna reach out to our devrel github admin @elibixby to get it created.