The YAGNI non-license

I appreciate the punk rock implications of “POSS (Post Open Source Software).” (Back story: @monkchips, Luis Villa and my previous post). But it's not just punk rock, it's also an accepted engineering strategy.

“You aren’t gonna need it” (acronym: YAGNI)[3] is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.[4] Ron Jeffries writes, “Always implement things when you actually need them, never when you just foresee that you need them.”[5] The phrase also appears altered as, “You aren’t going to need it”[6][7] or sometimes interpreted as, “You ain’t gonna need it”. YAGNI is a principle behind the XP practice of “do the simplest thing that could possibly work” (DTSTTCPW).

Do you really need to attach an open license to your source? How do you know? Why can’t you just make your source available in a completely unfettered form such as a Github public repo?

Doesn’t that form of publishing demolish any future copyright claim you might make? Let’s say you put a project on Github. Somebody forks it, somebody else forks that, before you know it your code is part of somebody else’s product. Now you sue the people who make the product for copyright infringement. Do you really have a case?

You can cause trouble, but it’s hard to imagine you winning. And if this isn’t true, can you tell me of an example of contradictory case law?

The no-warrantee component of the BSD license is similar. BSD basically says “do whatever you want with this code but don’t sue me if it doesn’t work.” But has anybody ever actually tried to sue?

Let’s say you put a half baked piece of code on Github and a developer who works on medical equipment copies it into the code for a defibrillator. Time passes and then, one day, somebody in the emergency room is on the verge of dying. A doctor juices up the defibrillator to heroically save the patient. And then a bug in the original code causes the defibrillator to explode, killing the patient on the spot.

The no-warrantee component of BSD prevents the patient’s family from suing the original developer, you, for posting negligent work on Github. But are they really going to do that? If they are anguished enough to actually try is there any reason to think they’ll win? Wouldn’t it make more sense for them to sue the defibrillator maker? So what purpose does the no-warrantee clause serve?

Category: Uncategorized 3 comments »

3 Responses to “The YAGNI non-license”

  1. spacer
    Luis
    February 1st, 2013 at 9:02 am

    The proper lawyer-y response to that is here: lawandlifesiliconvalley.com/blog/?p=708

  2. spacer
    Lucas Gonze
    February 1st, 2013 at 11:15 am

    But then again the law is in service. It comes second.

    That article makes two points:
    1) no license hinders broad use of their code because corporations won’t use it
    2) liability for average quality, fitness for purpose, indemnity

    I’d ask you, as a specialist, whether these are really show stoppers. Corporations’ conservatism might be considered to be their problem by the coder. And is there any history of open source developers losing in court over the article II liability?

    My gut instinct is that only the first issue matters.

    An open source developer will limit their success in the short term and long term without a license. That meets the the YAGNI test. If there are immediate bad effects of not having a license, get a license.

    But the article II liability seems like a very long shot.

  3. spacer
    gurdonark
    February 4th, 2013 at 8:28 pm

    Such a non-license YAGNI approach causes more hassle than it solves. A liberal license or public domain dedication is simpler, I think, and the feature bloat, if any, is just a few characters (cc-0 or PD, say). I do not favor YAGNI in licenses, but do favor it when it comes to feature bloat in DAWs


Leave a Reply



↑ Back to top

     

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.