Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blazegraph fork? #86

Open
berezovskyi opened this issue Apr 12, 2018 · 43 comments
Open

Blazegraph fork? #86

berezovskyi opened this issue Apr 12, 2018 · 43 comments

Comments

@berezovskyi
Copy link

Now that it seems Amazon has acquired Blazegraph (https://www.trademarkia.com/blazegraph-86498414.html etc), does it make sense for the OSS community to fork Blazegraph and restart the development (at least processing the PRs)?

@ianwdunlop
Copy link

Another goal of a forked/reborn blazegraph would be to migrate the sesame dependency to org.eclipse.rdf4j.

@ianwdunlop
Copy link

Anyone still interested in forking blazegraph and trying to keep it alive in the OSS community? Maybe someone already has. If so where is the project? Maybe a possible strategy is to fork and try to build from master and the latest unreleased branch (maybe 2.2.0). I've tried building but there are some test failures. Has anyone else tried building from source?

@beebs-systap
Copy link
Contributor

@ianwdunlop @berezovskyi We've had some recent discussions on this and there seems to be community interest, which we're working to gather together. Feel free to update this interest for folks that would be interested.

@smalyshev @thompsonbry

@nyurik
Copy link

nyurik commented Dec 1, 2018

I propose we set up a project, e.g. bigblaze or blazebig seem to be non-trademarked, and add anyone interested from the community as members. Of course it would be great if the original authors of Blazegraph would participate in this development.

@ianwdunlop
Copy link

@nyurik That's a fair proposal. It would be good to hear more from @beebs-systap and folks about what their intentions are - whether they would like to keep the original blazegraph repo going or if it is time to start a new project based on the existing code.

@thompsonbry
Copy link
Contributor

thompsonbry commented Dec 5, 2018 via email

@nyurik
Copy link

nyurik commented Dec 5, 2018

I think @smalyshev is doing an amazing job with various Blazegraph improvements, and certainly should be one of the key people driving this project forward, but I do not think Blazegraph fork should be under Wikimedia's umbrella, using less convenient or familiar tooling (gerrit/phabricator), or managed by WMF management. Rather, I think it should remain in GitHub e.g. a separate organization as a typical open source project, with a low barrier of entry, a wide community of contributing and reviewing developers, and WMF developers actively participating.

@thompsonbry
Copy link
Contributor

thompsonbry commented Dec 6, 2018 via email

@turbolent
Copy link

In https://github.com/turbolent/embergraph I've took 2.1.5-RC and started renaming the code to Embergraph (to avoid inflicting on trademarks), cleaning up the code base, and updating it (Java 8).

I plan on mostly updating the SPARQL server (probably replacing Jetty and servlets with something else) and will try to update dependencies (e.g. migrate to RDF4J).

@thompsonbry
Copy link
Contributor

thompsonbry commented Jan 14, 2019 via email

@thompsonbry
Copy link
Contributor

thompsonbry commented Jan 14, 2019 via email

@beebs-systap
Copy link
Contributor

@turbolent Would you be amenable to setting up a CLA to push the changes back into the core Blazegraph?

@ianwdunlop
Copy link

2 quick comments. Why do we need a CLA to push changes (via pull request I assume) back into the core blazegraph repo? Is this a different repo from this one? Isn't all this covered by the current licence (GPL 2)?
From recent comments it seems that you would like to restart blazegraph development using this repo rather than fork off to anywhere else. I like that idea.

@nyurik
Copy link

nyurik commented Jan 15, 2019

In https://github.com/turbolent/embergraph I've took 2.1.5-RC and started renaming the code to Embergraph (to avoid inflicting on trademarks), cleaning up the code base, and updating it (Java 8).

I plan on mostly updating the SPARQL server (probably replacing Jetty and servlets with something else) and will try to update dependencies (e.g. migrate to RDF4J).

I do like the Embergraph name, but there does seem to be another project by that name. Not sure if that's a problem.

I am not sure what you meant by renaming the code to Embergraph - IANAL, but it seems MariaDB who went through the similar process did not modified the actual code - as that would make the code incompatible with extensions/external modifications. There is a difference between classnames that use Blazegraph or Bigdata internally, and the branding of the product. I suspect we only need to modify the later.

@beebs-systap
Copy link
Contributor

@ianwdunlop @nyurik Yes, you can definitely fork it under GPLv2 into a separate project. However, we would like to see if there's interest in getting a set of interested parties to collaborate on restarting development in this github. WMF/Wikidata would definitely have a role as a significant stakeholder, but is not the only one. The CLA is needed to make sure that the contributions can be accepted under GPLv2, but it can be a fairly lightweight process. Would you be amenable to setting up a quick chat to discuss in more details?

@nyurik
Copy link

nyurik commented Jan 15, 2019

@beebs-systap I obviously would prefer not to fork if possible, and sure, ping me at my firstandlastname at gmail :) I was under the impression that now that the trademark belongs to Amazon, no one outside of Amazon can use it, hence the need for a fork. Another (possibly minor or irrelevant?) concern is re-licensing - e.g. if a person contributes code to this repo under GPL2, can Amazon re-license that contribution under a proprietary license?

@ianwdunlop
Copy link

I agree with @nyurik that keeping it in the original repo is preferred over a fork. If a CLA is necessary to contribute under gpl2 then that seems ok. I imagine what contributors need assurance over is that any code they commit remains open source forever. I guess we would have to clarify any trademark issues since that could cause problems for some people. Ping me at gmail for a lightweight discussion. One thought that did occur to me is what branch development should be focussed on? master or the latest unreleased branch or another? What would be the priorities for a re-invigorated blazegraph? I think it would be getting dependencies up to the latest rdf4j etc rather than focussing on new features.

@beebs-systap
Copy link
Contributor

@ianwdunlop @nyurik Sounds workable. Yes, everything would be open source under GPLv2 and the CLA is a fairly standard process (it has always been in-place for Bigdata/Blazegraph). I think there's two priorities; updating the 2.1.5 branch as needed and picking up the 2.2.0 branch for future work.

Let me setup a quick meeting/discussion offline with you and we can chat through some of the details.

@thompsonbry
Copy link
Contributor

thompsonbry commented Jan 16, 2019 via email

@berezovskyi
Copy link
Author

berezovskyi commented Feb 16, 2019

I am not sure if depending on Amazon's goodwill regarding the trademark is a good idea. Also, CLA likely means a copyright assignment process which would allow Amazon to use GPLed contributions in Neptune without contributing any patches back to Blazegraph under GPL, which might not be in the spirit of GPL.

But I understand that Wikimedia and a few others are major users of Blazegraph and we should hear their opinion. From a cursory look, seems like @turbolent and @ianwdunlop have the most active forks and the former is free from trademark use.

UPD: USPTO/WIPO have 0 hits on 'Embergraph'.

@thompsonbry
Copy link
Contributor

thompsonbry commented Feb 16, 2019 via email

@akuckartz
Copy link

Is that CLA published anywhere?

@thompsonbry
Copy link
Contributor

thompsonbry commented Feb 17, 2019 via email

@berezovskyi
Copy link
Author

@elft3r
Copy link

elft3r commented May 17, 2019

Hi everybody,
I'm currently in the process of evaluating different graph databases and one of them is blazegraph. It looks really promising, and we are thinking about choosing it for our solution.

However, the uncertainty of the future of this project, lets us still hesitate whether we should adopt it or not. Are there any updates about the plans of this project?

Thanks for your help,
Jochen

@beebs-systap
Copy link
Contributor

@elft3r Wikidata is running it in production and there's interest in continuing to move it forward.

@elft3r
Copy link

elft3r commented May 20, 2019

@beebs-systap Thanks for your quick reply. Are there already plans laid out on how it will move forward?

@beebs-systap
Copy link
Contributor

@elft3r There's ongoing discussion and a general outline, which is in process.

@berezovskyi
Copy link
Author

I am ok closing the issue given that there are new releases.

@ben-j-herbertz
Copy link

Hi all, what is the current status?
There was no new release for almost one year ...

@ben-j-herbertz
Copy link

Well, as there is nothing new, should the project considerd dead?

I don't see it up online off hand. It is referenced at [1,2]. Brad would be able to provide you with a current version. Thanks, Bryan [1] https://wiki.blazegraph.com/wiki/index.php/Contributors [2] https://www.blazegraph.com/develop/

And those links are not working anymore...

In https://github.com/turbolent/embergraph I've took 2.1.5-RC and started renaming the code to Embergraph (to avoid inflicting on trademarks), cleaning up the code base, and updating it (Java 8).

This fork is also not maintained anymore...

I would really like to help here.

@berezovskyi
Copy link
Author

Seems like teaming up with Wikimedia is the best course of action, their fork is very much alive:

@ben-j-herbertz
Copy link

ben-j-herbertz commented Feb 22, 2021

So what should be the plan here?

Is there any difference between the wmf fork and this one?

@berezovskyi
Copy link
Author

TBH, I only met one person from Wikimedia DE / Wikidata at a conference a few years ago who was not directly involved with Wikidata infra. We need to find a point of contact at the Wikidata infra team first to see if they are ready to lead the fork development (at least to package and publish it). Of course, would have been better if new maintainers could simply get write access to this org instead of forking...

@ben-j-herbertz
Copy link

I see, who has write access?

AFAIK the wmf fork is not really maintained as well..

@berezovskyi
Copy link
Author

@beebs-systap and @thompsonbry I would presume.

@ben-j-herbertz
Copy link

Ok, i saw the jira was last maintained by @beebs-systap and @igor-kim (Jan. 2020).

But i dont know if one should work on the Tickets as, they are not maintained as well..

@ben-j-herbertz
Copy link

FYI: I got a simple CI Pipeline working (build the jar + Docker Image)

@beebs-systap
Copy link
Contributor

@josn0w @berezovskyi I'd prefer to avoid a fork too. If you want to contribute, let's get a CLA in place and do it from within the current project. I'll reach out separately to discuss.

We'd also be interested in any others that also want to contribute.

@ben-j-herbertz
Copy link

@beebs-systap I would like to contribute here, if it is possible.
It would be great if you can update on the current status of the Project and the plan for the future.

@beebs-systap
Copy link
Contributor

@josn0w Great. Send me an email beebs [at] amazon.com RE: the CLA. The status of the project and the plan for the future depends on the contributors. We're happy to continue to support.

@jeffreyschultz
Copy link

any update on this discussion?

@berezovskyi
Copy link
Author

@jeffreyschultz I am using Jena/Fuseki and the built-in SWI-Prolog RDF store for most of my project work now. Not sure if @ben-j-herbertz got push/releng/issue triage rights to the repo.
I guess housekeeping like adding CI and updating CVE-affected dependencies would be the first step. Ensuring https://w3c.github.io/rdf-tests/ are covered would be another, though fixing issues like #234 would require some non-trivial commitment.

Wikimedia is evaluating migration off Blazegraph: https://phabricator.wikimedia.org/T206560

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants