On Nov 21 2012 3:05 PM, John Morris wrote: > Hi EBo, > > On 11/21/2012 01:51 PM, EBo wrote: >> True. But one point that is in the compatibility list that you did >> not >> cover is: >> >> if LCNCv3 is (L)GPL2+, then it conveys with anything that is >> (L)GPL3+ > > Thanks for pointing this out. I'm weak on this subject, only knowing > what I do from packaging software for Fedora and RPMFusion, and not > familiar with the 'conveys with' terminology. My understanding is > that > if LCNC (or any software) is GPLv2+ and it's linked against something > GPLv3, it must then follow the GPLv3 rules. That will then make > anything GPLv2-only license-incompatible. Did I get that right?
That jives with my understaning. > If I did, then at least the portion of LCNC that links against the > RTAI > and Xenomai kernels must follow the rules for GPLv2-only, and must > not > link against anything GPLv3 or otherwise GPLv2 incompatible. I'm not entirely clear what this would mean for us with using/linking OS level stuff with our code. For that I would ask EFF, but there is probably something out there that explains it. >> How much of readline do you really use? Can it be easily replaced >> with >> something else. > > I don't know what readline is used for in LCNC, but I imagine > readline > v6 would be more or less easily replaced by readline v5. > > If the RTAPI/HAL portion and the UI portion only communicate through > IPC, then there would be more flexibility on UI licensing. probably, but IANAL... > John > > >> What I am getting at is to start with *if* all developers are on >> board >> with (L)GPL2+, then we look at the requirements. Them make a list >> of >> the potential libraries that can be broken out (HAL, ClassicLadder, >> ???) >> with a complete list of each ones dependencies (like readline, >> boost, >> ...) >> >> Once the above is done, we can either start experimenting with >> breakouts, or finding replacements for functional components. >> >> Once we have the above, we can then do the same for the different >> UI's. >> >> That's my 2c... I'll look at this again later tonight. >> >> EBo -- >> >> >> On Nov 21 2012 12:30 PM, John Morris wrote: >>> Hi list, >>> >>> On 11/21/2012 07:11 AM, Michael Haberler wrote: >>>> Yes it is time, but we have not ticked off on a key sanitary >>>> non-code >>>> prerequisites >>>> >>>> The GPL2-only situation prevents bringing in outside code which >>>> requires GPL2+ licenses. >>>> >>>> I table this issue again to get this finally resolved, I do not >>>> want >>>> to 'slide into some L3 work' and that glaring issue somehow falls >>>> under the table because of all the excitement about features and >>>> grand ideas about what could be done. We had a push recently, and >>>> it >>>> tapered off without tangible results. >>>> >>>> This licensing issue *must* be resolved before we go ahead, there >>>> is >>>> no way around it. >>> >>> Licensing is a complex issue, not simply about the original >>> authors' >>> wishes, but also what external software LCNC is built against, how >>> LCNC >>> is built against them (linked, code copied, or not), and how those >>> external softwares are licensed. Including those external >>> softwares >>> introduces license compatibility constraints. >>> >>> An example of such a constraint: On my system, LCNC is linked >>> against >>> the GNU readline library v6, licensed GPLv3+. Therefore LCNC must >>> either also be licensed GPLv3, or else must drop that library. If >>> the >>> readline v6 library were dropped, LCNC could be licensed as GPLv2, >>> according to my incomplete survey below. One possible workaround >>> would >>> be to use the GPLv2+-licensed readline v5, available on fedora as >>> 'compat-readline5'. (Anyone know what readline library used in >>> Debian?) >>> >>> An example of a non-constraint: LCNC is compiled with gcc and uses >>> source-highlight to process documentation. Those tools are >>> licensed >>> GPLv3, but since LCNC does not link to them or copy code from them, >>> LCNC >>> licensing isn't affected. >>> >>> An example of a problematic constraint: The RTAI and >>> Xenomai-kernel >>> versions link against both the GPLv3+ readline v6 library (on my >>> system, >>> anyway) and the GPLv2-only Linux kernel. LCNC cannot legally be >>> shipped >>> like that. Unless... >>> >>> I don't understand the architecture of LCNC well, but for example >>> if >>> the >>> RT piece linked to the kernel talks to the UI piece linked to >>> readline >>> only through shm, there may be an opportunity to ship the two >>> pieces >>> separately under separate licenses. >>> >>> Here's an incomplete survey based on the requirements discovered >>> while >>> building the el6/fedora packages. I don't know how some of the >>> programs >>> are combined with LCNC, and I don't know about compatibility of all >>> of >>> the licenses; hopefully others can help with that. Otherwise, a >>> quick >>> compatibility chart for the GNU licenses can be found here: >>> >>> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility >>> >>> John >>> >>> >>> Linked: >>> LGPLv2+: gtk2-devel, libgnomeprintui22-devel >>> MIT: mesa-libGL-devel, mesa-libGLU-devel, libXaw-devel >>> Boost: boost-devel >>> LGPLv2+: pth-devel, libmodbus-devel >>> GPLv3+: readline-devel >>> GPLv2: Linux kernel (Xenomai-kernel, RTAI, RTLinux) >>> >>> Dunno: >>> TCL: tcl-devel, tk-devel, bwidget >>> LGPLv3+: python-mtTkinter >>> MIT: blt-devel >>> GPLv3+ and LGPLv2+: gettext >>> python: python-devel, python-lxml >>> >>> Not linked: >>> GPLv3+: gcc, gcc-c++ >>> GPLv2+: lyx, dblatex >>> GPLv3+: source-highlight >>> ImageMagick: ImageMagick >>> GPLv2+ and OFSFDL: dvipng >>> GPL+ and GPLv2+: asciidoc >= 8.5 >>> GPLv2: Linux kernel (Xenomai-user, RT_PREEMPT, Posix) >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Monitor your physical, virtual and cloud infrastructure from a >>> single >>> web console. Get in-depth insight into apps, servers, databases, >>> vmware, >>> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >>> Pricing starts from $795 for 25 servers or applications! >>> http://p.sf.net/sfu/zoho_dev2dev_nov >>> _______________________________________________ >>> Emc-developers mailing list >>> Emc-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a >> single >> web console. Get in-depth insight into apps, servers, databases, >> vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, > vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
