Licensing and future plans
michalochman opened this issue · comments
Hello Patrick,
I've noticed that you decided to implement your own version of React reconciler for Pixi based on michalochman/react-pixi-fiber.
Great! I have absolutely no problem with that, as I've released it under MIT license.
However, according to the license, you should have left the original copyright notice in any substantial portions of the original software (which is most of the code).
I had a look at the code in this repo and it is not that different from my original code – just a little reorganized and with some features added.
Is there a reason you decided to copy the code instead of forking it and submitting issues or pull requests to the original repo? Do you think we really need another library doing the same exact thing using the same exact API? Would you consider joining forces instead to collaborate on a single project? I think that would better benefit the community and would be less wasted effort.
Let me know what you think.
Cheers,
Michał
In addition to the above, I've noticed that you publicly claim copyright ownership on Twitter. Saying that you "wrote a React PIXI Renderer" is far from truth.
Hi Michał,
Thank you for reaching out!
Regarding copyrights
This repo isn't a clone or copy of your codebase. I did some research on React Fiber reconcilers in general and used yours (and others) as reference. Take that as a compliment :) Sorry to see you're offended.
However, according to the license, you should have left the original copyright notice in any substantial portions of the original software (which is most of the code).
I wrote this lib from ground up, just have a thorough look at the code. Although, we might share some common code-architecture concepts, those are mostly borrowed from ReactDOM.
I've mentioned your react pixi lib in the README as well (scroll to bottom)
Reason
Is there a reason you decided to copy the code instead of forking it and submitting issues or pull requests to the original repo?
Firstly, I didn't copy/paste any code. If you think otherwise, please let me know what parts you think I've copied.
Obviously, I was in the need of a React renderer for PIXI. The popular lib react-pixi was pointing to yours, so I decided to take a look and back then I noticed that a lot wasn't implemented yet (and some things could be optimized). I started out writing one, so I learned how to write a renderer and play with the new experimental reconciler.
Best,
Patrick
Hi Patrick,
What you write above is not true at all.
This repo isn't a clone or copy of your codebase.
(...)
I wrote this lib from ground up, just have a thorough look at the code.
I think the very first commit speaks for itself.
Your repository was not written from ground up, it was a copy of my repository with slightly changed file structure, you can clearly see it from the contents of files in this commit.
What's funnier, I've also noticed that after I opened a pull request with changes to tree updates it only took you 3 hours to copy it and include in your repo.
To address other parts of your statement:
I noticed that a lot wasn't implemented yet
At the time of you copying my code, my library was 100% compatible with original react-pixi project.
(and some things could be optimized)
It is in good taste to use github issues / pull requests for such things, my library is under active development which can be seen by other reported issues and pull requests.
Resolution
The evidence I supplied leaves no doubts. Please let me know how do you want to resolve this situation. I would expect one of the following:
- you fork my original repository from start the proper way (using github forks for example), leave all copyright notices as MIT license says in any substantial portions of the original code (which is most of the code), and then apply any changes you possibly want
- you simply delete this repository or make it private and we forget everything happened
Cheers,
Michał
Hi Michał,
With all due respect, I want to reply and close this conversation.
I think the very first commit speaks for itself.
Yes I did start forking your project, but as the commits evolves you can see clearly see that a lot has changed and the codebase is totally different now. (just have a third look
So here's my solution. Although I'm confident I'm not doing anything wrong, I truly want to help you solve this. I'm not going to delete this repo. Here's what we're going to do, you take a "proper" look at the current state of the codebase and let me know (by mail) which parts you think I've copied from you (not ReactDOM nor the prior izzimach react-pixi lib). I'll personally add copyright notices in the comments above the related code.
I've added a new commit with "copyright notices": 67bb65d
And please let's be polite to each other, no need to point fingers
Thanks!
Patrick
Second thought, we could merge our codebase together and make this codebase leading as it's more developed.
A good solution would be to create a Github organization for it and that we're both collaborations.
Please let me know your thoughts, thanks in advance!
Hey Patrick, that's exactly what I proposed in my first comment – I think having one library with the same API is enough and will better benefit open source community.
I would not say that this codebase is more developed, can you please point me to the additional features this codebase has that are hard to implement over the original code and why do you think is better as a base?
The reasons I think my original code should be the base:
- full, 100% compatibility with the original
react-pixifor React 15 with trivial migration path react-dom-like prop validation in development (as PR now, but it works), battle tested on various real-world projects
Also, I'm not sure about your experience with react-pixi, but I worked with it every day for the last 1.5 years and the decisions I took while working on react-pixi-fiber are well-thought and in mind with all the limitations and issues that I know about. I also have have long term plans for this project and I'm willing to fully commit to it.
What's missing and is easy to add:
- React 16.3 Context API Provider/Consumer – I want to add this and I know how I want to add this so it works with both React 16.3 and pre-16.3
- Handful of extra components (like Mesh, NineSlicePlane, Rope)
The other differences are mostly related to code style and project structure – which I think are fine in both repos.
Long term goals:
- Collection of custom components
- Better support for on-demand rendering
- Dual compatibility with Pixi v4 and v5
I've just created https://github.com/react-pixi organization, let me know if you want to join it. We can then talk about how we want to proceed and decide on the next steps.
Hi Michał,
First of all, thanks for your friendly reply.
Hey Patrick, that's exactly what I proposed in my first comment – I think having one library with the same API is enough and will better benefit open source community.
True! But before we collaborate on it together we need to be on the same page. And let's take decisions together instead of solo.
I would not say that this codebase is more developed, can you please point me to the additional features this codebase has that are hard to implement over the original code and why do you think is better as a base?
There's nothing wrong with your codebase at all, but I would have done things differently. For example testing the thing through, you've tested each individual methods on the reconciler while I test the implementation instead.
Here's why I think this repo should be leading and merge some ideas of you:
I think this repo covers separation of concern and is better testable and it already supports more features, like PIXI events and components. Every implementation derives from tests (TDD).
To be honest, I don't really care if it's backwards compatible with older React (stack rendered) versions, if people are using React < 16 then they can use https://github.com/Izzimach/react-pixi.
react-dom-like prop validation in development (as PR now, but it works), battle tested on various real-world projects
Sounds good! Let's add that.
I also have have long term plans for this project and I'm willing to fully commit to it.
Awesome, and I'd love to contribute to the project too and I totally agree on your long term goals!
So here are my thoughts.. let's make us both admins of the react-pixi github organization and create an initial commit with this repo code, apply additional stuff that you're missing in this repo (like prop validations etc) and we both contribute to the project to make it the best react pixi renderer available!
What do you think?
For example testing the thing through, you've tested each individual methods on the reconciler while I test the implementation instead.
If I understand correctly, you mean that you here have added basic integration tests, while my codebase only has unit tests. That's true, but copying over these integration tests would be straightforward.
I think this repo covers separation of concern
I'm really interested how do you think it does that and how it's different from the original repo in this regard. Would you be so kind to elaborate?
it already supports more features, like PIXI events and components
All Pixi events are supported in the original code, why do you think not? Regarding components, this repo only adds the components I've specified above, and as you already know, adding components that map to base Pixi DisplayObject classes is just few lines of code.
I don't really care if it's backwards compatible with older React (stack rendered) versions
It's not about being compatible with older React, there's react-pixi for that.
What's important is to give people with codebases that were using react-pixi while on React 15 the possibility to migrate to React 16 without having to rewrite their whole apps. Migrating from React 15 to React 16 and from react-pixi to react-pixi-fiber is very easy and is well documented. It's impossible to do with this library due to API differences.
react-dom-like prop validation in development (as PR now, but it works), battle tested on various real-world projects
Sounds good! Let's add that.
If you look at that PR then you will be able to say it's a lot of code that is added on top of existing project structure. It took a lot of time to add and test this feature and knowing this I would not attempt doing it for the second time.