Skip to content

Pick a real license #31

Closed
sarahgerweck opened this Issue Sep 4, 2013 · 5 comments

3 participants

@sarahgerweck

I'd like to strongly urge you to read up on open-source licensing and actually pick a license. As an open-source developer, it's extremely important that you familiarize yourself with the basic licenses and use one that's been legally vetted.

Technically, your current position of "no license" means that nobody is allowed to use this software except you: copyright law reserves all rights to the copyright holder except those explicitly granted to licensees.

You make things even more messy when you say "you can do whatever you want" but "you can't take credit for my work." These two statements contradict one another. You have to worry about legal liabilities if you say something like "do whatever you want." (E.g., does that include using it in a medical device? are you prepared for the legal ramifications if someone dies because your software was buggy?) You can be sued if you accidentally imply some kind of warranty.

GitHub is wise to recommend the Apache 2 license to people as the default. It is the most popular "do whatever you want" license. It protects you thoroughly while granting anybody the ability to use anything you published for any purpose—provided the user takes on any risks or obligations. Redistributors are not allowed to remove your copyrights from the code and must retain your NOTICE file. (This is a legal version of "don't take credit for my work.")

If you just want to make your software available for people to use as widely as possible, Apache 2.0 is your best bet. It's extremely permissive while also being defensible enough for big companies like Google to use.

@derekwyatt
Owner

Thanks Sarah. You're probably right... and that annoys me; not because you're right, but because software licenses annoy the hell out of me and I shouldn't have to do this. But, when you're right, you're right.

It shall be done.

@sarahgerweck

Sorry to be the bearer of bad news. :-) I totally understand the feeling (though I personally find the law quite interesting).

My personal advice is just to spend an hour looking through the most popular licenses and then pick one and basically use it for everything. The Open Source Initiative has a good list of licenses.

If it helps, my (non-attorney) view is that you have basically a choice between four licenses, all of which probably adequately protect you against lawsuits. There are some other licenses out there, but these four basically cover all the realistic open-source scenarios, and there's a considerable benefit (both to you and your users) to using one of the well-known licenses.

  • Apache 2.0: Code be used for any kind of project. Users must retain copyright information. Author grants permanent license both for code and any patents.
  • MIT: Can be used for anything with no restrictions of any kind (other than liability limitations).
  • GPL: Can only be used in open-source projects. You want to share your code, but you don't want it used as part of any professional project.
  • LGPL: Can be used in closed-source projects, but any changes to the specific module or library must be open sourced.

Personally I use the Apache 2.0 license almost exclusively and I'd never advocate for the GPL, but I do advocate that developers should understand these major licenses. OpsCode wrote up a good treatment of why they chose the Apache 2.0 license.

@Blaisorblade

@derekwyatt, GitHub created http://choosealicense.com/ for users in your situation.

I think @sarahgerweck's post makes sense, but maybe that helps.

Your current text seems closest to MIT but Apache2 would probably improve over that.

@Blaisorblade

@sarahgerweck, I assume BSD software can be incorporated in software with either MIT or Apache 2 licenses, right? This bears on #33, since scala-dist is BSD-licensed.

@sarahgerweck

BSD-licensed software can be basically incorporated into anything as long as you keep the copyright notices in place. However, if some organization had a policy that all source files had to have some kind of uniform copyright notice, they'd have to get your permission to remove your original copyright notice. (This is probably what you'd want anyway.)

As long as you still hold the copyright, you can always grant individuals or groups permission to use it under a different license if they need to for some legal reason. However, some licenses effectively prevent you from revoking that permission later on. (E.g., the Apache license effectively guarantees that people can continue to use your code and any included patents forever—as long as they do it in a way consistent with the license, don't sue you, etc.)

I'm not a lawyer so of course this is just my understanding of the licensing issues and not professional legal advice. I think you really can't go too wrong with any of the major, well-known licenses: It's just a matter of choosing one that aligns well with your intentions.

@derekwyatt derekwyatt added a commit that referenced this issue Nov 25, 2013
@derekwyatt Fixed issue #31
- Added an explicit LICENSE.TXT file that states the Apache 2 license
16e9f9d
@derekwyatt derekwyatt closed this Nov 25, 2013
@ornicar ornicar added a commit to ornicar/vim-scala that referenced this issue Dec 18, 2013
@ornicar ornicar Merge branch 'master' of git://github.com/derekwyatt/vim-scala into HEAD
* 'master' of git://github.com/derekwyatt/vim-scala: (24 commits)
  Added annotations and dots to case matches
  Some syntax fixes
  val,var and def names are now Statements
  Update README.md
  Enhanced calls to constructors
  Added backtick literals and digraphs for 'specials'
  I forgot comments (?!)
  Refactoring the syntax file
  Reverting 'fix' for issue #28
  Fixed issue #37
  Fixed issue #34
  Fixed issue #31
  Fixed issue #28
  Simple fix to keep it to 80 columns
  Enhanced syntax to handle string interpolation
  Add spec for multiple newlines
  Convert readme to markdown
  Add more specs
  Adjust travis emails
  Add more fixtures
  ...

Conflicts:
	ftplugin/scala.vim
	syntax/scala.vim
60eb195
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.