On Thu, Aug 9, 2012, at 10:41 AM, Kenneth Lerman wrote:
> Fortunately, the git (and previous) change logs can give us a list of > the contributors. As one step along the way of getting things done, I > suggest that we ask contributors to sign something like: > > I, (insert name here), do hereby authorize the Board of Directors of the > LinuxCNC project (formerly the EMC project) to define a new license to > be used for all of my past contributions to that project. In > consideration of the work they provide to define such a license, I agree > to sign any and all documents that are necessary to facilitate the > change of my contributions to use that license. Nobody is likely to sign that statement unless it also includes a description of the goals of the license. As written, the "new license" could be anything the board decides, including totally proprietary. > I suggest that we come up with an agreement of what our license > requirements are and start getting people to sign up. Agreed. > I believe that if we can, we should use some pre-existing license, > rather that writing our own. Agreed 110%. There is ABSOLUTELY NO REASON for us to even think about writing yet another license. My offer to relicense my contributions would be retracted if we were to do something so monumentally stupid. We are coders and machinists, not lawyers. My offer was based on the premise that the relicensing would most likely be a simple change from "GPL 2" to "GPL 2 or later" or something similar. It would take a lot more convincing to actually get me (and everyone else) to switch to a non-GPL license. Note that the HAL library is under the LGPL. I did want to allow HAL components that could contain proprietary algorithms, as long as they connect to the rest of HAL using the standard pin/signal interfaces. So the calls to create pins and signals, as well as the rest of the core API, are licensed accordingly. Of course, nothing legal is that simple. Realtime HAL components are kernel modules (at least until we move beyond RTAI to user- space realtime, RT-PREEMPT, or similar). Kernel modules with non-GPL licenses will always taint the kernel, and in the minds of at least some people will always be a license violation. I'm not a license lawyer and don't really care. > Among my requirements: > > 1 -- It should prevent people from hi-jacking our code and creating a > closed source product from it. > 2 -- It should facilitate the development of open source products. > 3 -- It should facilitate the work of system integrators. > 4 -- It should permit the development of closed source modules that work > with it. (I'm not sure we would all agree with this.) For example, > suppose I develop a really clever way of generating optimal paths for > clearing a pocket. I'd like to be able to sell this as an add on to > linuxCNC3 without distributing the source. I would suggest that this be GPL (some version, probably with "or later" to avoid future pain) combined with LGPL for interfaces where we want to allow the possibility of proprietary modules. Non-GPL licenses will have a much bigger hill to climb before they are accepted by the community. -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
