Re: [Libmesh-devel] GetPot design questions

[Derek G. <fri...@gm...>]

Unfortunately, that's not good enough Frank.  The reality is that some
of us work for the government and they will never allow our software
to have a license that restricts military usage.  Moreover, some of us
might feel differently about military usage than you do. Personally,
I'm proud when my software helps the country I love stay safe and ward
off enemies...

Anyway, this isn't a philosophical debate... I'm glad that I now
understand that you're not willing to change the license.  It helps
with our planning going forward.  I do hope you understand what this
means for your project: ie there will always be a more "free" fork of
your code with other features in it that you _can't_ merge back into
your main code.  It might even be the case that this fork grows more
popular than your own project (although I doubt it).  As long as
you're ok with that, then your reasoning is perfectly valid... But if
you think you can restrict our freedom just to try to impose your
personal beliefs AND still benefit from the work of others, you are
mistaken.

On the one hand you talk about dead babies and on the other you
personally restrict freedoms... Maybe we're not the ones that have
thinking to do.

Derek

Sent from my iPad

On Apr 28, 2010, at 5:21 AM, "Frank-Rene Schäfer"
<fs...@go...> wrote:

> I made this point many times; Your comment indicates that
> I should make this point in a more central position. Thanks,
> for your request. So here is my statement about 'military exclusion':
>
> There is no license for projects that explicitly target military purposes.
>
> Explanation: If you produce a pillow to
>     -- put your head on it,
>     -- to warm a but and
>     -- to suffocate people,
> then there is no license for you--because of the third purpose.
>
> If you produce a pillow with all kinds of purposes in
> mind that does not include killing people, then you have a license.
> You are not responsible, for some people doing mischief with it.
>
> If you produce a pillow for purpose A that has nothing to do with
> military and military uses it with purpose derived from 'A' to kill
> people, then that is also not your responsibility.
>
> Best Regards,
>
> Frank
>
> PS, another reason to put the software under military exclusion
> is to make people ponder about the consequences of their actions.
> The mother that cries with hear dead child in her arms is far away
> from the engineer who designed the missle that hit her house.
> Nevertheless, the engineer is part of the causal chain that caused her
> misery.
>
> 2010/4/27 Derek Gaston <der...@in...>:
>> 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
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>
>>
>
>
>
> --
> // Frank-Rene Schäfer
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel