On Wed, Jul 4, 2012 at 11:32 AM, David A. Wheeler <[email protected]> wrote: >> LOL, I prefer git to anything else for that matter. Tell me how to >> clone your git repo and I'll send you git bundle files or whatever (or >> if you can arrange to get me a publicly-accessible repo I can push to, >> that's better). > > Excellent, we'll switch to git. > >> I have a github account but it's not pure FOSS so I >> guess you might refuse to consider it. > > I'd really rather use a system with a FLOSS implementation. I'll work with > projects that are already on github, but that's different. > > I'll probably switch to SourceForge 2.0 (Allura) first, then switch the CM > system to git. I think that would be a far gentler transition than the > alternatives. It may take a few days because of the US' July 4th holiday, > but I wouldn't expect the transition to take long. If you hate that idea, > please let me know. > > By the way, I just added a "screenshot" to the SourceForge web page: > https://sourceforge.net/projects/readable/ > For a text processor a screenshot is slightly silly, but maybe not... it does > show the point. > >> As for the project... unfortunately it may have some application to my >> day job, and my employer might want it (employment contract makes >> employer claim ownership of anything I make during term of employment >> that appertains to (and a half-dozen other legalese) any products >> tools (and a half-dozen other legalese) that the employer deals in). >> So I'll see (in a month, maybe) what my employer says about making it open > > I completely understand. Well, we'll collaborate to the extent allowed. > >> - I prefer a GPL for it myself > > For applications I prefer GPL as well. But for libraries like this, where we > want maximum acceptance/use, I think MIT (or LGPL) would be a better choice. > We're already fighting against a mindset by many people that "S-expression > syntax cannot be improved on"; having to fight licensing too would not help > adoption.
Employment contract doesn't cover work that has absolutely no bearing on my work at the company, and I think we can reasonably strongly claim that (since the company doesn't deal in Lisp) any sweet-expressions work I do isn't going to need copyright disclaimer (although the FSF still recommends that you get a copyright disclaimer nonetheless, just to make it really sure). I agree with the licensing strategy for sweet-expressions. > >> (it *might* be an important >> advance in my day job, especially if I can keep it free as in >> freedom), and might very well not make it at all if my employer >> refuses to disclaim any copyright interest or FOSS it. But at least >> sweet-expressions get *something* as a side effect even if it doesn't >> pan out (at the very least, I expect a 0.3 release of the spec from >> our recent discussions). > > An improved spec is certainly useful. And if you can't get them to release > the implementation, perhaps they can agree on releasing test cases. A big > set 'o test cases would help increase the likelihood that (1) we all > understand the spec's implications and (2) the implementation actually > implements it correctly. Company doesn't deal in Lisps, so I think I might personally safely release simple test cases for the sweet-expressions reader. Sincerely, AmkG ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/readable-discuss
