Discussion:
[Numpy-discussion] A numpy based Entity-Component-System
Elliot Hallmark
2016-05-20 23:24:43 UTC
Permalink
I have a Data Oriented programing library I'm writing that uses the
Entity-Component-System model.

https://github.com/Permafacture/data-oriented-pyglet

I have initially called it Numpy-ECS but I don't know if that name is
okay. The numpy license says:

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

but doesn't say anything about using the name of NumPy. Is this okay?

For anyone interested in what this project is, I suggest looking at the
project README. Briefly, a Component is the Data Oriented version of what
Object Oriented calls an attribute (a Numpy array of values that represents
an attribute that Entities might have). An Entity is the Data Oriented
version of an object instance (something subscribed to some subset of
Components, with an ID that can be used to access each instance's values in
those components). A System is like an object method (a function that
operates on the Components of all Entities that have that Component).

This is something that one would use in a game engine or simulation. It
allows you to have instances, but where the logic can be bulk applied to
all involved instances by operations on slices of Numpy arrays. In an
example shown in this video <https://vimeo.com/66736654>, I went from 50
FPS in an object oriented approach to using ufuncs operating on shared
memory in multiprocessing and getting 180 space steps per second on the
physics and 500-600 FPS in the rendering.

Thanks for reading,
Elliot
Nathaniel Smith
2016-05-21 01:40:09 UTC
Permalink
Post by Elliot Hallmark
I have a Data Oriented programing library I'm writing that uses the
Entity-Component-System model.
Post by Elliot Hallmark
https://github.com/Permafacture/data-oriented-pyglet
I have initially called it Numpy-ECS but I don't know if that name is
Neither the name of the NumPy Developers nor the names of any
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
Post by Elliot Hallmark
but doesn't say anything about using the name of NumPy. Is this okay?
Legally speaking, I'm pretty sure no one is going to sue you. That clause
in the license is generally taken to be mostly meaningless, because lying
and claiming that so-and-so endorses my project when they don't is
generally going to get me into legal trouble anyway, so the license text is
redundant. The main thing that would legally control use of the name
"numpy" is if we had a trademark on it, and I'm pretty sure no one has
claimed or registered one of those.

But legal issues aside, it'd probably be better to give your software a
more unique name? "Numpy-ECS" is potentially confusing (are we going to get
bug reports filed on it because it says "numpy"?), and, well, it's kind of
boring and generic, don't you think? Like naming your child
"Human-legsarms"?

-n
Benjamin Root
2016-05-23 15:17:29 UTC
Permalink
As a bit of a real-life example where things can go wrong with naming. The
"pylab" name was accidentally hijacked a couple years ago on pypi, and
caused several bug reports to be filed against matplotlib for failing
scripts. Some people thought that one should do "pip install pylab" to do
"from pylab import *" -- crazy, I know, right? ;-)

That was at least two years ago, and we are just now getting the person who
uploaded that errant package to fix the problem. We also have not yet been
able to find out the owner of the long defunct matplotlib twitter handle
(we started the process to reclaim it, though). There are a couple other
situations that have caused confusion among users, but these have been
mostly an issue of trademarks (which I believe NumFOCUS holds for
matplotlib?).

What you really have to watch out for is when someone creates a package
that uses some open-sourced library, and then claims that it is "supported"
by it. This can cause an undue burden on the original maintainers in
fielding bug reports and other issues. It also creates a false sense of
association/coordination -- which gets me to the issue at hand. I highly
suggest coming up with a unique name. It benefits you as it becomes
something distinct from numpy (so search results are more relevant), and it
benefits the numpy developers because support requests go exactly where
they are supposed to go.
Like naming your child "Human-legsarms"?
You owe me a new monitor!

Cheers!
Ben Root

Loading...