On 1/23/20, G. Branden Robinson <g.branden.robin...@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.kl...@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-contributor-license-agreements/ > <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. _______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
