On Wed, Mar 25, 2020 at 11:24 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
> Erich,
>
> thank you for clarifying!
>
> On 24.03.2020 19:30, Erich Steinböck wrote:
>
> ooRexx only accepts Common Public License v1.0
> You are providing your rgf_util2.rex under ASF 2.0
>
> Removed the AL 2.0, cf. [r12007].
>
> ---
>
> *Please note: whatever AL 2.0 licensed, Rexx related software has been
> authored by me will hereby be licensed in addition under the CPL (Common
> Public License) v1.0. *
>
> ---
>
> There is one principal question in the context of tools though.
>
> The genesis of the above was as follows: while starting to overhaul the
> freshly split rexxpg book I noticed that not only was the text barely
> marked-up, but also that some parts needed updates that depend on the
> version of ooRexx from time to time, in this case the available classes and
> the class hierarchy.
>
> Rather than updating the class hierarchy in the xml file manually I wrote
> a little Rexx script that would ask ooRexx about its classes (in doing so I
> stumbled over a crash-bug that has been corrected in the meantime) and have
> the subclasses always in sorted order by the class' id. This is a little
> tool and I did not want to invest too much time beyond its purpose so I
> used my "rgf_util2.rex" package as it inlcudes a MessageComparator class
> that allows one to sort data of any type in any sequence by sending it
> appropriate messages.
>
> In this case ooRexx Class objects had to be sorted by their name "ID". So
> using the MessageComparator this was just plain simple:
>
> ...
> msgComparator=.messageComparator~new("id / i") -- use id value, sort
> case-independently
> do subClz over clz~subClasses~sortWith(msgComparator)
> ... do whatever is needed ...
> end
> ...
>
> Or with other words: using the "rgf_util2.rex" package made the sorting of
> ooRexx Classes plain simple, in addition it helped saving me some coding
> time, hence using it. Everything at that point was located on my PC.
>
> Then, later, thinking of some comments in the rexxref book where parts
> seemed to had been created using tools (indicated by text like GENERATED
> together with the date of the generation) that cannot be found anymore, I
> thought it to be a good idea for future updates to make this little tool
> available to the documentation project so anyone could use it reliably from
> then on.
>
> After communicating this idea I created the docs/trunk/tools/rexxpg
> directory and copied the script "createClassHierarchy.rex" and as a service
> its required package "rgf_util2.rex", such that everything is in place to
> run the script immediately.
>
> "rgf_util2.rex" was put under the Apache License 2.0 (as all of the
> BSF4ooRexx related code) as I have been on the Apache Software Foundation
> (ASF) and using ASF's BSF (bean scripting framework) which I maintain since
> then (I became a member of the ASF, which is possible by invitation from
> ASF members and after an election only).
>
> For ASF code it is important to put it under the AL 2.0 license such that
> it can be safely and blindly used in any ASF project. (Any code that one
> authors can be put under more than one license in parallel (without losing
> the copyright), if the author so wishes.)
>
> It has been my understanding that tools using AL 2.0 license do not impose
> any threats whatsoever to CPL 1.0 etc software. Hence, I did not even think
> that AL 2.0 would pose a problem to ooRexx. it is my understanding that one
> could even freely use and incorporate such AL 2.0 code into CPL 1.0
> projects without any negative side effects.
>
> ---
>
> Now turning to tools for ooRexx in general in the light of all of this: I
> had suggested that once Gil has finalized his great work on the
> documentation tool chain, that we should store his toolchain with the
> documentation, such that anyone who wants to help the ooRexx project in the
> documentation area would be able to do so immediately by just downloading
> Gil's package and after studying his readme1st.txt file.
> As we are in need and seeking helping hands it is important to make
> helping as easy as possible, also in the documentation area.
>
> If we look at the mix of tools there are all sorts of licenses that get
> used there. AFAICS at the moment no single license there would pose a
> problem on the ooRexx project.
>
> So my question is: what about tools that are needed to create the
> documentation that do not license CPL 1.0, but use licenses that do not
> infect the ooRexx license, can the be hosted with appropriate attribution
> in the ooRexx project?
>
Use of any of those tools are not an issue anymore than using gcc or other
similarly licensed tools to build ooRexx is an issue. The difference here
is that once you have checked the source of rgf_utils2.rex into the svn
repository, it becomes part of the project and must have a compatible
license with the rest of the project.
Rick
> ---rony
>
>
>
> On Mon, Mar 23, 2020 at 7:14 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
> wrote:
>
>> Hi Erich,
>>
>> On 22.03.2020 11:56, Erich Steinböck wrote:
>> > I agree with Gil. Let's stay with our current coding/tagging style and
>> the typographic conventions.
>> I concur as well, see my follow-up to Gil's mail.
>> > Also, rgf_util2.rex is unacceptable for inclusion in our svn. Please
>> fix the copyright or remove
>> > it from the svn, and please also do so for any other of your current or
>> future commits.
>>
>> What is the problem (I really do not understand)? What constitutes a
>> "fix"?
>>
>> ---rony
>
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
