Am 09.08.2012 um 17:34 schrieb John Kasunich: > > > 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.
John, let me say that I very much appreciate your readyness not just to see the problem, but also to do something about it. > 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. I concur, and initially I thought that would address the issue. I am unsure if it does, but this might be my own lack of clue. Among the things I do not understand is: what is the implications of different licenses in different corners of a given project like LinuxCNC?. Chatting with cradek on the issue we both assumed that for license compatibility with a to-be-used library the most restrictive part's license holds, which would be GPLv2only right now. This might or might not be the true; likely not, because under such an assumption different licenses are watered down to the most restrictive one, which makes the point of different licenses within a project moot in the first place. The other issue: for the sake of argument, assume the main codebase were now GPLv2-or-later, and LGPL-something for interfaces. Let us assume this translates into 'I want to release a project under: "GPLv2 or later"' in gnu.org speak, so that would be column 2 here: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility Now, staying with the example at hand - using a LGPLv3+ library package - I arrive at row 12 which says: "OK: Convey project under GPLv3 [9]". Looking at [9] I read: 9: Because GPLv2 does not permit combinations with LGPLv3, you must convey the project under GPLv3's terms in this case, since it will allow that combination. That I read as 'all of LinuxCNC must move to GPLv3', and thats a bit steep. I hope I'm off here. Again I don't see the upside for the LGPL parts. I understand this issue would not arise if LinuxCNC were LGPLv2.1 or later. The picture changes completely if for instance HAL (different license) is considered a separate 'project' of its own; maybe this is my misreading. I hope to be wrong or overly cautious on some of the issues. - m ------------------------------------------------------------------------------ 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
