On Thu, 09 Aug 2012 10:41:45 -0400, Kenneth Lerman wrote: > On 8/9/2012 9:47 AM, EBo wrote: >> On Thu, 09 Aug 2012 09:03:41 -0400, Kent A. Reed wrote: >>> On 8/9/2012 3:10 AM, Michael Haberler wrote: >>>> Chris, >>>> Am 09.08.2012 um 06:00 schrieb Chris Morley: >>>> .. >>>>> While a lot of the details are over my head the ideas your >>>>> talking >>>>> about are important. >>>>> We are not so good at long time planning in linuxcnc but it has >>>>> seemed to work up to this point never-the-less. >>>>> >>>>> I see a few things coming in the nearish future that may put us >>>>> in >>>>> a position of considering developing >>>>> a new version. >>>>> licensing is a bit of a mess right now - which limits who will >>>>> use/develop use if there is legal questions of use/distribution. >>>>> <...> >>>>> Enjoying the discussion... >>>>> Chris M >>>> linking a rewrite of LinuxCNC ("LinuxCNC3") and a licensing >>>> cleanup >>>> is an interesting idea, and I think worth exploring in more >>>> detail. >>>> >>>> I dont have a suggestion for a future license yet, but assume we >>>> had >>>> one (lets call it v3license) and it would enable bringing in other >>>> key >>>> components more easily. >>>> >>>> I need to think this through, but my first take on a greenfield >>>> approach to V3 would be: >>>> >>>> 1. carrying forward HAL and RTAPI, all the HAL components, motion, >>>> comp, the sim/rt environment to v3license would be key. >>>> <...> >>>> >>>> whale of a plan.. this will years of coexistence of v2 and v3. But >>>> I >>>> agree it is time to consider that cut. >>>> >>>> - Michael >>>> >>> I don't know what has happened to him in recent times but a fellow >>> named >>> Paul Corner (the father of the BDI series of EMC) was a major >>> player >>> early in the history of EMC being pushed out of NIST. In addition >>> to >>> making many technical contributions, he constantly complained about >>> the >>> licensing mess and the conundrum it would present to many users. >>> Tension >>> grew between him and other developers about many things and useful >>> discussions gradually ceased. Clearly, the licensing problem didn't >>> go >>> away however. >>> >>> One has to be cautious about license "cleanup". I'm not a lawyer >>> nor >>> do >>> I play one on TV but as I understand it, a license can be changed >>> only >>> by the granter of the license. I haven't looked explicitly at the >>> current codebase but In some parts of the original EMC both the >>> granter >>> and the license were explicitly stated. In other parts, not so >>> much. >>> As >>> Paul would (did) say, one can't simply slap a license on a piece of >>> code >>> that is missing a license statement. >>> >>> John Kasunich's communication came in as I was writing this. It is >>> exactly the kind of communication we want/need from all the >>> authors. >> I never said it would be easy, and belive me I was NOT suggesting >> just >> slapping something on it. No, if you cannot clean up the licenses >> then >> you will always have this problem creeping up. That would be, in >> my >> book, a prime reason to throw away working code to make it clear and >> simple. >> >> I'm glad that John got back to you, and there was a lot more wrong >> with >> Paul's discussions than what you described. I would have to check >> my >> email archives to make sure that he is in fact the same Paul that >> caused >> me to blow a cork a decade ago and end my serious participation with >> EMC. >> >> Moving forward. If I were heading up a license cleanup effort I >> would >> put together a list of acceptable licenses (whatever they are) and >> advocate one of them but ask if that one cannot be worked out with >> everyone is there another license that would be acceptable by the >> authors/license holders. It is likely that some of the components >> cannot be worked out, so then a clear migration strategy can be made >> for >> finding a replacement. At that point I would also ask if >> LinuxCNC/EMC >> can become the license holder so that they can work out these things >> in >> the future, but would also suggest that they, as a body, be holden >> to a >> contract that states the limits of what they can do with issues like >> relicensing, etc. >> >> Other than that, it will likely be a lot of work to swap out >> components >> to ones that have clear license/ownership constraints. >> >> Just my 2c... >> >> EBo -- >> > 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. > > I suggest that we come up with an agreement of what our license > requirements are and start getting people to sign up. > > I believe that if we can, we should use some pre-existing license, > rather that writing our own. 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 absolutly agree, but there is an issue that I personally would have to think thrice over -- that is are there any limits on the board changing the license? I also agree that we should try to use an existing license (like GPL/LGPL, BSD, MIT, Public Domain). The question is what are the range of acceptable licenses to choose from. Some (much?) of the work is GPLv2+ and there is an issue of GPLv3 libraries that people want to use. Personally I like (L)GPL code so that I can continue working with it in the future... EBo -- ------------------------------------------------------------------------------ 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