What's a good license for My Library?
in [JavaScript]
|
From: Chris Riesbeck on 6 Jan 2010 13:26 Lasse Reichstein Nielsen wrote: > Jorge <jorge(a)jorgechamorro.com> writes: > >> On Jan 5, 1:38 am, David Mark <dmark.cins...(a)gmail.com> wrote: >>> I've decided to release My Library under some sort of free license. >>> Haven't thought about free licenses in a long time (decades), so I am >>> open to ideas. >> "The Software shall be used for Good, not Evil" ? > > Bad idea. It lacks a definition of both "Good" and "Evil", making the > license ambiguous, and if it had one, it would probably run afoul of > the Open Source Definition (6. No Discrimination Against Fields of > Endeavor). but with an "or" instead of "and not" it's OK, right? http://nehararora.com/2008/oct/19/fortune-firesign-theater-a-power-so-great/ :)
From: Jeremy J Starcher on 6 Jan 2010 13:56 On Mon, 04 Jan 2010 16:38:30 -0800, David Mark wrote: > I've decided to release My Library under some sort of free license. > Haven't thought about free licenses in a long time (decades), so I am > open to ideas. > > Anything to prevent the exponential growth of JS futility like this;- > > http://github.com/jrburke/blade > > I don't think that thing even warrants a review and there are dozens > more like it popping up. Enough is enough. :) I'd have to agree with many of the others and figure that the MIT/BSD license would be a good shot. MIT/BSD/LGPL only adds a few more letters in from what I can tell. I don't think I'd be too worried about forking, honestly. As I've watched the various open source projects, major forks seem fairly rare and only after other effects have failed. I have no ideas of the legalities concerned, but if you change the My Library name to something that can be trade marked, you can do the same stunt that Firefox did. "You can copy our code exactly, but if you change it you've got to call it something else." Hence Firefox and IceWeasel. That way, we'll have: My Library His Library David's Library The Cowardly Anon's Library Not Your Library and the like.
From: Lasse Reichstein Nielsen on 6 Jan 2010 14:19 Chris Riesbeck <Chris.Riesbeck(a)gmail.com> writes: > Lasse Reichstein Nielsen wrote: >> Jorge <jorge(a)jorgechamorro.com> writes: >>> "The Software shall be used for Good, not Evil" ? >> Bad idea. It lacks a definition of both "Good" and "Evil", making the >> license ambiguous, and if it had one, it would probably run afoul of >> the Open Source Definition (6. No Discrimination Against Fields of >> Endeavor). > > but with an "or" instead of "and not" it's OK, right? Only if Good and Evil encompasses all uses. Morally neutral uses must be allowed as well ... if such exists. > http://nehararora.com/2008/oct/19/fortune-firesign-theater-a-power-so-great/ I like it :) /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Garrett Smith on 6 Jan 2010 17:12 David Mark wrote: > On Jan 6, 6:36 am, Matt Sach <matts...(a)gmail.com> wrote: >> On Jan 5, 10:57 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> >>> As for the "goals":- >>> * Mobile is more important than Internet Explorer >>> Apples are more important than oranges? :) >> I think "lemon" would be a more appropriate citrus fruit to represent >> IE ;) Sure, but having goals and writing them down has fundamental value. That way everybody knows what it is. It is worse to not have goals than to have bad goals. Bad goals can be changed. >> I've been >> trying to push them myself, in order to get them thinking and learning >> (not necessarily from my tutelage; I'm certainly nowhere near you and >> others here), but it's very difficult to get folks to learn when they >> have an "easy" way out that they already know. > > All you have to do is demonstrate how it fails. :) As for help doing > that, it's coming (is it ever). For anyone who hasn't seen the signs, > cinsoft.net is going to be the new quirksmode.org (for libraries and > frameworks, rather than browsers). Oh, and with competent > explanations. :) > Sounds good. You can try organizing and aggregating: Juriy's tests: http://github.com/kangax/jstests Sputnik tests: http://code.google.com/p/sputniktests/ Hixie's tests: http://hixie.ch/tests/evil/mixed/ Those could all be improved by automation. Significantly Please don't make me click through to every example and don't make complicated test cases (like an functional/example page that has every usage of the property/method). For such a test suite, the relevance of specification is important. Writing a testrunner will take time, but the investment will pay off with managing complexity of testing variance across browsers. YUI Test is not a bad one. You will need to patch it, though, and may want to change many things about the design of it. The asynchronous aspect of YUI Test is an important part that many other test runners or unit test frameworks just totally ignore.. The asynchronous part of YUI Test could be redesigned so that it allows pause between tests, and so that it uses a Timing abstraction (too much setTimeout eats up CPU and crashes poor Blackberry). Also it would be useful to have similar to Selenium `waitForCondition` (so the test can complete before the allotted expiration time). Also in YUI Test, it would be nice t ohave smaller methods. Not only would this help make YUI Test more readable, but when debugging, the developer should not have to step through a 300 line function just to get to where YUI Test has dispatched and event. Oh, it is so painful my fingers hurt just thinking about clicking debugger "step over" that many times. Ouch. YUI can be forked. Submitting but reports to YUI is a waste of time, IME. Just patch and go. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 7 Jan 2010 00:20
David Mark wrote: > On Jan 6, 5:12 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> David Mark wrote: >>> On Jan 6, 6:36 am, Matt Sach <matts...(a)gmail.com> wrote: >>>> On Jan 5, 10:57 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>> As for the "goals":- >>>>> * Mobile is more important than Internet Explorer [...] > I think not. > >> Those could all be improved by automation. Significantly >> >> Please don't make me click through to every example and don't make >> complicated test cases (like an functional/example page that has every >> usage of the property/method). > > No clue what that means. :) > By functional test, here, I am referring to here is a static demo page, like any of the Hixie or Juriy tests. Another sort of functional test is use-case functionality. Selenium is useful for that. Clicking each example is tiresome and doesn't give a comprehensive view of what works and what fails. A functional test that tries to test everything about one specific property is worse because it is not focused on one thing. Unit tests are the well-suited for testing browser features and dom features because each aspect can be tested. insertBefore suite might contain: testReturnsNode, testRefNodeNull, testHeirarchyRequestErr, testWrongDocumentErr, testNoModificationErr, testNotFoundErr. A unit test page can do those things and separate out the test cases to test functions, where each function tests one specific thing, using maybe 4-8 lines of code for each test function. >> For such a test suite, the relevance of specification is important. > > Or that. > Specifications should provide guidance for the outcome of assertions and also can help outline an API. For example, any of the DOM APIs could be tested, ECMA specs can be tested. Such tests would be valuable to me. I believe they could potentially contribute usefull to the w3c APIs. I doubt that anyone in the w3c would be able to see it. I might have had better luck if I had shown them actual test cases. That takes a bit of time to set up. You can see my input to that here: http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0013.html I'm no sure what the status is; I can't follow up because I was banned from the list. >> Writing a testrunner will take time, but the investment will pay off >> with managing complexity of testing variance across browsers. > > I don't need to write one. I have what I need for now. > That's what Hixie said. I still think he's missing something valuable in that. He doesn't (or didn't) see value in it. His acid tests, to me, are not valuable tools that I can refer to to see what works where, etc. His functional tests require a click through to each one are not even indexed that well. Having to click through does not provide a comprehensive view of what fails and what passes because you have to click through to each one, and in each browser, to see those results. What is valuable for me, is to see the appendChild method, see where it fails, and see an example of it. >> Also it would be >> useful to have similar to Selenium `waitForCondition` (so the test can >> complete before the allotted expiration time). > > You are getting way ahead of me. > For example, say you ahve an XHR adapter. The adapter makes a call to the server, and when the response comes, you need to verify that response. A test case wants to test the success of a response. To test that, the test case gets a connection. Opens, sends, and then *waits* for the response. The `success` callback fires asynchronously; it cannot be tested until the xhr is complete. The problem is, we don't know when that will happen. What YUI Test provides is a `wait` method. `wait` takes two arguments: callback, and timeout millis. So what you can do is to wait for a while. The assertions that verify the message of the ajax call are performed in the `wait` callback. test case:- this.wait(function(){ Assert.areSame("a", xhr.responseText); }, 4000); I would like a `waitForCondition` method, so I could, say:- this.waitForCondition(function(){ Assert.areSame("a", xhr.responseText); }, condition); function condition(){ xhr.complete == true; } I don't really like that order, but it is consistent with the `wait` approach. Also, I don't like how most x unit frameworks have expected result first. TestNG (Java) is switched, which makes sense, but inconsistent. >> Also in YUI Test, it would be nice t ohave smaller methods. Not only >> would this help make YUI Test more readable, but when debugging, the >> developer should not have to step through a 300 line function just to >> get to where YUI Test has dispatched and event. Oh, it is so painful my >> fingers hurt just thinking about clicking debugger "step over" that many >> times. Ouch. > > Whatever YUI is doing with their stuff is irrelevant. > If you try the test runner, you might get a feel for the API and about testing. You'll find what you don't like and maybe you might find things that are valuable in it. It is a lot better than JS Unit. The problems in the design of the YUI Test are solvable; it's not like he painted himself into a corner. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |