We need a license

[ariovistus]

So our code can be officially open source. Also so nobody hooks up the kiwidrive code to their nuclear reactor and then sues us when things go to pot..

pyfrc is MIT (this seems popular for javascript and python libraries) robotpy-wpilib is 3-clause BSD (because wpilib is BSD) or we could do GPL.

[ariovistus]

I vote MIT.

[wylliec]

I vote MIT

[aebooth]

MIT is fine with me.

[aebooth]

Do you want to do that for all of our stuff Ellery? Pass the job to Caleb if you're too busy.

[bb010g]

I vote AGPLv3 (list of some projects that use it). If we're going to be putting this on all our stuff, it'll be nice to have work on the future WPILib on JS come back into the community. It would help with growth (meaning more people to find bugs and suggest features :)). My issue with MIT or 3-clause BSD is that people can take our code or libraries and modify them without ever giving back to the community. While that may seem good short term, in the long term having a license like the GPL would encourage continued development by the nature of how changes used in competition (over a network, the FMS) would have to be accessible in some way. This keeps the code up to date and avoids stagnation, even if the original devs (us) drift away from it—as long as someone's using it, it's good. Commercial use shouldn't be a problem, as all of this is being used with robots in a community-focused program, anyway. If any of our future projects under Retrobotics have a good chance of being used commercially and we're worried about that, we can decide then and there. (We might even be able to dual license for commercial use and get that revenue feeding to the club, but that's pretty far down the road right now.) (Also, WPILib's 3-clause BSD license is compatible with the v3 GPLs, so that's not an issue.)

[ariovistus]

I personally think github's infrastructure has done more to keep software projects alive than the GPL has. Our robot code doesn't have a >1 year lifespan, and it is unlikely to be useful in a commercial context. The only relevant case I can think of is another team using our code and not disclosing their changes, but even that is unlikely since that code is fairly dependent on our custom hardware.

[ariovistus]

Although, if you want to build that battery charger idea and sell it to other teams, I'm in.

[aebooth]

Ellery, will you help with porting wpilib to nodejs? I think there is potential for great glory there....

[bb010g]

@ariovistus commented on Apr 9, 2015, 2:38 PM PDT:

I personally think github's infrastructure has done more to keep software projects alive than the GPL has.

That's debatable, as GNU & GPL have been around a fair bit longer than GitHub and social coding sites in general, but that is its own debate and not too relevant right now.

@ariovistus commented on Apr 9, 2015, 2:38 PM PDT:

Our robot code doesn't have a >1 year lifespan, and it is unlikely to be useful in a commercial context. The only relevant case I can think of is another team using our code and not disclosing their changes, but even that is unlikely since that code is fairly dependent on our custom hardware.

I was thinking more for all our Retrobotics projects—you're right, this robot code probably wouldn't be that widely used. However, a port of WPILib to JS or GObject or anything else would probably end up being used a lot by other teams. That's where I really want to make sure the proper care is being put, and I think a GPL would do better long-term.

@aebooth commented on Apr 9, 2015, 2:43 PM PDT:

Ellery, will you help with porting wpilib to nodejs? I think there is potential for great glory there....

I've been thinking about how to do that, and what about a port to GObject? It binds to other languages pretty easily and porting to Vala probably would be less of a pain.

[aebooth]

I think anything after node is gravy--I just think that js is important because it is becoming so universal. Plus node add-ons lend themselves nicely to this kind of project.

[bb010g]

I agree with the importance of a JS port, but I think porting to Vala and binding out from there to JS instead of through addons would be a lot easier to implement. Plus, we get other languages for free along with JS. The less we have to think about, the easier this will be.

[ariovistus]

I don't like the idea of a port. It puts the burden of upstream patches on you to translate and merge in. It puts the burden of QA on you - duplicated effort if the original already does it (I don't know what the wpilib folks do though). That said, it's what the robotpy people did, but then they seem more motivated than I am..

Vala is interesting but risky. It will probably suck much less to use than javascript, but it will preclude more people from contributing than javascript. Maybe that's why robotpy went to a pure python implementation.. Do you know of any vala projects that are distributed over npm?

Having never used either, is GObject a better option than a SWIG wrapper around c++ wpilib?

[ariovistus]

Anyways, the answer is no unless and until someone buys me a roborio and makes a power cord that plugs it into a regular wall outlet. That would be wizard.

[bb010g]

@ariovistus commented on Apr 9, 2015, 5:52 PM PDT:

Vala is interesting but risky. It will probably suck much less to use than javascript, but it will preclude more people from contributing than javascript. Maybe that's why robotpy went to a pure python implementation.. Do you know of any vala projects that are distributed over npm?

Having never used either, is GObject a better option than a SWIG wrapper around c++ wpilib?

I'd tend toward Vala because if we use SWIG we're going to have to be making manual adjustments anyhow with SWIG and there are a couple of semi-minor changes I want to make along the way, like what RobotPy did with the lambdas for PIDController. We also get ValaDoc for nice documentation, something SWIG doesn't have an equivalent to. It's pretty simple to get JS running with a GObject lib (see here, the first bits with building wouldn't even be needed unless someone was modifying WPILib, rather like RobotPy when they were on SIP. Even then, changes with WPILib would just be a matter of recompiling to C and using the cross-compiler on those, along with generating the bindings. That could all be automated in a makefile/script/something).

[ariovistus]

Not to say I don't have the time, but I am lazy.

Let's use MIT for this project, and have it be our default choice unless there is a compelling reason to use something else.

[ariovistus]

@bb010g building vala code is the easy part. I'd be more worried about whether we can get node build for the roborio. Also, what about multithreading? At least PIDController uses it, and nodejs doesn't have it.

Or it does, but doesn't expose it to javascript code. point to vala, I guess.

[bb010g]

I would look into what gjs has for multithreading too. It's like node.js, but on Spidermonkey instead of V8 (their performance is pretty dang close, so that isn't an issue) and natively supports GObject Introspection. I'm pretty sure they both have ARM binaries; I'll check when I get off mobile.

[aebooth]

Do we really need multithreading?

[aebooth]

Seeing as how real-time programs are all centered around a giant event loop anyway, I thought nodejs would be a natural choice since it follows the same idiom.

[aebooth]

I think going outside of c++ to accommodate something like GObject might be extra work where we're wandering around in a number of languages and codebases. Node add-ons are supposedly dead easy to write, and straightforward. If that is the case, then after deciding how we are going to organize everything, we just have to write a c++ addon for each c++ class (same language, all well documented). I imagine if we put our heads together, we could even write an addon generator in python, haskell, etc. that takes header files and makes v8 JS object classes and headers which need only minor tweaking.

[aebooth]

The other thing is that node add-ons are just c++ code that makes v8 objects, so in the node model, we get everything c++ wpilib can do for free--multithreading included.

[ariovistus]

I would assume wpilib has its own event loop; I wonder if node's event loop is even suitable. Seems like you'd need a way to terminate a js script if it blocks for too long for physical safety concerns.

[aebooth]

Part of my point is we could use the wpilib event loop because v8 (where you build node add-ons) is just a c++ library.

[ariovistus]

all right, so a viable game plan would be to embed v8 in a c++ project that loads and runs javascript code in the event loop. Its worth a try.

[aebooth]

That's what I'm saying. Then, if we follow some organizational conventions, we can take advantage of the nodejs infrastructure/package management system as well.

[aebooth]

You guys will want to check out tutorials on nodejs add-ons and the events module.

[ariovistus]

FYI we now have an Open Source license for Confluence, Confluence Questions, and Confluence Calendar at https://retro3223.atlassian.net