On 1/23/20, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
No, that's not what that means. Every FLOSS license, every Free Software license[1] permits private development.
Yes, I'm well aware that FOSS licenses permit private development by definition, and don't plan to release anything in UX/RT under a license that requires publication of changes (most of the first-party servers and commands will be under GPL2, and most libraries will be under MIT, BSD, or Apache licenses; anything derived from third party code will fully retain its original license).
Experimental code is just that, and happens all the time in both professional and personal development environments. We all write toy programs or slapdash implementations to develop and verify our understanding of the systems we're creating or interfacing with. Or, frequently, to discover the undefined behavior of the C compiler we're using. :P
Student projects are a case of this written large. Not everybody wants the code they write in their novice years to be unleashed upon the world. In the case of UNSW's AOS (Advanced Operating Systems) course[2], which is seL4-based, the students are discouraged from sharing their solutions to the project milestones because doing so would frustrate the educational objective of the course. That is, the course directors would have to redevelop it every term and that would make them unhappy; also, you'd eventually run out of well-understood operating system concepts with which to easily evaluate their solutions. Fortunately, since the AOS course builds _on top of_ instead of altering the seL4 kernel, this does create a GNU GPL section 7 problem[3].
That kind of thing is understandable.
If you're thinking of skunkworks-style projects, or secret modules that get released only to paying customers, then Gernot can answer with certainty but I can tell you that I've neither seen nor heard of any such thing in the year I've worked at the Trustworthy Systems Group; that proprietary work product is opposed to the mission of the lab as I understand it; and that such a thing is not congruent with the workplace culture and opinions of staff.
That is good to hear. I was worried that there was quite a bit of development going on behind closed doors.
However, I've gathered from encountering you on mailing lists over the past few years (no stalking, we simply seem to have similar interests :) ), that you're a lone developer working on a personal project. If you tried to impose a CLA on people I think you'd meet with a lot of resistance. And any contributor who valued their contribution would be pathologically selfless to assign copyright with no strings attached.
Yeah, it would be pretty much suicidal as an individual developer to impose a CLA on third-party contributions.
I think that if and when you can come to seL4 engineers at Trustworthy Systems with concrete use cases and measurable problems, they'll be happy to gnaw on the problem with you. It pays to remember that much of the staff are academics. Solving problems in microkernel performance and scalability, or showing how something once thought to be only achievable in a kernel can be done efficiently in user space, leads to conference papers and journal articles. They like that.
Yes, it's still quite early. Getting to real userspace is my only real priority at the moment, and I'm trying to avoid premature optimization. I probably won't bother to optimize all that much until it's capable of self-hosting. Once it's mature, I would like to see UX/RT become popular as a platform for research on OS subsystems and components, even though I'm intending it to be a production system and not a research system as such. I'd like to be able to incorporate such research into the mainline when it's reasonably possible. On 1/23/20, Klein, Gerwin (Data61, Kensington NSW) <Gerwin.Klein@data61.csiro.au> wrote:
Because CLA sounds scary: Currently we still have the CLA process, but we’re hoping to move to something simpler and less legalistic in the future: a Developer Certificate of Origin [see e.g. https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contrib... <https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/>].This is exactly the process that Linux uses for contributions.
That sounds good. I'm planning to have a Linux-style DCO for UX/RT contributions once it's more established and there are other people contributing.