Frank, What is the current status of the license for GetPot? I think one reason we're maintaining our own fork is because of licensing changes in GetPot. Is there any chance the license is going to change back to being more open in the future?
I understand and respect your wishes to not have your software used in military areas... but you have to see that this creates problems for the rest of us that are creating general libraries that use getpot... and these libraries might be used in military applications by someone else (even if they aren't by us). Also... the license change makes things tricky for merging back in changes from forks such as ours. How are you handling copyright with things like the additions Roy, Karl and even myself have made in libmesh under the LGPL? I don't think you can take our LGPL licensed code and just use it in your modified LGPL licensed library. If mainline Getpot used a regular LGPL license this wouldn't be as much of an issue (although there is still a copyright issue with using our code... but that is as simple as saying "pieces copyright so and so" at the top or asking us to sign over copyright to you. Derek On Apr 23, 2010, at 11:45 PM, Frank-Rene Schäfer wrote: > Hello LibMesh-Team, > > The integration of proposals from other people takes a little longer > than expected; So, please excuse the delayed integration of your > branch of GetPot. > >> One of the features in the libMesh GetPot fork is the templated read, >> which gives us support for any data type with a operator>> defined. >> We use our own specialization for bool, since operator>> won't handle >> all the "true" and "True" and "TRUE" and ".true." sorts of variants >> people might use. Should we extend that specialization to support >> "0" >> for "false" and "1" (or even any non-zero integer/number) for "true" >> as well? > > I need to have a look at your particular changes. Claire and Vivien > proposed a bool type for GetPot. In the new version you will be > able to define per macro a string "YES yes 1 OK" which lets GetPot > interpret "YES", "yes", "1", and "OK" as boolean 'true'. > >> (yes, a libmesh user here just got bitten by assuming that ints >> converted to bools in input files the same way as in code) > > I'll be glad to get your feedback on the new version; Please, feel > free > to criticize any error prone design flaw. > >> Either way, should we throw an exception instead of returning Default >> when an unconvertable string is encountered? Returning defaults when >> options are missing is a brilliant way to work, but returning >> defaults >> when options are unparseable seems excessive. If a config file has >> "some_val = trrue" or "some_val = faalse" in it, and someone requests >> a bool (or anything but a string or char*) for some_val, we ought to >> be able to flag that as a syntax error. > > The new version will allow to throw exceptions; You can throw > exceptions > by default, or explicitly requesting them for each function call. > > Stay tuned. The good news is that the changes are integrated. What > remains are a couple of bugs to be fixed, a unit test update and > documentation work. > > Best Regards > > Frank > > > > -- > // Frank-Rene Schäfer > > ------------------------------------------------------------------------------ > _______________________________________________ > Libmesh-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
