Hello Alois, not completely right. You will need CQs, but "works with", "pre-requiste" or "pre-requiste exempt". The PMC will need to discuss/vote on the request with the outcome of either of those and in the case or "pre-requisite" EMO has to approve as well. For a "pre-requisite" also a full IP check will be made.
The main difference between "works with" and "pre-requiste" is the question if the solution can do "its thing" without that dependency or not. Of course the question is what is that your application does. That is why there has to be a discussion around that to find it out. Now as far as I remember 4DIAC, there is a modular build system which uses CMAKE and some options to enable/disable things from the build. So you could run a Linux build, all problematic things excluded and distribute this as a binary without problems. Then you could offer a source release, allowing the user to enable things in the build, looks to me like a works-with then. Because your core runtime still works without those dependencies. Still you would need that "works with CQ", since you will be using their API in your source code. The third option would be to extend your build system in a way that your download the source release of 4DIAC and allow the user to add its own source package, recompile and have him add his own dependencies, but in a project-standardized way. Jens On 06/28/2016 09:10 PM, Alois Z. wrote: > Hi Jens, > > Thanks a lot for this clarifcation. EMO eproves it I would suggest to > put it into the wiki into the new project handbook. It helped me a lot > to understand the sitation. > > So for 4diac FORTE we are currently mainly doing source only releases. > We only have very basic binaries for Windows and Linux (and hopefully > soon for MacOS) allwoing users to do some quick tests and evaluations. > But these binaries have only OS dependencies. > > Furthermore all all our "special" dependenices are opt in > dependencies. That means the user needs to add them in the compilation > step and have the dependencies available during compialtion (i.e. our > option 2). > > We have for some systems vendor specific (closed source) dependencies > (i.e., I would like to compare it to a Windows dependency). In this > case our user typically needs anyhow to buy the hardware and/or the > according tools and libraries. So we can not deliver binaries for these. > > So making the long story short. If I understood your explantion we > sofar do not need to any CQs as long as we stick to source releases. > > BR, > Alois > > *Gesendet:* Dienstag, 28. Juni 2016 um 13:33 Uhr > *Von:* "Jens Reimann" <[email protected]> > *An:* [email protected] > *Betreff:* Re: [incubation] wrap binaries into a plugin > Hi, > > I do think that there are a few scenarios here. > > 1) You port your runtime to a new operating system. If that does not > bring any new dependencies (like libraries) then it should be not an > issue at all. I know that some operating systems just behave a bit > differently every new and then. For example porting from Linux i386 to > Linux x86_64 may require to change a few things here and there. But in > the end your code base supports both with one code set. I don't see a > reason to have any CQ here. > > 2) You port your runtime to a new target which requires additional > dependencies. If you want to distribute that final runtime (binary) you > need a CQ and the code has to go through the full IP check. > > 3) Like 2) but you don't want to distribute any binaries. Then you could > go with a "exempt pre-reqs", as Mike said. People just have to get those > dependencies first before they can compile your runtime themselves. > > 4) You want to add functionality to your runtime which requires 3rd > party dependencies which are not compatible with the EPL or are closed > source. Now I don't think that is possible in this case, since it would > require using "#include"s and function calls to proprietary/closed > source/incompatible code. So it is not only a matter of "when its there > is works", but it is a part of your runtime (4DIAC) then. > > But I also do think that there is a simple solution to #4. If your > runtime supports dynamic loading of extensions (which also works in > C/C++) then you could define some sort of plugin API. The plugin system > can be distributed easily through the Eclipse Foundation. And all other > extensions, which require problematic dependencies, can by loaded when > the runtime initializes. Which is in fact what the Eclipse IDE does all > the time. > > I think your scenario matches #2 or #3. Since, if I understood you > right, you compile your runtime, together with some O/S blob into a > firmware blob which is a combination of your code and their O/S. So you > can decide if you only distribute the source code (#3) or a full blob > (#2). > > Jens > > PS: @EMO please correct me if I was wrong > > On 06/24/2016 08:56 PM, Alois Z. wrote: > > Mike, > > > >> Operating systems are typically treated as "exempt pre-reqs" > because they are already installed on the target machine. I/O access > libraries have to be treated on a case-by-case basis, and it makes a > great deal of difference if you are distributing the library with your > code, or simply calling a library that is already installed on the > target machine. > > > > Thanks for the clarification. How would we treat operating systems > as often sued on smaller IoT devices where the operating system is a > library linked to the application (e.g., eCos, freeRTOS). Would these > be treated like any library? > > > > I'll read through the docs. Thanks for the pointers. > > > > Alois > > > >> See http://www.eclipse.org/org/documents/ for the following > documents:http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf[http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf] > >> http://www.eclipse.org/org/documents/GPL_CE_Policy.php > >> http://www.eclipse.org/org/documents/LGPL_API_Policy.pdfHope that > helps. > > > > -- > > Mike Milinkovich > > [email protected][[email protected]] > > +1.613.220.3223 > > _______________________________________________ incubation mailing > list [email protected] To change your delivery options, retrieve > your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation[https://dev.eclipse.org/mailman/listinfo/incubation] > > _______________________________________________ > > incubation mailing list > > [email protected] > > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > > https://dev.eclipse.org/mailman/listinfo/incubation > > > -- > IBH SYSTEMS GmbH > D-85235 Pfaffenhofen an der Glonn > Läutenring 43 > Geschäftsführer / CEO: Dr. Thomas Heitzig > > Amtsgericht München > Handelsregister Nummer HRB 197959 > USt ID: DE267945175 > > Office Munich > D 80992 München > Agnes-Pockels-Bogen 1 > T +49 89 18 9 17 49 0 > > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or pivileged > material. Any review, retransmission, dissemination or other use of, > or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender and delete the > material from any computer. > > > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation > > > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation -- IBH SYSTEMS GmbH D-85235 Pfaffenhofen an der Glonn Läutenring 43 Geschäftsführer / CEO: Dr. Thomas Heitzig Amtsgericht München Handelsregister Nummer HRB 197959 USt ID: DE267945175 Office Munich D 80992 München Agnes-Pockels-Bogen 1 T +49 89 18 9 17 49 0 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or pivileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
