Over the last few days I've been writing stuff here and reading other people's stuff. I've been rolling all this stuff around in my mind with the intention of figuring out what solution I would propose for the copyright/licensing issue, and what sort of plan I could make for things to do at the meeting next week. Since I'll soon have to stop doing anything except getting my stuff together to drive out there (Steve says we'll leave Saturday afternoon), I figure I should post my best thoughts so far:
1. Make a drawing/diagram/something, plus a bunch of writing, that explains how linuxcnc works. This should describe what happens during startup, what loops of program logic are doing while the program (linuxcnc) is running (including all the different modes and states that can exist), and what happens on exit. I also need to be able to relate what's happening conceptually to where the actual source code is located in the source tree and how it is implemented. I will admit that I simply can't visualize the whole system at the top level, I don't understand it. There are pieces of it that I know really well, and I'm able to apply linuxcnc as a solution (it's sort of my job), but I don't know the system as a whole as well as I'd like. If all I do next week is this, I'll be satisfied. I'll bring a roll of white butcher paper, and all the felt tip markers we accumulated when the kids were little. I figure I can just roll it out and draw diagrams, then take pictures of them with they are done. Since most of the people who, collectively at least, know most of what there is to know about the system, will be there, I can just ask for help if I get stuck or prove entirely clueless. 2. I'm also going to bring whatever papers and things I have from early EMC development that aren't already available online. Hopefully someone from our documentation department will be there to tell me WTF to do with this stuff (I haven't gathered it up yet, so maybe I'm imagining it's more than it is). Scan it & trash the originals maybe? Anyone else who has old CDROMs of old EMC versions, or anything else that's old and project related is welcome to bring their stuff as well and we'll archive and/or dispose of all of it in whatever way seems best. 3. MODULARITY - In the e-mail list postings, private e-mails, and phone calls I have received, the one nearly universal suggestion from everybody has been to "increase modularity". This is hardly surprising given the rapid acceptance and general high praise for the HAL, which is basically, an experiment in radical modularity. People just seem to want their industrial automation software served in bite sized pieces. So, I guess, the thing to do is to come up with a drawing/diagram/something, plus a bunch of writing (see #1 above), that describes how to further subdivide the system, and to what atomicity. Also, how do the newly liberated components communicate? Should, for example, the HAL be installable as a stand alone system (without the CNC part of linuxcnc)? That was John Kasunich's original idea. IIRC he was going to call it 'BLOCS'. I'm sorry that, at the time, I didn't push him in that direction. The HAL is a genuine good idea, and it deserves more than to simply be a linuxcnc ingredient. I'd like to leave the meeting with a clear plan for accomplishing whatever you guys want in the area of increased modularity. 4. The Copyright/Licensing Issue - After careful consideration, my recommendation is this: A. Most of the code is clearly the work of known authors with unassailable copyright interest in their work. I'm talking about things like AXIS, the documentation, HAL components, Gscreen, etc.I want to talk with these groups of authors to make sure their licensing terms are clearly and emphatically expressed in the source code. We might also discuss, all together, what license would maximize interoperability and minimize annoying hogwash with the goal of ensuring that everyone's license works with everyone else's. B. The part of the code that's in /src/emc is (perhaps with parts of RTAPI which I need to talk about with JohnK) where most of the problems lie (also I'm ignoring all of NML as we seem to agree that will be replaced in any case). Code that originated at NIST, or which was written, even partly, by NIST employees or me (my part is a very small part indeed) is, I believe, in the public domain. Dave Bagby and others have convinced me that this is true, or as true as I can know short of a court decision. In the end, I intend to revert the following commits (and any others in the same vein) as regards licensing: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=525e2661087959e1f864e12224e3ad33c568f21d http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=9328e59aca3ceef4005caa1b476eb3678fa217f0 I will do this myself so that whatever the consequences, they will fall on me. I own this problem and now I'm fixing it. Before I can do that, there are some people with interests here whose situation needs to be addressed. These folks, acting on the false impression created by the spurious license statements, made contributions to this area of the code base with the idea that their work was covered under the GPL. It would be immoral for me to pull the rug out from under these folks, so they will need to (and I'll try my best to help them) remove their code to another part of the source tree. Some examples of things I'm talking about are (I think) Chris Radek's improved trajectory planner, and a whole lot of interpreter extensions with various authors. We'll have to figure out how to do this so that everyone who wishes to preserve their copyright interest may do so. Now I really want everyone to be happy, but if you're the kind of person who is only happy when everyone else is unhappy, and you think your two line or even fifty line bug fix entitles you to throw a monkey wrench into this project for your own amusement, I'm not having it. You can move your code to another directory, or voluntarily commit it to the public domain with the rest of the NIST code. If you decide to sit still and obstruct progress, say by claiming an authorship interest without identifying your code so that you can be written out, then you're welcome to sue me when I revert those commits. I've sued and been sued; I don't like it, but it doesn't scare me either. If you feel that I have overlooked some important fact with respect to this situation, that had I known this or that I would act differently, please speak now, or (as they say) forever hold your peace. One nice thing about keeping the public domain code in the public domain is that if later someone wants to challenge the IP, for example by claiming patent infringement, we can just shrug and suggest they take that up with the government. As far as I'm concerned, IP trolls are always in season and the government can do whatever it wants with them. C. Personally, I think that it would be a good idea to put in place some mechanism to ensure this copyright/licensing confusion never arises again. I also think that the mechanism should be the least complicated and intrusive that can be devised. My best suggestion (so far) is to handle this the way the kernel developers do: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches (see section 12) D. I oppose copyright assignment for several reasons: First, copyright assignment requires that there is someone/something to assign it _to_, usually some specially constructed legal entity created for just that purpose. I oppose creating any legal entities because they all cost time and money to maintain, and any lapse in performing this tedious maintenance renders them invalid unless you do even more tedious and expensive work to fix them. Second, all you achieve by assigning all the copyrights in a project to a single legal entity is to simplify the job for anyone who wants to dispute your project's right to exist for whatever reason. Instead of facing a difficult to identify, widespread group of opponents with unknown capabilities and resources, each of which must be separately engaged on their own turf, there's just one big fat stupid entity to defeat. Unless you think we can create an entity with huge resources that would deter the casual patent troll or other IP criminal, you're better off with everyone keeping their own copyright. Here's a powerpoint that addresses this: http://ref.fedorapeople.org/fontana-linuxcon.html Linus also concurs: https://groups.google.com/forum/?fromgroups=#!original/fa.linux.kernel/1bajji4TsDI/m6e33MR6WLAJ E. While I'm busy turning friends into enemies with all this negativity, I guess I should address the whole governance thing. My view is simple: Cooperation ( http://en.wikipedia.org/wiki/Worker_cooperative ). IMHO, the Board of Directors should vote to abolish themselves, then resign, or vice versa. The whole Board of Directors idea has resulted in two things: First it provides a convenient contact point and identification of responsible parties for any predators who come along looking for trouble. Second, it supplies a locus for criticisms of our project. Because the Board is not especially active or vocal, it can be labeled a failure or ineffective by outside naysayers. Of course if the Board were active and vocal, outside naysayers would be calling the Board "Orwellian" or Nazis. You can't win this one, so it's best to just avoid the whole thing entirely. What we _do_ need is two things: A way to poll the community, free of fraudulent influence, that anyone in the group can use to quickly and easily measure the community's opinion on a subject, and a way for us to communicate more effectively and with higher bandwidth during the largest part of the year when we're not all in the same room. If you have any ideas on either of these things, press 'Reply' now and start typing! F. Cyberpunk style problems require a cypherpunk style solution, and that's basically what I'm proposing. Other than the mailing lists and our other tech support facilities, our public profile needs to hunker down and lie as flat as possible so that it's not silhouetted against the horizon. On the plus side, opportunistic jackasses are usually easily discouraged, so even small efforts at making ourselves "hard to get a grip on" will deliver payback on the 80/20 scale. Once linuxcnc is adopted by a plurality of commercial users we'll be a lot safer. It's that awkward phase between now and when we achieve world domination that I'm concerned about ;) The above is certainly enough to keep me busy for a week (at least). I have to start forming up my pile of junk next to the front door of my house so that when Steve shows up I can throw my stuff in the van and go. To the other folks who sent me lists of good ideas: I'll try to aggregate these and ensure that they are addressed at the point when we work on items #1 and #3 above. Thanks, Matt ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
