Re: Are programming languages suitable for Apache?
On Sun, 8 Jan 2023 at 08:08, Vladimir Sitnikov wrote: > > You are right about that, and I think that ultimately could prevent it > from > > happening > > Can you elaborate? > > Suppose Apache Bicycle project takes the current Elm code in a source > form and evolves it. > It should be pretty much possible. > > BSD-3 code may be included in Apache projects. > BSD-3 does not forbid modifications. > Eventually, the newly added files (and completely rewritten ones) > would be licensed under Apache-2. > To elaborate, I was under the impression that copyright ownership of code had to be transferred to Apache, so thinking that is unlikely to happen so would be a deal breaker. But your comments on BSD-3 compatability are illuminating, thanks for the explanation.
Re: Are programming languages suitable for Apache?
On Sun, 8 Jan 2023 at 11:12, Justin Mclean wrote: > The BSD license is compatible with the Apache license, so there are no > license or legal issues here. However in general, the ASF likes to play > nice with other communities and not have hostile forks. You would need to > come up with a good case to get the project accepted as an ASF incubating > project. > The intention is not to create a hostile fork, and things are not being driven by an acrimonious split in the community. I should also clarify for the record that I like and respect Elms BDFL a great deal and view the whole thing in an almost entirely positive light. Its a great piece of software; a well rounded vision and a lot of hard work has gone into making it so. The issue that is beginning to force a fork is that Elm is not really maintained. The 0.19.1 release came out in 2019, and there has been nothing since. The usual argument is that as a compiler and language, rapid change is not needed or appreciated, which is acceptable and certainly has benefits in providing a long term stable platform to build on top of. The difficulty is that there are bugs in the compiler and core packages and some of those have had patches submitted as pull requests on GitHub - none have been merged for around the last 4 years. Generally speaking, this has not been too much of a problem. Certainly every time I have hit a bug I have always managed to find a workaround and the severity of the issues has not been bad. But there is the ever present risk of hitting bugs and having no way to fix them. My expectation of a well run open source project, would be that patches are reviewed and accepted/rejected. Even if the feature set of a project does not evolve quickly, it is reasonable to expect a series of point releases that incorporate the acceptable contributed bug fixes. My view is that a business relying on a piece of open source software should always consider what the route to getting issues fixed is, and in this case it simply feels like a dead end. Every 6 months or so it crops up on the Elm Discourse forum, is discussed at length, and nothing changes. Working as a software architect I feel that as much as I like Elm, I would be dishonest if I did not score it as a DIVEST on a technology road map, due to these risks and uncertainty around its maintenance. Not to be too critical of the Elm BDFL though, he has a young family so perhaps has less time on his hands that he used to, and has also explained his perspective on things which is that he does not really enjoy this kind of working in public, and having to engage with forums and chat where strangers can make endless demands of him. We have to accept that we cannot force him to work in ways he doesn't want to and respect his choices. Hopefully this gives a truthful picture of things, though obviously this is my personal take on how things are with Elm.
Re: Are programming languages suitable for Apache?
On Sun, 8 Jan 2023 at 15:59, Vladimir Sitnikov wrote: > See https://dev.to/kspeakman/elm-019-broke-us--khn , > https://discourse.elm-lang.org/t/native-code-in-0-19/826 Yes, this did happen... but I would also qualify it by adding that it should have been very clear that the kernel interfaces are not public APIs and should not have been relied upon. Warnings about this were given in advance and ignored. It was certainly clear to me, and I have succesfully upgraded code through Elm 0.17, to 0.18 to 0.19 - there has even always been a nice `elm-upgrade` tool to help with some of the drudge work. We should also infer from the 0.18 version number and conventions of semantic versioning that 0.19 did not have to be backwards compatible. But in the same light, production work based on 0.19 is taking the exact same risks. Quite often the Elm community asks for the current 0.19.1 version to simply be re-published as 1.0.0. The quality of it is easily good enough to be a version 1, and there community is large enough and contains more than sufficient talent to maintain a version 1.
Re: Are programming languages suitable for Apache?
On Sat, 7 Jan 2023 at 13:32, PJ Fanning wrote: > One thing to be aware of is that the license on Elm Compiler is BSD > 3-clause license [1]. Generally speaking, the ASF would require the > code to be granted to the foundation, including permission to change > over to the Apache 2 license. In a community split scenario, this > might not be feasible. > You are right about that, and I think that ultimately could prevent it from happening. I don't think the BDFL has any intention of giving up ownership of the code.
Re: Statements from Qpid mentors would help me decide... [WAS Re: [VOTE] Apache Qpid Graduation as TLP]
I don't mean to be secretive so I shall clarify things for you. I have provided consultancy to JPMC and this did relate to Qpid, particularly helping some of their teams to get set up with it. However, I have never been covered by a corporate CLA but signed it as an individual contributor. This was because I was not ever an employee of JPMC but provided consultancy through another company. Our contract stated something along the lines of JPMC specify what it is that they need, but is up to the contractor to decide how, where, when this is fulfilled (in order to make it clear that I was not an employee). In other words, I chose of my own independent free will to recomend Qpid as a solution for them, and contributed to it as an independant entity to further our mutual aims, rather than being employed specifically to work on it. I have finished consulting for JPMC but am still a committer to the project. I have an active interest in other customers who could benefit from free and open middleware especially where the interoperable and open nature of AMQP could be used to their advantage. I also have an ongoing interest in developing some testing ideas based on aspects of model checking, as I wrote the junit-toolkit, and am interested in ways in which logic programming can be used to generate and evaluate test cases. I'm currently an active committer and fully independant at the time of the proposed graduation. Hope this helps you make your minds up. Best regards, Rupert On 25/03/2008, Yonik Seeley [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 12:44 PM, Robert Greig [EMAIL PROTECTED] wrote: On 25/03/2008, Robert Greig [EMAIL PROTECTED] wrote: Let's drop the legally qualifier from independent... this isn't the IRS :-) In that case I would claim that I am also independent. Although I work for JPMC I am not paid to work on the Qpid project and all my contributions for the last 14 months have been in my own time. As anyone can see from my public LinkedIn profile, I am an architect for the cash equities business. That's cool. I'd much rather have people put it all out there and let others decide (full disclosure). Intersecting affiliations should be disclosed IMO. Doesn't matter what that affiliation is... working for part time, full time, indirectly, an indirect client of, working on site, whatever. The whole secrecy thing is strange. Is Rupert one of those guys who can't reveal his affiliations (including people he works with and end clients, not just middle-men)? -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
