> I have some questions: > * What license are the devs using for SCL? Sourceforge says the project is > LGPL/BSD, but I wasn't sure if that was a dual license, or if portions of it > were released under one license and portions under another.
The LGPL license is the primary license for BRL-CAD as a whole, which is why you see it on the sourceforge page. Our build system is BSD licensed. SCL is more properly regarded as a subproject we include for build convenience - it happens to be the primary repository for us since as far as we knew at the time we were the only interested developers, so we haven't yet made a separate project for just the SCL. > http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/step/CMakeLists.txt?revision=43301&view=markup seems > to imply that SCL is (C) US ARL, which does not make sense to me. SCL itself is of course from NIST, and not copyright by ARL. We have added new build logic, both the autotools logic and the newer CMake logic. The CMake logic itself is thus copyright by ARL, but that does not imply that the copyright applies to the remainder of SCL. The status of the broader SCL code is indicated by the COPYING file in our repository - if I recall correctly, aside from build logic the main differences in our repository from the NIST original are the application of all the compile fixes we could scare up or make at the time we imported the repository. The subversion history will show what we did - I tried to make that history reflect the various steps from the NIST code to the current BRL-CAD repository. > * Have you been able to use SCL with modern EXPRESS schemas? I've run into > trouble with most of the ones I've tried with my version of SCL, but I don't > know a lot about EXPRESS or parsers and haven't found the cause. I believe the developer who did the primary development work for our converter found he had to get a newer schema working, but I don't recall the details - I'd have to scan the commit history. > * What are your future plans for SCL? Have you generated all the code you > will ever need, meaning that you won't ever have reason to work on SCL > again? We will definitely have reason to work on SCL - the code base needs quite a lot of modernization (they predate a lot of the modern C++ STL, and we need to scrub out the custom one-off string handling (just to pick one glaring example) in favor of using STL.) In fact, scrubbing the SCL code was one of our proposed GSoC activities. I'm currently exploring options for how to approach SCL from a code generating standpoint - personally I loathe including machine generated code in repositories for anything except bootstrapping and have been exploring cross platform ways to integrate the code generating process into the CMake build. That's got a ways to go (I'm currently learning about the re2c lexer and lemon parser, which both seem to be cross platform and may be a way to move the express lex/yacc logic to something we can use on Windows). I think our step-g converter is currently using a tweaked version of SCL's generated code, but that's not what we (or I at least) want to do long term. BRL-CAD is moving to it because we must support MSVC Windows building and CMake allows us to do it from a single set of build files. Going forward BRL-CAD will be using CMake to build SCL, so from our standpoint our SCL autotools build logic is on its way out. > Or do you intend to support more or newer STEP APs? It's not an immediate short term goal - 203 is our main focus at this time, but certainly others are of longer term interest if they describe geometry (214 I believe is one of the others...) > If the former, I'd like to integrate your work on SCL into my project - > assuming the license is compatible. I'm not recalling anything we put into the SCL code that would dictate LGPL licensing - certainly we haven't tossed an LGPL on the whole of our version of the NIST repository. I don't recall if we made any non-bug-fix changes that might raise the issue for any code in there. Certainly the build logic is BSD license - that's standard for all BRL-CAD's build logic that we have written. If there is any concern I can check with our project lead to confirm that our SCL is BSD clear. > If the latter, perhaps we can collaborate. We are certainly very interested in collaborating! > Thomas Paviot, who created > OpenCASCADE Community Edition, rounded up a group of people interested in > SCL. The group includes people who help run PDES and CAX-IF - if we get SCL > to work with new schemas, there should be a lot of people willing to test > and improve it. What specific schemas did you want to target? Are they online? Cheers, CY ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
