Can I take over development of this project?

[Jeffrey Phillips Freeman]

From @freemo on October 17, 2016 15:20

Hi, my project has a pressing need to rely on aparapi and as such I have been contributing on the project in my own repositories. Since I will be contributing significant amount of work I'd like to contribute back that effort. You are of course welcome to adopt the project back into yours but you will find a lot has changed and that may be difficult at this point, but please feel free. If not perhaps the team would like to consider moving over to my new repositories for future effort? I am willing to discuss alternatives as well.

Here is a recap of what I did so far and where the new repositories can be found.

Everything has been mavinized!

All new code is licensed under the apache license. Also since AMD is no longer the maintainer I changed the root package across all the projects.

I pulled out the core java library. This is where all the platform independent code lives and ultimately produces the jar that will be used as the dependencies. This is now its own repository and can be found here:

https://github.com/Syncleus/aparapi

I pulled out all the platform specific code, the JNI layer, into its own repository. This no longer uses ant, as the project has been mavenized. But it isnt a Java project either, so it doesnt use maven. It has been refactored to use autotools, which is a platform independent way to compile shared libraries. It currently only compiles for linux platforms though. The code for the JNI libraries can now be found here, it uses submodules so please clone recursively:

https://github.com/Syncleus/aparapi-jni

I also created an Archlinux AUR and an unofficial binary repository for the aparapi system-specific shared library. This will allow installation of the aparapi shared library using the archlinux package management system, and uninstallation as well. The AUR can be found here:

https://github.com/Syncleus/aparapi-archlinux

To add the unofficial repository to archlinux for use with pacman then add the following line to your /etc/pacman.conf file, before all the other repositories:

[aparapi]
SigLevel = Optional TrustAll
Server = http://syncleus.com/aparapi-archlinux-repo/

The examples are now also a separate repository, as it isnt really needed for the library itself. This has the life sample mavenized and working but still need to mavenize the rest of the examples. This repo can be found here:

https://github.com/Syncleus/aparapi-examples

Finally I purchased the aparapi.com domain name so I can start hosting some useful information about it and host some files there. I also have an account on maven central so I will soon be able to upload aparapi there as it is now in a state where it can be consumed as a dependency (since it is completely mavenized).

So let me know what you guys think about joining efforts and perhaps moving the development over to the new repositories?

Copied from original issue: aparapi/aparapi#39

[Jeffrey Phillips Freeman]

From @grfrost on October 17, 2016 19:10

Hey Freemo

As the original developer/architect I have no problem with this and am glad
that you are extracting value from Aparapi and adding value by making it
more readily available.

My only caution would be the relicensing under Apache, I am not a lawyer
but you might need AMD's permission to do that.

I look forward to pulling from git and tinkering. Can you tel me what
domain you are working in? Looks like it may be Machine Learning (an area
I am working with at Facebook these days).

Love the idea that you have aparapi.com ;)

Gary

On Mon, Oct 17, 2016 at 8:20 AM, Jeffrey Phillips Freeman <
[e-mail]> wrote:

Hi, my project has a pressing need to rely on aparapi and as such I have
been contributing on the project in my own repositories. Since I will be
contributing significant amount of work I'd like to contribute back that
effort. You are of course welcome to adopt the project back into yours but
you will find a lot has changed and that may be difficult at this point,
but please feel free. If not perhaps the team would like to consider moving
over to my new repositories for future effort? I am willing to discuss
alternatives as well.

Here is a recap of what I did so far and where the new repositories can be
found.

Everything has been mavinized!

All new code is licensed under the apache license. Also since AMD is no
longer the maintainer I changed the root package across all the projects.

I pulled out the core java library. This is where all the platform
independent code lives and ultimately produces the jar that will be used as
the dependencies. This is now its own repository and can be found here:

https://github.com/Syncleus/aparapi https://github.com/Syncleus/aparapi

I pulled out all the platform specific code, the JNI layer, into its own
repository. This no longer uses ant, as the project has been mavenized. But
it isnt a Java project either, so it doesnt use maven. It has been
refactored to use autotools, which is a platform independent way to compile
shared libraries. It currently only compiles for linux platforms though.
The code for the JNI libraries can now be found here, it uses submodules so
please clone recursively:

https://github.com/Syncleus/aparapi-jni
https://github.com/Syncleus/aparapi-jni

I also created an Archlinux AUR and an unofficial binary repository for
the aparapi system-specific shared library. This will allow installation of
the aparapi shared library using the archlinux package management system,
and uninstallation as well. The AUR can be found here:

https://github.com/Syncleus/aparapi-archlinux
https://github.com/Syncleus/aparapi-archlinux

To add the unofficial repository to archlinux for use with pacman then add
the following line to your /etc/pacman.conf file, before all the other
repositories:

[aparapi]
SigLevel = Optional TrustAll
Server = http://syncleus.com/aparapi-archlinux-repo/

The examples are now also a separate repository, as it isnt really needed
for the library itself. This has the life sample mavenized and working but
still need to mavenize the rest of the examples. This repo can be found
here:

https://github.com/Syncleus/aparapi-examples
https://github.com/Syncleus/aparapi-examples

Finally I purchased the aparapi.com domain name so I can start hosting
some useful information about it and host some files there. I also have an
account on maven central so I will soon be able to upload aparapi there as
it is now in a state where it can be consumed as a dependency (since it is
completely mavenized).

So let me know what you guys think about joining efforts and perhaps
moving the development over to the new repositories?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEKiNwOzd7EdC-NGvehQYA2UuZT-WlRdks5q05JHgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

From @paxcalpt on October 17, 2016 19:48

Hi Jeffrey,

Just adding my own support to this.

We extensively use aparapi in academic research for image processing. We
already have a couple of papers on analytics that take advantage of aparapi
extensively.

I'm all for seeing further support of aparapi, one minor request would be
to keep support for multiple OSs as our user base mostly works on OSX and
Win.

Best,
-Ricardo
On Mon, 17 Oct 2016 at 20:10, grfrost [e-mail] wrote:

Hey Freemo

As the original developer/architect I have no problem with this and am glad
that you are extracting value from Aparapi and adding value by making it
more readily available.

My only caution would be the relicensing under Apache, I am not a lawyer
but you might need AMD's permission to do that.

I look forward to pulling from git and tinkering. Can you tel me what
domain you are working in? Looks like it may be Machine Learning (an area
I am working with at Facebook these days).

Love the idea that you have aparapi.com ;)

Gary

On Mon, Oct 17, 2016 at 8:20 AM, Jeffrey Phillips Freeman <
[e-mail]> wrote:

Hi, my project has a pressing need to rely on aparapi and as such I have
been contributing on the project in my own repositories. Since I will be
contributing significant amount of work I'd like to contribute back that
effort. You are of course welcome to adopt the project back into yours
but
you will find a lot has changed and that may be difficult at this point,
but please feel free. If not perhaps the team would like to consider
moving
over to my new repositories for future effort? I am willing to discuss
alternatives as well.

Here is a recap of what I did so far and where the new repositories can
be
found.

Everything has been mavinized!

All new code is licensed under the apache license. Also since AMD is no
longer the maintainer I changed the root package across all the projects.

I pulled out the core java library. This is where all the platform
independent code lives and ultimately produces the jar that will be used
as
the dependencies. This is now its own repository and can be found here:

https://github.com/Syncleus/aparapi <
https://github.com/Syncleus/aparapi>

I pulled out all the platform specific code, the JNI layer, into its own
repository. This no longer uses ant, as the project has been mavenized.
But
it isnt a Java project either, so it doesnt use maven. It has been
refactored to use autotools, which is a platform independent way to
compile
shared libraries. It currently only compiles for linux platforms though.
The code for the JNI libraries can now be found here, it uses submodules
so
please clone recursively:

https://github.com/Syncleus/aparapi-jni
https://github.com/Syncleus/aparapi-jni

I also created an Archlinux AUR and an unofficial binary repository for
the aparapi system-specific shared library. This will allow installation
of
the aparapi shared library using the archlinux package management system,
and uninstallation as well. The AUR can be found here:

https://github.com/Syncleus/aparapi-archlinux
https://github.com/Syncleus/aparapi-archlinux

To add the unofficial repository to archlinux for use with pacman then
add
the following line to your /etc/pacman.conf file, before all the other
repositories:

[aparapi]
SigLevel = Optional TrustAll
Server = http://syncleus.com/aparapi-archlinux-repo/

The examples are now also a separate repository, as it isnt really needed
for the library itself. This has the life sample mavenized and working
but
still need to mavenize the rest of the examples. This repo can be found
here:

https://github.com/Syncleus/aparapi-examples
https://github.com/Syncleus/aparapi-examples

Finally I purchased the aparapi.com domain name so I can start hosting
some useful information about it and host some files there. I also have
an
account on maven central so I will soon be able to upload aparapi there
as
it is now in a state where it can be consumed as a dependency (since it
is
completely mavenized).

So let me know what you guys think about joining efforts and perhaps
moving the development over to the new repositories?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39, or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AEKiNwOzd7EdC-NGvehQYA2UuZT-WlRdks5q05JHgaJpZM4KYwLm

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAunbb_MI_akbVS4FxNf-DaTpQ8niJQlks5q08gVgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

@grfrost Hey. It is indeed Machine Learning. I worked on a pure Java Machine learning library a while back. I'm in the middle of writing a new one from scratch backed by graph databases (including in-memory graph databases) and GPU acceleration. Ferma is already a ORM for graph databases that fulfilled half of my needs. Aparapi is the other half/

@paxcalpt I have every intention of maintaining other operating systems to the best of my ability. Right now I'm starting with Archlinux but one reason I used autotools is because it boasts a platform independent way of building binaries. So I should be able to maintain OSX and windows libraries easily enough. I just need to get vagrant booting some dev images up.

[Jeffrey Phillips Freeman]

I also created a aparapi gitter room if anyone wants to join: https://gitter.im/Syncleus/aparapi

[Jeffrey Phillips Freeman]

From @SubaruWRC on November 15, 2016 21:17

Everyone,

Sorry it had taken me so long to reply, life is busy these days. I have a couple of points I'd like to make, hopefully this discussion can lead to some positive outcomes:

• As the current lead of Aparapi Github effort, I wanted to build a strong community of people who could feel free to contribute to this effort directly, without having to create forks and incompatible releases because a single owner/steward needed to review everything. To that end, there are already multiple admins of this Github repo and multiple developers. If someone wants to become an admin, please just let me know.
• The #1 reason that this effort has had slow releases is because it is incredibly difficult to find computers that have all the necessary operating systems and hardware for testing. Sure, we could build Aparapi for Linux only, but then what's the point? To partially address the need to support Linux + Windows + OS X, we've resorted to building Aparapi in a private cloud computing environment using Jenkins, but it takes a lot of work to maintain. On top of that, OS X cannot be virtualized in the cloud at all and Windows licenses are not free.
• The #2 reason this effort has had slow releases is because it is a purely volunteer effort. We all have day jobs (hopefully), families, etc. and if our day job stops funding our Aparapi work, we stop working on it, unless we can find time to work on it on the side that does not impact our families. This is the reason I am 100% against forking this effort just for the sake of it. The person who makes the fork will ultimately change jobs, change focus, lose funding, etc. and the effort will once again fall into a state of non-maintenance. Except now there will be multiple conflicting, non-compatible dead forks of the original effort.

In summary, I am all for some of the changes you suggest to the code and project. I am completely against forking and moving the entire community to a fork that is guaranteed to become stale. How about we keep growing this existing effort, continue to add new admins/devs/etc.?

Sent from my iPhone --- Please excuse any typos or autocorrect mistakes

On Oct 17, 2016, at 12:49 PM, Ricardo Henriques [e-mail] wrote:

Hi Jeffrey,

Just adding my own support to this.

We extensively use aparapi in academic research for image processing. We
already have a couple of papers on analytics that take advantage of aparapi
extensively.

I'm all for seeing further support of aparapi, one minor request would be
to keep support for multiple OSs as our user base mostly works on OSX and
Win.

Best,
-Ricardo
On Mon, 17 Oct 2016 at 20:10, grfrost [e-mail] wrote:

Hey Freemo

As the original developer/architect I have no problem with this and am glad
that you are extracting value from Aparapi and adding value by making it
more readily available.

My only caution would be the relicensing under Apache, I am not a lawyer
but you might need AMD's permission to do that.

I look forward to pulling from git and tinkering. Can you tel me what
domain you are working in? Looks like it may be Machine Learning (an area
I am working with at Facebook these days).

Love the idea that you have aparapi.com ;)

Gary

On Mon, Oct 17, 2016 at 8:20 AM, Jeffrey Phillips Freeman <
[e-mail]> wrote:

Hi, my project has a pressing need to rely on aparapi and as such I have
been contributing on the project in my own repositories. Since I will be
contributing significant amount of work I'd like to contribute back that
effort. You are of course welcome to adopt the project back into yours
but
you will find a lot has changed and that may be difficult at this point,
but please feel free. If not perhaps the team would like to consider
moving
over to my new repositories for future effort? I am willing to discuss
alternatives as well.

Here is a recap of what I did so far and where the new repositories can
be
found.

Everything has been mavinized!

All new code is licensed under the apache license. Also since AMD is no
longer the maintainer I changed the root package across all the projects.

I pulled out the core java library. This is where all the platform
independent code lives and ultimately produces the jar that will be used
as
the dependencies. This is now its own repository and can be found here:

https://github.com/Syncleus/aparapi <
https://github.com/Syncleus/aparapi>

I pulled out all the platform specific code, the JNI layer, into its own
repository. This no longer uses ant, as the project has been mavenized.
But
it isnt a Java project either, so it doesnt use maven. It has been
refactored to use autotools, which is a platform independent way to
compile
shared libraries. It currently only compiles for linux platforms though.
The code for the JNI libraries can now be found here, it uses submodules
so
please clone recursively:

https://github.com/Syncleus/aparapi-jni
https://github.com/Syncleus/aparapi-jni

I also created an Archlinux AUR and an unofficial binary repository for
the aparapi system-specific shared library. This will allow installation
of
the aparapi shared library using the archlinux package management system,
and uninstallation as well. The AUR can be found here:

https://github.com/Syncleus/aparapi-archlinux
https://github.com/Syncleus/aparapi-archlinux

To add the unofficial repository to archlinux for use with pacman then
add
the following line to your /etc/pacman.conf file, before all the other
repositories:

[aparapi]
SigLevel = Optional TrustAll
Server = http://syncleus.com/aparapi-archlinux-repo/

The examples are now also a separate repository, as it isnt really needed
for the library itself. This has the life sample mavenized and working
but
still need to mavenize the rest of the examples. This repo can be found
here:

https://github.com/Syncleus/aparapi-examples
https://github.com/Syncleus/aparapi-examples

Finally I purchased the aparapi.com domain name so I can start hosting
some useful information about it and host some files there. I also have
an
account on maven central so I will soon be able to upload aparapi there
as
it is now in a state where it can be consumed as a dependency (since it
is
completely mavenized).

So let me know what you guys think about joining efforts and perhaps
moving the development over to the new repositories?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39, or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AEKiNwOzd7EdC-NGvehQYA2UuZT-WlRdks5q05JHgaJpZM4KYwLm

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAunbb_MI_akbVS4FxNf-DaTpQ8niJQlks5q08gVgaJpZM4KYwLm
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Jeffrey Phillips Freeman]

Thank you for the reply, please don't ever feel obligated. Open-source as
you said is volunteering, and I am most grateful for any time you have ever
or will ever give to the project. I certainly am not complaining about the
limited participation, totally understandable.

I would not be opposed to becoming an admin of the repository. and to
moving my efforts over to this group. Of course we would have to create
multiple repositories to keep my changes. But thats not so much an issue as
a note.

I totally understand the difficulty it would be to create a full test-bed
for this project. I've been a professional in java for 19 years with a lot
of experience in that, so I could help with that as well. I myself however
would have no problem making the project Linux only for my own needs, but
ideally keeping it windows is best for the community. But naturally that
means I can help more on the linux side than the windows side. With that
said there is another point to consider. If I am able to take the project
under my own stewardship (or rather my company), then I will also invest a
sizable portion of my own income (since I'm the only owner in the company)
into the windows licenses and servers to make a test-bed possible. Now if
we keep the stewardship in your hands I will still contribute time, but
financially I am less motivated to contribute on any test-bed that does not
benefit me directly. I hope you understand.

There is another concern for me personally. If I contribute to your project
rather than my own fork, then I cant really make changes as quickly, I
would need to ensure the community discusses it, and then ultimately you
(as the owner) gives the go ahead. Since I am a person who wants to get a
lot done quickly that sort of scenario would only be effective for me if
the owner of the project were able to give a significant portion of his
time to the role (enough that they can make these sorts of decisions
quickly and participate in the on going discussions throughout the day).
Without that because I have certain demands from the project, and my other
projects are stalled if Aparapi is stalled, all in all it means I will have
to fork the project, or be given full autonomy to modify the project as I
see fit and make releases (which I would not expect to have on your
project, and rightfully so). So just all things to consider on that point I
suppose.

There is one final thing to consider. You, as the Stewart of the current
effort, basically have first rights to the project if you wish to continue
in that role. I would not, out of respect, co-opt that name away from you.
I would create my own fork of this project and change the name and make it
a new project. But, as I make those changes this project could also pull
those changes in. As long as the devs in this project stay current with
pulling from my project you can still reap all the benefits from my project
and keep your own "flavor" as well. This way if either of our projects go
stale, whichever one remains is still up to date and can move forward.

Anyway, long story short, depending on how quickly this project can move,
and how many changes it can pull in I would be willing to just help you
guys out directly. If my own needs can't be met by the pace of this project
then I will have to keep my own project active (under a new name) and you
guys just pull from my git if you wish (I kept the git history so you guys
could do exactly that if you wish). So we just need to decide which path
you want to take to proceed. I await hearing from you, and look forward to
the possibility of working with you.

On Tue, Nov 15, 2016 at 4:17 PM, SubaruWRC [e-mail] wrote:

Everyone,

Sorry it had taken me so long to reply, life is busy these days. I have a
couple of points I'd like to make, hopefully this discussion can lead to
some positive outcomes:

• As the current lead of Aparapi Github effort, I wanted to build a strong
  community of people who could feel free to contribute to this effort
  directly, without having to create forks and incompatible releases because
  a single owner/steward needed to review everything. To that end, there are
  already multiple admins of this Github repo and multiple developers. If
  someone wants to become an admin, please just let me know.
• The #1 reason that this effort has had slow releases is because it is
  incredibly difficult to find computers that have all the necessary
  operating systems and hardware for testing. Sure, we could build Aparapi
  for Linux only, but then what's the point? To partially address the need to
  support Linux + Windows + OS X, we've resorted to building Aparapi in a
  private cloud computing environment using Jenkins, but it takes a lot of
  work to maintain. On top of that, OS X cannot be virtualized in the cloud
  at all and Windows licenses are not free.
• The #2 reason this effort has had slow releases is because it is a
  purely volunteer effort. We all have day jobs (hopefully), families, etc.
  and if our day job stops funding our Aparapi work, we stop working on it,
  unless we can find time to work on it on the side that does not impact our
  families. This is the reason I am 100% against forking this effort just for
  the sake of it. The person who makes the fork will ultimately change jobs,
  change focus, lose funding, etc. and the effort will once again fall into a
  state of non-maintenance. Except now there will be multiple conflicting,
  non-compatible dead forks of the original effort.

In summary, I am all for some of the changes you suggest to the code and
project. I am completely against forking and moving the entire community to
a fork that is guaranteed to become stale. How about we keep growing this
existing effort, continue to add new admins/devs/etc.?

Sent from my iPhone --- Please excuse any typos or autocorrect mistakes

On Oct 17, 2016, at 12:49 PM, Ricardo Henriques <
[e-mail]> wrote:

Hi Jeffrey,

Just adding my own support to this.

We extensively use aparapi in academic research for image processing. We
already have a couple of papers on analytics that take advantage of
aparapi
extensively.

I'm all for seeing further support of aparapi, one minor request would be
to keep support for multiple OSs as our user base mostly works on OSX and
Win.

Best,
-Ricardo
On Mon, 17 Oct 2016 at 20:10, grfrost [e-mail] wrote:

Hey Freemo

As the original developer/architect I have no problem with this and am
glad
that you are extracting value from Aparapi and adding value by making
it
more readily available.

My only caution would be the relicensing under Apache, I am not a
lawyer
but you might need AMD's permission to do that.

I look forward to pulling from git and tinkering. Can you tel me what
domain you are working in? Looks like it may be Machine Learning (an
area
I am working with at Facebook these days).

Love the idea that you have aparapi.com ;)

Gary

On Mon, Oct 17, 2016 at 8:20 AM, Jeffrey Phillips Freeman <
[e-mail]> wrote:

Hi, my project has a pressing need to rely on aparapi and as such I
have
been contributing on the project in my own repositories. Since I
will be
contributing significant amount of work I'd like to contribute back
that
effort. You are of course welcome to adopt the project back into
yours
but
you will find a lot has changed and that may be difficult at this
point,
but please feel free. If not perhaps the team would like to consider
moving
over to my new repositories for future effort? I am willing to
discuss
alternatives as well.

Here is a recap of what I did so far and where the new repositories
can
be
found.

Everything has been mavinized!

All new code is licensed under the apache license. Also since AMD is
no
longer the maintainer I changed the root package across all the
projects.

I pulled out the core java library. This is where all the platform
independent code lives and ultimately produces the jar that will be
used
as
the dependencies. This is now its own repository and can be found
here:

https://github.com/Syncleus/aparapi <
https://github.com/Syncleus/aparapi>

I pulled out all the platform specific code, the JNI layer, into its
own
repository. This no longer uses ant, as the project has been
mavenized.
But
it isnt a Java project either, so it doesnt use maven. It has been
refactored to use autotools, which is a platform independent way to
compile
shared libraries. It currently only compiles for linux platforms
though.
The code for the JNI libraries can now be found here, it uses
submodules
so
please clone recursively:

https://github.com/Syncleus/aparapi-jni
https://github.com/Syncleus/aparapi-jni

I also created an Archlinux AUR and an unofficial binary repository
for
the aparapi system-specific shared library. This will allow
installation
of
the aparapi shared library using the archlinux package management
system,
and uninstallation as well. The AUR can be found here:

https://github.com/Syncleus/aparapi-archlinux
https://github.com/Syncleus/aparapi-archlinux

To add the unofficial repository to archlinux for use with pacman
then
add
the following line to your /etc/pacman.conf file, before all the
other
repositories:

[aparapi]
SigLevel = Optional TrustAll
Server = http://syncleus.com/aparapi-archlinux-repo/

The examples are now also a separate repository, as it isnt really
needed
for the library itself. This has the life sample mavenized and
working
but
still need to mavenize the rest of the examples. This repo can be
found
here:

https://github.com/Syncleus/aparapi-examples
https://github.com/Syncleus/aparapi-examples

Finally I purchased the aparapi.com domain name so I can start
hosting
some useful information about it and host some files there. I also
have
an
account on maven central so I will soon be able to upload aparapi
there
as
it is now in a state where it can be consumed as a dependency (since
it
is
completely mavenized).

So let me know what you guys think about joining efforts and perhaps
moving the development over to the new repositories?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39, or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AEKiNwOzd7EdC-
NGvehQYA2UuZT-WlRdks5q05JHgaJpZM4KYwLm

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AAunbb_MI_akbVS4FxNf-DaTpQ8niJQlks5q08gVgaJpZM4KYwLm>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC5JAj5UbWdpPkdCdsg87sYDiOSLXe1Dks5q-iFwgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

From @rlamothe on November 16, 2016 22:42

I appreciate your thoughtful response, but I am not sure I am following some of your concerns. Right now, the project already has a number of "admins" who are not required to fork the effort nor ask for my permission before committing code changes. You can see the list at https://github.com/orgs/aparapi/people. The effort is also setup as an organization, so committers can create their own sub-repos if necessary. This was done to ensure that large breaking changes, such as the lambda repo, could occur in parallel with the main development trunk. For example, in my organization, Maven is now old news and Gradle is the new hotness. It turns out that it is usually easiest to not completely mix those two things. Ideally, proper architecting of the Aparapi repos should allow both source paths to occur, but someone needs to think through that ahead-of-time. I am okay with adding you as an admin, but I will re-iterate that we need to be careful of two things: 1) The entire code base does not turn into a single use case, single operating system solution 2) If/when your company is no longer functioning or working on Aparapi, the project continues to remain viable for others. Also take note that none of the issues at https://code.google.com/archive/p/aparapi/issues were migrated to Github and many of those issues are still outstanding.

[Jeffrey Phillips Freeman]

If development can proceed in a way that incorporates my concerns then I
have no real objection. There are currently 4 separate repos, fully working
under maven and libtools. Does this mean we can fully import those changes
immediately, as well as release them to maven central? The impression I got
was that there would be more of a process to get things like this adopted,
but if i was incorrect then that concern might be washed away.

Also I am totally fine with continuing support for windows, but as I said
if i am contributing to the project (rather than becoming the owner) then
any windows support (both money and time) would be on other developers who
need this support, not me. As I said as an owner with a vested interest I
could invest corporate funds, and my own money, to that end (even hire
developers to help, or use my own team), but as an individual as part of
someone else's project I wouldn't contribute to the Windows side. Since you
said the cost and development on the windows side is part of the slow down,
don't you feel that may ultimately slow things down with me as a
contributor? I guess what I'm getting at is if i can contribute fixes and
patches that are tested and verified on the Linux side, it will be up to
the rest of the team to ensure the windows half of that doesn't lag behind.
Can you ensure you and the rest of the team can deliver in that regard?

As for #2 I can give a few reassurances. First off one of my oldest active
projects is dANN it is over 11 years old and still active. I also have
several other projects I maintain anywhere from 4 - 10 years old. So there
is a strong history there that would suggest projects I maintain aren't
very likely to go stale. Some of these projects today are the top in their
class. Also, like you, all my projects are hosted on github and any
contributors who wish to be an active part of the community can become a
developer. So I'd be happy to give anyone here the same privileges there.
So the risks regarding the project going stale are no different than here.
Although with money to funnel into the project the risk of it going stale
is less Id say.

If you are ok with forgoing the funding that would come from my company
taking over development then I will happily contribute to this project
instead. I can merge in the current changes immediately (once you make me
an admin) and whoever is the top maintainer of the windows testing on your
side can ensure the testing on the windows side keeps up. However if you
decide you'd like my company to take over ownership of the project, and
provide both funding, and developers, to maintain the windows
compatibility, I can do that as well.

I will also need access to be able to push releases out to maven central if
you wish me to be a contributor on this project.

On Wed, Nov 16, 2016 at 5:42 PM, rlamothe <[e-mail]

wrote:

I appreciate your thoughtful response, but I am not sure I am following
some of your concerns. Right now, the project already has a number of
"admins" who are not required to fork the effort nor ask for my permission
before committing code changes. You can see the list at
https://github.com/orgs/aparapi/people. The effort is also setup as an
organization, so committers can can actually create their own sub-repos if
necessary. This was done to ensure that large breaking changes, such as the
lambda repo, could occur in parallel with the main development trunk. For
example, in my organization, Maven is now old news and Gradle is the new
hotness. It turns out that it is usually easiest to not completely mix
those two things. Ideally, proper architecting of the Aparapi repos should
allow both source paths to occur, but someone needs to think through that
ahead-of-time. I am okay with adding you as an admin, but I will re-iterate
that we need to be careful of two things: 1) The entire code base does not
turn into a single use case, single operating system solution 2) If/when
your company is no longer functioning or working on Aparapi, the project
continues to remain viable for others. Also take note that none of the
issues at https://code.google.com/archive/p/aparapi/issues were migrated
to Github and many of those issues are still outstanding.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC5JAuNHx4k1NNy1mqAnQ5cRcAqDTxasks5q-4bTgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

From @rlamothe on November 17, 2016 0:43

Sure, I can add you as an admin, no problem. But why the push to become the sole maintainer/owner of the repo? I'm not sure what that gives you that being an admin does not.

[Jeffrey Phillips Freeman]

I don't wan't to be the sole maintaner, just the owner, I welcome other
maintainers to be a part of it.

The advantage for me personally is to see my company fund the project,
which means the project will accelerate faster. The advantage to the
company is branding. By making it an official project of the company, then
my company gains recognition should the project become popular down the
road.

So in short, the only real advantage to me and the project is funding that
I couldnt otherwise justify to the board if the project were owned by
someone else. There are no real functional advantages to it other than that.

On Wed, Nov 16, 2016 at 7:43 PM, rlamothe <[e-mail]

wrote:

Sure, I can add you as an admin, no problem. But why the push to become
the sole maintainer/owner of the repo? I'm not sure what that gives you
that being an admin does not.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC5JArz0BFdxaKF_3He9UrX7vMfTUqiQks5q-6McgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

From @grfrost on November 17, 2016 16:10

Hey Jeffery.

You may have mentioned it before, but can you tell me what company you are
referring to? Also what domain they work in?

Just curious really...

Gary

On Nov 16, 2016 16:47, "Jeffrey Phillips Freeman" [e-mail]
wrote:

I don't wan't to be the sole maintaner, just the owner, I welcome other
maintainers to be a part of it.

The advantage for me personally is to see my company fund the project,
which means the project will accelerate faster. The advantage to the
company is branding. By making it an official project of the company, then
my company gains recognition should the project become popular down the
road.

So in short, the only real advantage to me and the project is funding that
I couldnt otherwise justify to the board if the project were owned by
someone else. There are no real functional advantages to it other than
that.

On Wed, Nov 16, 2016 at 7:43 PM, rlamothe <
[e-mail]

wrote:

Sure, I can add you as an admin, no problem. But why the push to become
the sole maintainer/owner of the repo? I'm not sure what that gives you
that being an admin does not.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AC5JArz0BFdxaKF_
3He9UrX7vMfTUqiQks5q-6McgaJpZM4KYwLm>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEKiN9dLVDBHjHX73uZ1MWVj8ozpeP_Dks5q-6QwgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

Of course. Syncleus is the name of the company. It is a small company with
a large network of contractors to call on when needed. We make between one
and two million a year as a company (which isnt very much for a company).

We are int he Big Data and Machine Learning arena. Two of the most relevant
projects we host is Ferma, which is a ORM for graph databases (sometimes
called a OGM instead of an ORM), it is the fastest and most popular OGM
there is for java unless things have changed in the last few months, it
sits on top of Tinkerpop. The other project I mentioned is dANN (which has
since been renamed to GRAIL for its next release), that is a machine
learning library with hundreds of implemented algorithms and has been
active for over 11 years. We have a handful of other opensource projects
too on our github.

On Thu, Nov 17, 2016 at 11:10 AM, grfrost [e-mail] wrote:

Hey Jeffery.

You may have mentioned it before, but can you tell me what company you are
referring to? Also what domain they work in?

Just curious really...

Gary

On Nov 16, 2016 16:47, "Jeffrey Phillips Freeman" <
[e-mail]>
wrote:

I don't wan't to be the sole maintaner, just the owner, I welcome other
maintainers to be a part of it.

The advantage for me personally is to see my company fund the project,
which means the project will accelerate faster. The advantage to the
company is branding. By making it an official project of the company,
then
my company gains recognition should the project become popular down the
road.

So in short, the only real advantage to me and the project is funding
that
I couldnt otherwise justify to the board if the project were owned by
someone else. There are no real functional advantages to it other than
that.

On Wed, Nov 16, 2016 at 7:43 PM, rlamothe <
[e-mail]

wrote:

Sure, I can add you as an admin, no problem. But why the push to become
the sole maintainer/owner of the repo? I'm not sure what that gives you
that being an admin does not.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AC5JArz0BFdxaKF_
3He9UrX7vMfTUqiQks5q-6McgaJpZM4KYwLm>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AEKiN9dLVDBHjHX73uZ1MWVj8ozpeP_Dks5q-6QwgaJpZM4KYwLm>

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC5JAjy3eIWd2TUNa7fewsrB_VYesWoPks5q_HxwgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

From @rlamothe on November 18, 2016 18:0

Okay, so I think we all need to step back here for a second and actually dig into this a little deeper. First thing, when I start digging into Syncleus it appears to be a single employee corporation that is most likely an independent consulting venture, working on very small contracts over time. That by itself is perfectly fine, but when I peruse the Syncleus Github repository I see some projects that are either a copy or a fork of other efforts, but with the attributions removed. Take Aparapi for example, the Syncleus website lists Aparapi as its own effort, with no mention of its history or team. The Github repo itself is a copy of Aparapi, instead of a fork, that strips out most (all?) of the existing attributions and even licenses. I am not even sure that is legal. To me, this feels less like community building and more like a land-grab, in an effort to continue building the Syncleus small brand. This is exactly why I am against the BSD and MIT licenses. Before I give over some keys to the Aparapi castle, can you please address what I am seeing?

[Jeffrey Phillips Freeman]

Valid points. As I said Syncleus IS a small organization. Me, its board,
and two other executives make up the whole team. As I said we only pull in
1 - 2 million a year. So this was never hidden.

As for removing attributions. Aparapi was only added to the website a few
days ago shortly before grfrost responded. At the time it appeared that the
effort would be moved to us. Now that that is in question we are changing
the name.

Second as for removing attributions? Can you please tell me a single
example where attributions were removed? Every single project retains the
original contributors list, and full repo history is maintained. In most
cases however by looking at the commit history it should be apparent that
the vast majority of commits were by syncleus contributors (mostly me,
occasionally others as well). So these claims that the projects were simply
stolen and the attributions removed seem completely unfounded. Can you give
even a single example of that? Even with aparapi not a single attribution
was intentionally removed (and if you can show me an example where it was
it will be promptly re-added). Also when on the website does it say that it
was its "own effort" .. the website suggests only that it is one of the
projects in its portfolio and then when clicking the link it leads directly
to the repository that includes full attributions. Here is the direct link
if you doubt me:
https://github.com/Syncleus/aparapi/blob/master/CONTRIBUTORS.md

So I have to wonder were these faceless claims made just to defame the
effort and the company for personal reasons, or can you share some
legitimate examples of the accusations your making?

On Fri, Nov 18, 2016 at 1:00 PM, Ryan LaMothe [e-mail]
wrote:

Okay, so I think we all need to step back here for a second and actually
dig into this a little deeper. First thing, when I start digging into
Syncleus it appears to be a single employee corporation that is most likely
an independent consulting venture, working on very small contracts over
time. That by itself is perfectly fine, but when I peruse the Syncleus
Github repository I see some projects that are either a copy or a fork of
other efforts, but with the attributions removed. Take Aparapi for example,
the Syncleus website lists Aparapi as its own effort, with no mention of
its history or team. The Github repo itself is a copy of Aparapi, instead
of a fork, that strips out most (all?) of the existing attributions and
even licenses. I am not even sure that is legal. To me, this feels less
like community building and more like a land-grab, in an effort to continue
building the Syncleus small brand. This is exactly why I am against the BSD
and MIT licenses. Before I give over some keys to the Aparapi castle, can
you please address what I am seeing?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC5JAmmA3bsLlThWQCZpu2u7iQLynxrGks5q_eexgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

Also to further elaborate on the last point lets look at each project
posted that is active and listed on the site and then see if they fit your
claim that they are just forks of other projects with the attribution
changed:

https://github.com/Syncleus/Ferma - This project has over 400 commits and
the graph show the vast majority are from synceus, furthermore it is
apparent that none of the code pulled in from other projects are retained
in the current version. Despite this the names of contributors to that code
remain int he contributions section.

https://github.com/Syncleus/GRAIL-core - This project is completely started
and developed by Syncleus. So no one to attribute to, not forked or using
any other projects code.

https://github.com/Syncleus/peak - Pulls in some minor code from other
projects, though most of this code has since been heavily refactored out.
Despite this the git history remains and a contributors file remains
listing the contributions of anyone who added any code. As can be seen
again from the git graphs almost all of the work and commits on this
project came from within syncleus itself with the exception of only a
miority of contributions that occured under other projects (all of which
attributed).

https://github.com/Syncleus/apex - This project is a python varient of
peak. all the same applies, despite being a rewrite, contributor list was
maintained since those contributors at least gave inspiration.

https://github.com/Syncleus/kiss-tnc - This project was completely a
syncleus based project. But again since it pulled from the python varient
for inspiration (different language) contributors and attributions were
carried over, this usually isnt done in the OSS community.

https://github.com/Syncleus/dANN-core This project is about 11 years old
and it is obvious from the contributions graph that 99% of it was coded by
syncleus. The only package that pulls in any thing from a different source
is the matrix math package. That package is attributed int he header for
the 3 files that pulled it and the cntributors file also mentioned the
contributors for that section.

https://github.com/Syncleus/fusion-graph - This was a 100% syncleus effort,
no projects pulled in. Attributions given to contributors.

https://github.com/Syncleus/Ferma-recurse - Same as fusion-graph, this was
100% syncleus effort and attributions given.

So when I look at this list it is very hard for me to find any truth to the
accusations you just made. Now if you feel you can find some actual
examples, I will happy add the attribution anywhere you can find an example
one might have been overlooked. You will probably have a much better time
making a case if you provide actual evidence and examples when you make an
accusation rather than just accuse and hope everyone buys into it as fact.
I would also say most would consider it quite rude, but I do feel you had
the best of intentions, so I simply hope you can provide some evidence of
your claims.

On Fri, Nov 18, 2016 at 1:07 PM, Jeffrey Freeman [e-mail] wrote:

Valid points. As I said Syncleus IS a small organization. Me, its board,
and two other executives make up the whole team. As I said we only pull in
1 - 2 million a year. So this was never hidden.

As for removing attributions. Aparapi was only added to the website a few
days ago shortly before grfrost responded. At the time it appeared that the
effort would be moved to us. Now that that is in question we are changing
the name.

Second as for removing attributions? Can you please tell me a single
example where attributions were removed? Every single project retains the
original contributors list, and full repo history is maintained. In most
cases however by looking at the commit history it should be apparent that
the vast majority of commits were by syncleus contributors (mostly me,
occasionally others as well). So these claims that the projects were simply
stolen and the attributions removed seem completely unfounded. Can you give
even a single example of that? Even with aparapi not a single attribution
was intentionally removed (and if you can show me an example where it was
it will be promptly re-added). Also when on the website does it say that it
was its "own effort" .. the website suggests only that it is one of the
projects in its portfolio and then when clicking the link it leads directly
to the repository that includes full attributions. Here is the direct link
if you doubt me: https://github.com/Syncleus/aparapi/blob/master/
CONTRIBUTORS.md

So I have to wonder were these faceless claims made just to defame the
effort and the company for personal reasons, or can you share some
legitimate examples of the accusations your making?

On Fri, Nov 18, 2016 at 1:00 PM, Ryan LaMothe [e-mail]
wrote:

Okay, so I think we all need to step back here for a second and actually
dig into this a little deeper. First thing, when I start digging into
Syncleus it appears to be a single employee corporation that is most likely
an independent consulting venture, working on very small contracts over
time. That by itself is perfectly fine, but when I peruse the Syncleus
Github repository I see some projects that are either a copy or a fork of
other efforts, but with the attributions removed. Take Aparapi for example,
the Syncleus website lists Aparapi as its own effort, with no mention of
its history or team. The Github repo itself is a copy of Aparapi, instead
of a fork, that strips out most (all?) of the existing attributions and
even licenses. I am not even sure that is legal. To me, this feels less
like community building and more like a land-grab, in an effort to continue
building the Syncleus small brand. This is exactly why I am against the BSD
and MIT licenses. Before I give over some keys to the Aparapi castle, can
you please address what I am seeing?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC5JAmmA3bsLlThWQCZpu2u7iQLynxrGks5q_eexgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

Just want to say one final thing. Sorry if my last email sounded
antagonistic. I reread it and saw it may come across this way. My apologies
if you felt this way as well, it wasnt my intention. I do sincerely hope
any valid concerns you can point out will be fixed but I suspect for the
most part they seem unfounded. I could be mistaken. Mostly just sorry if my
tone didnt convey that.

Also one final note. Please share with me where the current version of the
Aparapi repo strips out any attribution? It does move the license over to
the MIT license (which my lawyers said is compatible with the Aparapi
license). Though I do agree the old license needs mention somewhere. We do
need to add a remark somewhere that indicates the license changed. Which I
will work on today, because that has been bugging me anyway. But other than
that one minor point I cant see where you have any examples of a single
contributor being removed. Full contributor list is maintained in the repo
with all original contributors.

Second to your point of forking on GitHub vs a copy of the repo. That is
actual standard practice anytime a repo is going to diverge from the
original. The point of forks is to submit pull requests. As two projects
diverge from each other by having it as a fork rather than a distinct
project causes a multitude of minor issues. It is NOT standard practice if
you are going to maintain your own divergent version of a project that you
do so as a github fork. For good reason. However you will notice we DID
follow standard practices in the sense that we retained the entire github
history so there is no hiding where the code came from or just how much any
of your contributed. All of this is standard practice.

On Fri, Nov 18, 2016 at 1:17 PM, Jeffrey Freeman [e-mail] wrote:

Also to further elaborate on the last point lets look at each project
posted that is active and listed on the site and then see if they fit your
claim that they are just forks of other projects with the attribution
changed:

https://github.com/Syncleus/Ferma - This project has over 400 commits and
the graph show the vast majority are from synceus, furthermore it is
apparent that none of the code pulled in from other projects are retained
in the current version. Despite this the names of contributors to that code
remain int he contributions section.

https://github.com/Syncleus/GRAIL-core - This project is completely
started and developed by Syncleus. So no one to attribute to, not forked or
using any other projects code.

https://github.com/Syncleus/peak - Pulls in some minor code from other
projects, though most of this code has since been heavily refactored out.
Despite this the git history remains and a contributors file remains
listing the contributions of anyone who added any code. As can be seen
again from the git graphs almost all of the work and commits on this
project came from within syncleus itself with the exception of only a
miority of contributions that occured under other projects (all of which
attributed).

https://github.com/Syncleus/apex - This project is a python varient of
peak. all the same applies, despite being a rewrite, contributor list was
maintained since those contributors at least gave inspiration.

https://github.com/Syncleus/kiss-tnc - This project was completely a
syncleus based project. But again since it pulled from the python varient
for inspiration (different language) contributors and attributions were
carried over, this usually isnt done in the OSS community.

https://github.com/Syncleus/dANN-core This project is about 11 years old
and it is obvious from the contributions graph that 99% of it was coded by
syncleus. The only package that pulls in any thing from a different source
is the matrix math package. That package is attributed int he header for
the 3 files that pulled it and the cntributors file also mentioned the
contributors for that section.

https://github.com/Syncleus/fusion-graph - This was a 100% syncleus
effort, no projects pulled in. Attributions given to contributors.

https://github.com/Syncleus/Ferma-recurse - Same as fusion-graph, this
was 100% syncleus effort and attributions given.

So when I look at this list it is very hard for me to find any truth to
the accusations you just made. Now if you feel you can find some actual
examples, I will happy add the attribution anywhere you can find an example
one might have been overlooked. You will probably have a much better time
making a case if you provide actual evidence and examples when you make an
accusation rather than just accuse and hope everyone buys into it as fact.
I would also say most would consider it quite rude, but I do feel you had
the best of intentions, so I simply hope you can provide some evidence of
your claims.

On Fri, Nov 18, 2016 at 1:07 PM, Jeffrey Freeman [e-mail] wrote:

Valid points. As I said Syncleus IS a small organization. Me, its board,
and two other executives make up the whole team. As I said we only pull in
1 - 2 million a year. So this was never hidden.

As for removing attributions. Aparapi was only added to the website a few
days ago shortly before grfrost responded. At the time it appeared that the
effort would be moved to us. Now that that is in question we are changing
the name.

Second as for removing attributions? Can you please tell me a single
example where attributions were removed? Every single project retains the
original contributors list, and full repo history is maintained. In most
cases however by looking at the commit history it should be apparent that
the vast majority of commits were by syncleus contributors (mostly me,
occasionally others as well). So these claims that the projects were simply
stolen and the attributions removed seem completely unfounded. Can you give
even a single example of that? Even with aparapi not a single attribution
was intentionally removed (and if you can show me an example where it was
it will be promptly re-added). Also when on the website does it say that it
was its "own effort" .. the website suggests only that it is one of the
projects in its portfolio and then when clicking the link it leads directly
to the repository that includes full attributions. Here is the direct link
if you doubt me: https://github.com/Syncleus/aparapi/blob/master/CONTRIBU
TORS.md

So I have to wonder were these faceless claims made just to defame the
effort and the company for personal reasons, or can you share some
legitimate examples of the accusations your making?

On Fri, Nov 18, 2016 at 1:00 PM, Ryan LaMothe [e-mail]
wrote:

Okay, so I think we all need to step back here for a second and actually
dig into this a little deeper. First thing, when I start digging into
Syncleus it appears to be a single employee corporation that is most likely
an independent consulting venture, working on very small contracts over
time. That by itself is perfectly fine, but when I peruse the Syncleus
Github repository I see some projects that are either a copy or a fork of
other efforts, but with the attributions removed. Take Aparapi for example,
the Syncleus website lists Aparapi as its own effort, with no mention of
its history or team. The Github repo itself is a copy of Aparapi, instead
of a fork, that strips out most (all?) of the existing attributions and
even licenses. I am not even sure that is legal. To me, this feels less
like community building and more like a land-grab, in an effort to continue
building the Syncleus small brand. This is exactly why I am against the BSD
and MIT licenses. Before I give over some keys to the Aparapi castle, can
you please address what I am seeing?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC5JAmmA3bsLlThWQCZpu2u7iQLynxrGks5q_eexgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

Please file an issue report on any of the Syncleus projects where you see
attribution is missing or something about it is misleading. Any valid
issues will be addressed and rectified.

On Fri, Nov 18, 2016 at 1:34 PM, Jeffrey Freeman [e-mail] wrote:

Just want to say one final thing. Sorry if my last email sounded
antagonistic. I reread it and saw it may come across this way. My apologies
if you felt this way as well, it wasnt my intention. I do sincerely hope
any valid concerns you can point out will be fixed but I suspect for the
most part they seem unfounded. I could be mistaken. Mostly just sorry if my
tone didnt convey that.

Also one final note. Please share with me where the current version of the
Aparapi repo strips out any attribution? It does move the license over to
the MIT license (which my lawyers said is compatible with the Aparapi
license). Though I do agree the old license needs mention somewhere. We do
need to add a remark somewhere that indicates the license changed. Which I
will work on today, because that has been bugging me anyway. But other than
that one minor point I cant see where you have any examples of a single
contributor being removed. Full contributor list is maintained in the repo
with all original contributors.

Second to your point of forking on GitHub vs a copy of the repo. That is
actual standard practice anytime a repo is going to diverge from the
original. The point of forks is to submit pull requests. As two projects
diverge from each other by having it as a fork rather than a distinct
project causes a multitude of minor issues. It is NOT standard practice if
you are going to maintain your own divergent version of a project that you
do so as a github fork. For good reason. However you will notice we DID
follow standard practices in the sense that we retained the entire github
history so there is no hiding where the code came from or just how much any
of your contributed. All of this is standard practice.

On Fri, Nov 18, 2016 at 1:17 PM, Jeffrey Freeman [e-mail] wrote:

Also to further elaborate on the last point lets look at each project
posted that is active and listed on the site and then see if they fit your
claim that they are just forks of other projects with the attribution
changed:

https://github.com/Syncleus/Ferma - This project has over 400 commits
and the graph show the vast majority are from synceus, furthermore it is
apparent that none of the code pulled in from other projects are retained
in the current version. Despite this the names of contributors to that code
remain int he contributions section.

https://github.com/Syncleus/GRAIL-core - This project is completely
started and developed by Syncleus. So no one to attribute to, not forked or
using any other projects code.

https://github.com/Syncleus/peak - Pulls in some minor code from other
projects, though most of this code has since been heavily refactored out.
Despite this the git history remains and a contributors file remains
listing the contributions of anyone who added any code. As can be seen
again from the git graphs almost all of the work and commits on this
project came from within syncleus itself with the exception of only a
miority of contributions that occured under other projects (all of which
attributed).

https://github.com/Syncleus/apex - This project is a python varient of
peak. all the same applies, despite being a rewrite, contributor list was
maintained since those contributors at least gave inspiration.

https://github.com/Syncleus/kiss-tnc - This project was completely a
syncleus based project. But again since it pulled from the python varient
for inspiration (different language) contributors and attributions were
carried over, this usually isnt done in the OSS community.

https://github.com/Syncleus/dANN-core This project is about 11 years old
and it is obvious from the contributions graph that 99% of it was coded by
syncleus. The only package that pulls in any thing from a different source
is the matrix math package. That package is attributed int he header for
the 3 files that pulled it and the cntributors file also mentioned the
contributors for that section.

https://github.com/Syncleus/fusion-graph - This was a 100% syncleus
effort, no projects pulled in. Attributions given to contributors.

https://github.com/Syncleus/Ferma-recurse - Same as fusion-graph, this
was 100% syncleus effort and attributions given.

So when I look at this list it is very hard for me to find any truth to
the accusations you just made. Now if you feel you can find some actual
examples, I will happy add the attribution anywhere you can find an example
one might have been overlooked. You will probably have a much better time
making a case if you provide actual evidence and examples when you make an
accusation rather than just accuse and hope everyone buys into it as fact.
I would also say most would consider it quite rude, but I do feel you had
the best of intentions, so I simply hope you can provide some evidence of
your claims.

On Fri, Nov 18, 2016 at 1:07 PM, Jeffrey Freeman [e-mail]
wrote:

Valid points. As I said Syncleus IS a small organization. Me, its board,
and two other executives make up the whole team. As I said we only pull in
1 - 2 million a year. So this was never hidden.

As for removing attributions. Aparapi was only added to the website a
few days ago shortly before grfrost responded. At the time it appeared that
the effort would be moved to us. Now that that is in question we are
changing the name.

Second as for removing attributions? Can you please tell me a single
example where attributions were removed? Every single project retains the
original contributors list, and full repo history is maintained. In most
cases however by looking at the commit history it should be apparent that
the vast majority of commits were by syncleus contributors (mostly me,
occasionally others as well). So these claims that the projects were simply
stolen and the attributions removed seem completely unfounded. Can you give
even a single example of that? Even with aparapi not a single attribution
was intentionally removed (and if you can show me an example where it was
it will be promptly re-added). Also when on the website does it say that it
was its "own effort" .. the website suggests only that it is one of the
projects in its portfolio and then when clicking the link it leads directly
to the repository that includes full attributions. Here is the direct link
if you doubt me: https://github.com/Syncleu
s/aparapi/blob/master/CONTRIBUTORS.md

So I have to wonder were these faceless claims made just to defame the
effort and the company for personal reasons, or can you share some
legitimate examples of the accusations your making?

On Fri, Nov 18, 2016 at 1:00 PM, Ryan LaMothe [e-mail]
wrote:

Okay, so I think we all need to step back here for a second and
actually dig into this a little deeper. First thing, when I start digging
into Syncleus it appears to be a single employee corporation that is most
likely an independent consulting venture, working on very small contracts
over time. That by itself is perfectly fine, but when I peruse the Syncleus
Github repository I see some projects that are either a copy or a fork of
other efforts, but with the attributions removed. Take Aparapi for example,
the Syncleus website lists Aparapi as its own effort, with no mention of
its history or team. The Github repo itself is a copy of Aparapi, instead
of a fork, that strips out most (all?) of the existing attributions and
even licenses. I am not even sure that is legal. To me, this feels less
like community building and more like a land-grab, in an effort to continue
building the Syncleus small brand. This is exactly why I am against the BSD
and MIT licenses. Before I give over some keys to the Aparapi castle, can
you please address what I am seeing?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC5JAmmA3bsLlThWQCZpu2u7iQLynxrGks5q_eexgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

From @george-hawkins on November 23, 2016 20:32

My 2 cents:

@rlamothe have talked about what they hoped for for this project - that it would be maintained by a group of committers who formed the heart of a vibrant community.

That would be lovely - but it hasn't been achieved. There may be multiple committers but they are not committing - we can see from the nice Github charts that development peaked in 2013 and things have been fairly quiet since (other than a blip in 2015 which seems to be largely the work of @mibrahim working on documentation and fixing up code formatting).

The project is essentially moribund. So I think you can't defend the status quo on the basis of what you hoped would happen but didn't. I think @rlamothe should acknowledge this situation - and decide what to do next.

What should that be?

@freemo has proposed giving over control of the repository to him (rather than simply making him an additional committer on the project).

He has explained his reasons for wanting this arrangement - whether they're reasonable is up for discussion.

An alternative to either giving up control to him or adding him as a committer might be to clearly state at the start of the README for the aparapi/aparapi project that this project is no longer being actively developed but an actively maintained fork can be found at Syncleus/aparapi.

This way you've given up no control - you can remove the line if the Syncleus fork goes stale or you decide to take up active development again - but in the meantime you provide a clear pointer for people to a fork that at the moment seems to be going places while the original aparapi repo, due to time or other constraints on the current committers, is essentially inactive.

Finally points:

1. @rlamothe made some very serious accusation against @freemo in his last comment. Perhaps he didn't mean things to come across that way but if what he says were true it would reflect very badly on @freemo. @freemo appears to have repudiated these accusations so I think @rlamothe must either back up his accusations, with clear links and examples, or withdraw them. To leave unsubstantiated accusations of this nature just sitting there is, I think, bad form.

2. The original author @grfrost reacted very positively to @freemo's original message but did bring up licenses:

My only caution would be the relicensing under Apache, I am not a lawyer but you might need AMD's permission to do that.

Licensing also comes up in a number of other messages and @freemo says:

It does move the license over to the MIT license (which my lawyers said is compatible with the Aparapi license). Though I do agree the old license needs mention somewhere. We do need to add a remark somewhere that indicates the license changed. Which I will work on today, because that has been bugging me anyway.

That update hasn't happened yet (the last commit still shows as Oct 18, 2016). When it does happen I think it should not only comment that a change in license occurred but it should also include a link to something confirming the lawyers claim as to compatibility between the licenses - there's presumably no end of material on the web as to what OS licenses are or are not compatible with each other and on whether one can or cannot easily switch the licensing of a project from one particular license to another.

[Jeffrey Phillips Freeman]

I just wanted to add that after @george-hawkins post we added back some text referencing the original license for transparency. We wanted to do this in a separate file (as the readme is usually reserved for important quick-start type information). So do expect the location of this notice to change. But in the short term I felt it was important to get the notice out there as quick as possible rather than waiting on this debate to be resolved (and thus allowing Syncleus development of aparapi to continue). But you can now find the original license text int he README for all 3 aparapi derived repositories. Hopefully this should help alleviate any fears in the short term.

In the long term I am waiting to publish aparapi.com until there is some resolution here (as I want to make sure the community as a whole is happy with the direction). But once we resolve these issues I can address the excellent idea of also producing an official statement from our lawyers regarding the compatibility of the licenses (and welcome any concerns that may arise from this as part of the debate of course). Also as a side note, it appears I mistakenly said the MIT license, when I meant to say the Apache License.

I would hope I could continue to pursue the vision of @rlamothe when it comes to making this project community driven with a network of interested contributors. I also hope everyone who has an interest (including the current owners) would continue to have an important role in the community moving forward.

[Jeffrey Phillips Freeman]

From @rlamothe on November 28, 2016 15:25

Hope everyone had a wonderful Thanksgiving. Back to the real-world now. Once again, let's step back and take another look at this thread, addressing each point individually. Ideally we can put this thread to rest.

1. How to become an Aparapi core contributor: I did not become the project owner of Aparapi on GitHub overnight. If you study the history of Aparapi, multiple teams that I led spent a number of years and tens of thousands of dollars working with Gary and AMD testing Aparapi, contributing issue tickets, submitting critical code, supporting major refactoring efforts, presenting results at technical conferences (see the correlation-matrix sub-project) and generally being an engaged long-term member of the Aparapi community. I also helped AMD kick-off OpenJDK’s Project Sumatra, found at https://wiki.openjdk.java.net/display/Sumatra/Main, which was intended to be the successor of Aparapi. You can see remnants of the initial Sumatra work in the Lambda branch of the Aparapi GitHub repository. As history would have it, AMD was unable to continue financial support of both Aparapi and Sumatra. Fortunately, Aparapi had an existing community behind it, whereas Sumatra is no longer active. Syncleus on the other hand, has made zero Aparapi pull requests, submitted zero bug fixes, submitted zero feature enhancements, has put no effort whatsoever into building a long-term relationship with the existing Aparapi community or with me and yet creates this thread wanting to take over ownership of this effort? If Syncleus wants to become a core contributor to Aparapi or any other open source project, then Syncleus needs to reconsider how it engages with the open source community and how it can commit code to project’s that it does not own to further it’s own means. That type of behavior can be a win-win for everyone.
2. Syncleus work without attribution/questionable behavior: There are a number of things right off the bat that are extremely troubling about Syncleus’s behavior. On the surface, this page http://syncleus.com/projects.html makes Aparapi appear to be one of Syncleus’s very own projects, instead of an existing open source project. Digging a little deeper, Syncleus’s version of Aparapi located at https://github.com/Syncleus/aparapi is a copy, not a fork, of the existing Aparapi GitHub code base. Therefore, it is clear that there was never any intention of becoming a contributor to the original effort. Digging even deeper, within the Syncleus Aparapi copy there is a lot of pre-meditated effort, that clearly belies Syncleus’s true intentions. For example, Syncleus performed a global find/replace of AMD with Syncleus, including within existing documents, inline code, comments, package names, etc. Although I-Am-Not-A-Lawyer it also seems particularly brazen of Syncleus to simply rip out via global find/replace all existing licenses and copyrights, replacing them with Apache licenses and “Copyright (c) 2016 - 2017 Syncleus, Inc.”. Syncleus also removed all existing test and example code, conveniently removing anything that was not license compatible with Apache or where copyright could not be conveniently replaced with Syncleus’s own copyright. Syncleus then proceeded to remove the existing web page content, gutted the README file, and worst of all removed all credit of work performed by existing and historical Aparapi contributors such this deletion e41c4d0#diff-ec6b233a4376469c2d28e2f18a4a7f98. All of this without a single communication attempt to the existing Aparapi community or project owner. I can continue working through all of Syncleus’s GitHub commits one-by-one, but you get the idea. In academic circles this would look like plagiarism, in the business world it looks like either an attempted theft, a possible hostile takeover attempt, or similar.
3. Failed community: I would like to point out that the existing Aparapi community is neither a failure nor is it dead. In addition to the code commits mentioned above, the Aparapi Google mailing list is alive and well (albeit relatively low traffic), but has a lot of interesting bug fix suggestions and experimental code discussions that spike from time to time. You should give it a try. The Aparapi project itself has had 12 contributors between Google Code and GitHub, with the newest contributors arriving via GitHub. There are currently a number of active GitHub tickets right now. The reason for Aparapi’s initially slow contributor rate was essentially two-fold: First, Aparapi was initially owned and controlled by AMD who necessarily limited outside contributions and, Second during the Google Code years most folks had made a copy of Aparapi to GitHub and didn’t have a reasonable way to contribute code changes between the two environments. Finally, the primary challenge with any open source effort is one of actual external code commits. There are always a few core contributors, but everyone else essentially files bug reports, raises concerns, criticizes, etc. and only a very few people ever pull down the code, spend the time to track down and fix a bug/implement a feature, write tests, etc. and then submit a pull request back to the trunk. Even when that happens, most people have turned out to be casual observers or students, so usually do not commit more than once or twice. As for the time it takes to accept commits, all Pull requests have been accepted within a reasonable amount of time, and currently there is only a single outstanding Pull request, which contains both a minor code fix and a complete code tree refactor with partial Maven support in a single commit. That request has taken more time to accept. As always, both paid and volunteer contributions are welcome.
4. Syncleus wants to take over ownership: Short answer; No. Long answer; Syncleus has a choice, they can either become healthy active members of the existing Aparapi community and begin building a long-term relationship and trust with me via acceptable code commits and involvement or Syncleus can effectively steal the project and go on their merry way. The second choice would obviously be undesirable and I will make sure that this thread becomes as publically visible as possible, to alert others to the history of why there are two Aparapi projects. As I previously discussed in a different reply, it is unacceptable to refactor the entire Aparapi tree in a way that only supports a single use case, a single operating system, and guts all of the existing examples/integration tests while providing no testing whatsoever on non-Linux platforms. I do understand the need to create a Maven build of Aparapi, but it was blocked by AMD in the past, due to the Lambda and Sumatra work which is now unblocked. In the end, while Aparapi has a lot of interesting features, if all you plan to support is a single use case on Linux why not just use JOCL and/or JCUDA instead?

How can we move forward together?

[Jeffrey Phillips Freeman]

From @george-hawkins on November 28, 2016 15:40

Thanks for a long and considered answer. The points are all well made. It was unfair of me to describe the project as "moribund" - it's such a substantial and interesting piece of work that I guess I just feel sorry to see that it's not being more actively developed. But lack of large scale active development is not a good enough reason to hand over the project to just anyone. It seems to be the unfortunate fate of many OpenCL projects for Java (and other JVM based languages) that they often seem to go quiet after an initial significant development effort.

[Jeffrey Phillips Freeman]

I will likewise address each of your points.

1. No one is trying to undervalue your contributions. So let me be clear in
   saying your contributions are both appreciated and respected. No one is
   saying you don't have the respect of the community. The issue has more to
   do with the fact that the project has been largely idle and you yourself
   indicated you had very limited time to contribute. As for Syncleus needing
   to prove itself to the Aparapi community, that comes with time, however
   even our initial commits have accomplished a significant leap forward in an
   otherwise stagnant community with regards to how the files are packaged
   (maven and libtools). Is that enough to "earn your respect", well no, nor
   do I expect it to be. Our goal is to make the project useful for our own
   needs, as well as the needs of others. Hopefully in doing so we can win
   your respect as well, but that is not the driving force here.

2. This point seems to lack a basic understanding of how these things tend
   to work, in fact MUST work. First off the projects listed on the site are
   the project we "own" in the sense that we maintain, distribute, serve, and
   invest in the project. Being open-source it is NOT intended to imply we are
   the sole developers or even the creators of such a project. This is very
   common practice in the open-source community for the "owner" of a project
   to cite it on their page, assuming the project retains the list of
   contrbutors, which we do. Now granted since you intend to keep stewardship
   over the project we will have to consider a new name for the project.
   Consider for example the project list on the Apache website. Most of those
   projects were started by other companies and individuals and adopted by
   apache later on, despite this they are still listed on the main page in the
   same way we do. Tinkerpop is a prime example of this, for years version 1
   and 2 were independent projects but version 3 moved to the Apache umbrella
   and is now listed as an apache project. Open-source is specifically for
   this very purpose, so people can freely modify work and incorporate it into
   their own efforts.

Next lets address the "global find replace", specifically package naming.
Not only is this REQUIRED but it is illegal NOT to do this. Anyone who has
ever published a project to maven central knows you can only obtain
permission to publish to package names you are the owner of. Essentially no
one except AMD company can publish any packages to maven central under the
"com.amd" package. This means if you EVER hope to actually publish this
project so as to allow it to be consumed and used in other projects you
MUST change this. To not do so implies you are acting on behalf of AMD
which is of course illegal. Thus why we changed it to "com.syncleus", this
is a domain in the maven central repository we actually have permission to
push to.

Also as for copyright notices we did NOT change any existing copyright
notices, we did however add our own. Which is also both legally expected
and a good thing to do. Each developer of a project should add their own
copyright to the mix, the key is not to delete any existing ones. The
original license is retained, and the AMD copyright notice in that license
is also retains. The new license contains the syncleus copyright notice,
exactly how it is suppose to when relicensing (so long as the old license
and old copyright notice are also included, which they are). Now do you
have any examples of where we actually REMOVED a copyright notice? Or is
your complaint simply that we added our own in addition?

As per the link you provided where you seem to feel the credit of work was
deleted. Is that because we changed the credits.txt file to a
Contributors.md file and reduced it to names of people contributed without
the full description next to each name? The descriptions were added back to
the contributors file. But considering none of the names were removed from
the list that strikes me as a rather minor edit (since those details are
better reflected in the github history). But I'm happy to add that back
since it appears to be a point of contention for you. Overall seems to be
an extremely minor concern however. To call it plagiarism is absurd, no
ones name was removed from the contributor file, just didnt seem the place
for long descriptions of what everyone did considering the list will get
excessively long over time. Also when you list the contributors to call it
plagerism is just not accurate. Regardless, as i said the descriptions have
been added back.

The readme and webpage were intentionally gutted because the information
was outdated and hasnt been updated in over 5 years. Both of these will be
completely rewritten as a result.

Finally your comment regarding examples is simply untrue. We retained all
the current examples and even converted them all to maven:
https://github.com/Syncleus/aparapi-examples

3. When I came upon the project with the intention of using it as a base in
   our own frameworks it was quickly evident the project was dead or at least
   dieing. Consider the following points.

• Despite being many years old not a single release was ever made.
• Still used antiquated ant making it very difficult or even impossible for
  any modern day project to use the library.
• Very little actual commits took place, the last one being 6 months ago
  and rather minimal at that.
• Even aparapi.com was still available to be registered

Long story short, despite any discussions on the mailing list (indicating
people have an interest in the project) its development was effectively
dead and its accomplishments over its lifetime seem to demonstrate this.
Especially considering how trivial many of the above points were to
correct. It took me only a day to convert the full project to maven, get a
release on maven central, package the binary to compile across multiple
platforms. On top of that we obtained the domain name aparapi.com as well
as all the variants on the other extensions (.net, .org, .io, .info, etc
and plan to publish a website there soon).

4. We welcome this thread to become public. I stated multiple times that if
   you decided for us not to take over the project then we would change the
   name out of respect. But considering your attitude in all this I can see
   working together isnt going to happen. My original intention if that were
   to happen was to donate the domain names to you and continue on a separate
   fork. But considering your response I will no longer be doing that, and
   continue to use aparapi name since we received the blessing of the original
   developer to do so (and I can see why seeing how you handled this
   discussion). Furthermore it is important to note that the new Aparapi will
   NOT support a single use case, nor does it currently do so. It is true it
   is currently untested on windows, however the new packaging was picked
   specifically because it is platform independent. Meaning it should
   currently work on windows and we intend to continue to support that. The
   new Aparapi will NOT be a single use case scenario, which is exactly why
   funding the project will be needed, to ensure it is fully tested under
   windows as well.

Please be aware that while the AMD license originally used is compatible
with the Apache license I can not promise the reverse is true (that new
work done under the apache license can be merged back into your project).
You will have to consult your own lawyers. Therefore it will be legal for
us to merge in any future commits from your project into ours, but not
necessarily legal for you to merge in our edits back into your own.
Normally I would be happy to grant a dual licensing exception to make this
possible. But again since your attitude seems mostly divisive without any
real justification this makes me less likely to want to work with you or to
do anything that might give your project an advantage moving forward. This
is a shame because I entered this conversation hoping to work together and
even saying i would have been happy to join your project instead if you
could ensure the pace of the project would move forward. But obviously if
you intentionally claim you will put every effort forward to defame us I
cant in good conscious contribute. I have fully copied this thread to
ensure when you do make it publicly visible you do not alter the facts to
your liking, we will similarly publish this thread on our own page,
including the endorsements of the original authors.

I just want to reiterate that I'm not sure where you got the idea we only
intend to support a single use case however. As I stated multiple times if
we adopt the project then we intend to support ALL use cases including
windows. We also intend to invest considerable money to ensure that
happens. If I were to contribute time to your project, however, then that
is simply your obligation, not mine (as i wouldnt have the resources of a
company to do so).

In the end Syncleus has its answer. We will continue development starting
this month, and publish this thread (which includes the blessings of the
original developer). As development continues and the Syncleus version
excels well past this particular fork I am confident the community will
back the more mature product that has the better license as well as owns
the domain name, and is capable of publishing to maven central; all of
which mean your particular project will be on the loosing side. I really
would have rather worked together, but if your goal is to unfairly defame
my own company and project, then clearly you have made this impossible.

On Mon, Nov 28, 2016 at 10:26 AM, Ryan LaMothe [e-mail]
wrote:

Hope everyone had a wonderful Thanksgiving. Back to the real-world now.
Once again, let's step back and take another look at this thread,
addressing each point individually. Ideally we can put this thread to rest.

1. How to become an Aparapi core contributor: I did not become the
   project owner of Aparapi on GitHub overnight. If you study the history of
   Aparapi, multiple teams that I led spent a number of years and tens of
   thousands of dollars working with Gary and AMD testing Aparapi,
   contributing issue tickets, submitting critical code, supporting major
   refactoring efforts, presenting results at technical conferences (see the
   correlation-matrix sub-project) and generally being an engaged long-term
   member of the Aparapi community. I also helped AMD kick-off OpenJDK’s
   Project Sumatra, found at https://wiki.openjdk.java.net/
   display/Sumatra/Main, which was intended to be the successor of
   Aparapi. You can see remnants of the initial Sumatra work in the Lambda
   branch of the Aparapi GitHub repository. As history would have it, AMD was
   unable to continue financial support of both Aparapi and Sumatra.
   Fortunately, Aparapi had an existing community behind it, whereas Sumatra
   is no longer active. Syncleus on the other hand, has made zero Aparapi pull
   requests, submitted zero bug fixes, submitted zero feature enhancements,
   has put no effort whatsoever into building a long-term relationship with
   the existing Aparapi community or with me and yet creates this thread
   wanting to take over ownership of this effort? If Syncleus wants to become
   a core contributor to Aparapi or any other open source project, then
   Syncleus needs to reconsider how it engages with the open source community
   and how it can commit code to project’s that it does not own to further
   it’s own means. That type of behavior can be a win-win for everyone.
2. Syncleus work without attribution/questionable behavior: There are
   a number of things right off the bat that are extremely troubling about
   Syncleus’s behavior. On the surface, this page
   http://syncleus.com/projects.html http://syncleus.com/projects.html
   makes Aparapi appear to be one of Syncleus’s very own projects, instead of
   an existing open source project. Digging a little deeper, Syncleus’s
   version of Aparapi located at https://github.com/Syncleus/aparapi is a
   copy, not a fork, of the existing Aparapi GitHub code base. Therefore, it
   is clear that there was never any intention of becoming a contributor to
   the original effort. Digging even deeper, within the Syncleus Aparapi copy
   there is a lot of pre-meditated effort, that clearly belies Syncleus’s true
   intentions. For example, Syncleus performed a global find/replace of AMD
   with Syncleus, including within existing documents, inline code, comments,
   package names, etc. Although I-Am-Not-A-Lawyer it also seems particularly
   brazen of Syncleus to simply rip out via global find/replace all existing
   licenses and copyrights, replacing them with Apache licenses and “Copyright
   (c) 2016 - 2017 Syncleus, Inc.”. Syncleus also removed all existing test
   and example code, conveniently removing anything that was not license
   compatible with Apache or where copyright could not be conveniently
   replaced with Syncleus’s own copyright. Syncleus then proceeded to remove
   the existing web page content, gutted the README file, and worst of all
   removed all credit of work performed by existing and historical Aparapi
   contributors such this deletion e41c4d0#diff-
   ec6b233a4376469c2d28e2f18a4a7f98
   e41c4d0#diff-ec6b233a4376469c2d28e2f18a4a7f98.
   All of this without a single communication attempt to the existing Aparapi
   community or project owner. I can continue working through all of
   Syncleus’s GitHub commits one-by-one, but you get the idea. In academic
   circles this would look like plagiarism, in the business world it looks
   like either an attempted theft, a possible hostile takeover attempt, or
   similar.
3. Failed community: I would like to point out that the existing
   Aparapi community is neither a failure nor is it dead. In addition to the
   code commits mentioned above, the Aparapi Google mailing list is alive and
   well (albeit relatively low traffic), but has a lot of interesting bug fix
   suggestions and experimental code discussions that spike from time to time.
   You should give it a try. The Aparapi project itself has had 12
   contributors between Google Code and GitHub, with the newest contributors
   arriving via GitHub. There are currently a number of active GitHub tickets
   right now. The reason for Aparapi’s initially slow contributor rate was
   essentially two-fold: First, Aparapi was initially owned and controlled by
   AMD who necessarily limited outside contributions and, Second during the
   Google Code years most folks had made a copy of Aparapi to GitHub and
   didn’t have a reasonable way to contribute code changes between the two
   environments. Finally, the primary challenge with any open source effort is
   one of actual external code commits. There are always a few core
   contributors, but everyone else essentially files bug reports, raises
   concerns, criticizes, etc. and only a very few people ever pull down the
   code, spend the time to track down and fix a bug/implement a feature, write
   tests, etc. and then submit a pull request back to the trunk. Even when
   that happens, most people have turned out to be casual observers or
   students, so usually do not commit more than once or twice. As for the time
   it takes to accept commits, all Pull requests have been accepted within a
   reasonable amount of time, and currently there is only a single outstanding
   Pull request, which contains both a minor code fix and a complete code tree
   refactor with partial Maven support in a single commit. That request has
   taken more time to accept. As always, both paid and volunteer contributions
   are welcome.
4. Syncleus wants to take over ownership: Short answer; No. Long
   answer; Syncleus has a choice, they can either become healthy active
   members of the existing Aparapi community and begin building a long-term
   relationship and trust with me via acceptable code commits and involvement
   or Syncleus can effectively steal the project and go on their merry way.
   The second choice would obviously be undesirable and I will make sure that
   this thread becomes as publically visible as possible, to alert others to
   the history of why there are two Aparapi projects. As I previously
   discussed in a different reply, it is unacceptable to refactor the entire
   Aparapi tree in a way that only supports a single use case, a single
   operating system, and guts all of the existing examples/integration tests
   while providing no testing whatsoever on non-Linux platforms. I do
   understand the need to create a Maven build of Aparapi, but it was blocked
   by AMD in the past, due to the Lambda and Sumatra work which is now
   unblocked. In the end, while Aparapi has a lot of interesting features, if
   all you plan to support is a single use case on Linux why not just use JOCL
   and/or JCUDA instead?

How can we move forward together?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
aparapi/aparapi#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC5JAvEGmTGlcpw7QCvBDUC-BVKq9tPXks5rCvKIgaJpZM4KYwLm
.

[Jeffrey Phillips Freeman]

For the record we addressed the one valid concern you brought up with regards to attribution. The full description of contributions that were replaced by a simplified list now have the full descriptions added back. This should satisfy all legitimate concerns you have regarding attribution. If you can find any others please let me know:

729a036

[Jeffrey Phillips Freeman]

Also we reviewed the claim regarding copyright notices. As can be clearly seen ALL files retain both the original header and original AMD copyright notice, as well as adds the new license header and new copyright notice (both of which are considered good practice when relicensing software). The following is an example from one of the files ( https://github.com/Syncleus/aparapi/blob/master/src/main/java/com/syncleus/aparapi/Config.java ):

/**
 * Copyright (c) 2016 - 2017 Syncleus, Inc.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
/*
Copyright (c) 2010-2011, Advanced Micro Devices, Inc.
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer. 

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with the distribution. 

Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission. 

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

If you use the software (in whole or in part), you shall adhere to all applicable U.S., European, and other export
laws, including but not limited to the U.S. Export Administration Regulations ("EAR"), (15 C.F.R. Sections 730 through
774), and E.U. Council Regulation (EC) No 1334/2000 of 22 June 2000.  Further, pursuant to Section 740.6 of the EAR,
you hereby certify that, except pursuant to a license granted by the United States Department of Commerce Bureau of 
Industry and Security or as otherwise permitted pursuant to a License Exception under the U.S. Export Administration 
Regulations ("EAR"), you will not (1) export, re-export or release to a national of a country in Country Groups D:1,
E:1 or E:2 any restricted technology, software, or source code you receive hereunder, or (2) export to Country Groups
D:1, E:1 or E:2 the direct product of such technology or software, if such foreign produced direct product is subject
to national security controls as identified on the Commerce Control List (currently found in Supplement 1 to Part 774
of EAR).  For the most current Country Group listings, or for additional information about the EAR or your obligations
under those regulations, please refer to the U.S. Bureau of Industry and Security's website at http://www.bis.doc.gov/. 

 */

[Jeffrey Phillips Freeman]

Since one of you're points of contention was the fact that I took down the website (which had some acknowledgements). I now have http://aparapi.com up with all those attributions included again. That should address all your concerns regarding attributions that you mentioned here.

[Jeffrey Phillips Freeman]

This was carried over from the original project for reference. Closing it though.