The validity of a scanned signature or electronic keys is subject to interpretation and assessment on a per case basis especially in civil contracts by the diverse legal systems on Earth.
It's not the Clojure community that is behind, it's the legal systems of many countries that did not follow the pace of technology. Some will not recognize scanned signatures at all. On the other hand, original hand written signatures are recognized almost every where. As much as you complain about the paper CA, you should complain about the legal systems of these countries that do not follow US and western Europe attempts to recognize technology changes and adapt to it. You analyze the issue by the wrong end It's not a technology issue, it's a legal one. You could have the best electronic authentication scheme, if it's not recognized by a country's legal system, it's useless in court in this country. If claims rights on contributions not backed by a CA in a valid form as defined in this country, it's a lost case. Big organizations have the tools and budgets to fight in various legal systems out there. Not small open source projects or projects without big sponsors. I understand and approve the requirement of the original hand written signature in this context. That's a real life issue that cannot be dealt with by technology alone. If a national mail system is not able to get reliably an envelope to the US within 4/5 weeks, I would be very concerned about the state of their legal system. Luc > 2012/10/7 Softaddicts <lprefonta...@softaddicts.ca> > > > I do not agree at all with you. Any piece of software that gets used widely > > needs to be maintained with some formal process otherwise there's no way > > to insure consistency of future releases. It gets worse as you increase > > the # of people that can modify code. > > > > Sorry, have you tried reading what people who complain about the CA > submission process > actually complain about? They do not complain about having the CA. They are > not eager to > jump in working on the language. They complain about being shut out from > contributing *anything* > (including documentation and updates to libraries like data.json) by the > requirement > that CA has to be mailed in paper, in the year 2012. > > We have posted examples of projects and corporations that accept PDFs over > email: > Oracle, OpenJDK, Apache Software Foundation, Neo4J. Scala and Opscode found > more creative solutions > that use OAuth and similar techniques. > > As far as the number of language designers, I think there is little > disagreement that the number Clojure has right now > (1 or 2, with some influence from maybe 5-6 more) is about optimal. There > is much more to success and adoption > of Clojure than just language features, design, consistency and other > things that may benefit from this "tight grip". > > > > > > Tickets may seem to you as overhead but it's a decent way to track issues > > and > > fixes according to release plans. > > > > Looking at a bunch of commits in git is limited compared to dedicated > > ticket logging solutions like Jira. Providing patches attached to the > > ticket links > > the ticket to the code in git is much more usable. > > > > Refusing pull requests is a way to force issues to be logged in Jira. > > The main entrance gate is in Jira, not the other way around. > > > > > This is all handwaving. You can use a bug tracker and plan the hell out of > releases on github. > Many projects do so. However, how quickly contributions are accepted > matters a lot for smaller improvements > like the Jay's example. > > Go take a look at repositories under github.com/clojure, you will find > 10-20 people contributing small improvements > and being rejected every single month. Do you really think most of them > actually will come back? Do you have the > guts to say they should not be considered valuable members of the community > because of that? > > If you make something difficult or time consuming, people will do it less. > > > > Clojure is not the only open source projects driven by a ticket reporting > > system. > > > > This may look as overhead to you but it is still lighter than similar > > processes in many software businesses. > > > > You can report the kind of problems you highlighted on the mailing list > > so at least others can take ownership of the issue if you do not feel > > inclined to post it in Jira. > > > > It's about even having a chance to participate. JIRA and patches are > annoying to anyone who has used github for > at least a few months but it is not really a big deal to anyone I know who > is unhappy about the situation. > > It is all about the fact that if you do not live in North America or > western Europe, you are shut out of the game. > And the reason why CDS distances itself from Clojure/core and the existing > process as far as possible is to at least give Clojure users > a chance to help with the biggest pain point: documentation. > -- > MK > > http://github.com/michaelklishin > http://twitter.com/michaelklishin > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
