Re: [json] Re: Introduction Date and Function objects to the standard
- Dave Balmer wrote:
> Greg,Agreed. I'd like to see a std for dates as they are very commonly used
> I've given this a bit of thought too, but in the end this would only
> complicate matters exponentially. Making a simple data parser is one
> thing, but adding in a language parser (much less many language
> parsers) on top of that just isn't practical.
and nearly count as a scalar type :) But stick to the KISS principle.
Feature bloat his killed a lot of stds.
- --- In email@example.com, "Martin Cooper" wrote:
>I completely agree. We were unable to use the GNOTE-licensed code in
> On 5/26/06, Greg Patnude <gpatnude@...> wrote:
> > Speaking of the "Good NOT Evil" license -- is anyone interested in
> > formalizing that ? like the myriad licensing already available --
> > GPL, or LGPL, or BSD Licenses... we could call it the "GNOTE"
> > license....
> No, no, no! There are already dozens and dozens of open source
> licenses. There is absolutely no good reason to invent another one.
> Do you have any idea how much legal crap creating a new license
> creates for any company or other organisation that actually wants
> to use the associated software?
either our GPL application, or in our other app that's currently
closed-source. Fortunately, we found a json implementation under a
simpler license, so we didn't have to re-invent it from scratch.
Personally, my big problem with the GNOTE license is: WHO decides what
is evil? Some folks thing gays are evil, while others think that
anti-gay behavior is evil. Some folks think Bin Laden is evil, but
I'm pretty sure he thinks his enemies are the evil ones. Worse...what
is "evil" can change over time, so I might be allowed to use the
software today, but next year my use might be considered evil by the
It's a great idea, but just doesn't work in practice. Basically, it
will either discourage people from using the software, or will
encourage people to ignore or violate the license, whether
intentionally, or due to a disagreement over what is evil. Pretty much
anyone who takes licenses seriously will not be able to use GNOTE
> I'd suggest the Apache License 2.0, which pretty much says you canExcept that Apache License 2.0 code (arguably) can't be linked with
> do whatever you want with the software as long as you keep the
> original license in place.
GPL software, which is unfortunate. For widest compatibility with
other licenses, I prefer the MIT-style license, which is even more
liberal. The LGPL also tends to work well with proprietary and Free
> var dt = new Date("mm-dd-yy hh:mm:ss.ms");Except for time zones.
> Since 99.999% of the dates / times I display in the UI come from the
> RDBMS -- this also made a lot of sense at the time....
> RE: Unix date / time -- not everyone is into Unix... many peopleAs another poster commented, unix epoch is a great transmission
> appear to be using PHP, Perl, and ASP... Personally -- if it were
> 100% Unix / C / Java / ANSI SQL types -- I would be a happy camper...
> but... we gotta provide support for the greatest common
> denominator... not the lowest common denominator...
format thanks to its explicit treatment of time zones. Every language
I deal with in my work uses it (PHP, Python, ECMA-, Action-, and
moving data between web servers, DB servers, and client browsers that
are in unknown locations. The Atom spec does something similar, by
requiring dates to be expressed in UTC.
I'm generally opposed to the inclusion of dates and functions into
limits what can be done with functions as data. No sense in taking a
simple, beautiful spec and complicating it just to satisfy a few edge
michal migurski- contact info and pgp key:
- On 6/3/06, Kevin Smith <yahoogroups@...> wrote:
> --- In firstname.lastname@example.org, "Martin Cooper" wrote:
> I'd suggest the Apache License 2.0, which pretty much says you canNo, that's not the case (and there is no "arguably" ;), at least from an ASF
> > do whatever you want with the software as long as you keep the
> > original license in place.
> Except that Apache License 2.0 code (arguably) can't be linked with
> GPL software, which is unfortunate.
There is a policy in place at the Apache Software Foundation (ASF) that
states that ASF projects cannot have required dependencies on, or bundle,
libraries licensed under the GPL or certain other licenses. What that means
is that whenever you download ASF software, you can be absolutely sure that
there are no "tricks up our sleeve" and you do not suddenly find yourself
using additional software, with incompatible licenses, that you may not have
That is _completely_ different from what you, as a user of ASF software,
choose to do with it. If you want to build an application that includes ASF
and GPL software, that is absolutely fine with the ASF.
For widest compatibility with
> other licenses, I prefer the MIT-style license, which is even moreI'd agree that the MIT license is very flexible, but I'd suggest caution
> liberal. The LGPL also tends to work well with proprietary and Free
with the LGPL in a business environment. But this is getting way off-topic
for this list...
>[Non-text portions of this message have been removed]
> Yahoo! Groups Links