HN Books @HNBooksMonth

Creating your own foundation is a huge amount of work. I think you would benefit from doing this research, and I'm not going to tell you "don't do it" because it won't be convincing, but I predict that in the end you will not choose to start a foundation.

There's a chapter in Van Lindberg's Intellectual Property and Open Source on this topic. (It ends with a discussion of umbrella foundations like Apache, Eclipse, Software Freedom Conservancy.) Check it out: http://www.amazon.com/Intellectual-Property-Open-Source-Prot...

⬐ japhyr

I've never thought of a nonprofit as a foundation. Are they equivalent?

The primary appeal for me as a nonprofit is declaring unequivocally that profit is not the goal of the project, and to facilitate donations to support ongoing development. I am aware of the need to establish a board; I've been a board member on a nonprofit, and I've been involved with nonprofits in a number of other roles as well.

I think of a foundation as an umbrella organization, much different than a small nonprofit. Is there anything fundamentally off about my understanding?

⬐ Sanddancer

"Foundation" is just a part of a name, in the US at least. There are definite connotations to using Foundation in your name, like those you described, but anyone can use it. Conversely, nonprofits can be of near any side, from a local community entity doing volunteer work, all the way up to big entities like planned parenthood. So, they're not equivalent, and do in fact have tendencies for a large amount of overlap.

Agreed. Nolo books are very basic.

The following is much better and does talk about many corner cases. It also is written specifically for the software-development case.

http://www.amazon.com/Intellectual-Property-Open-Source-Prot...

The book is written by software developers turned lawyers, and provided me with some fresh perspectives on the nature of the law itself.

Legally speaking, merely mentioning it to your boss does not necessarily shield you from a lawsuit. It certainly reduces the likeliness though in my opinion (i.e., have no data).

Further, "employer's line of business" is very loosely defined. If you could share the technical skills between your job and the side project, you are most likely in the same line of business.

Here's a book I highly recommend: http://www.amazon.com/Intellectual-Property-Open-Source-Prot...

⬐ rst

I've got my boss (well, actually the CEO) to sign a paper acknowledging the side project, and disclaiming any interest on behalf of the company. Hopefully, that counts for at least a little more.

⬐ taylorbuley

You have a very progressive boss.

It depends deeply on the project. Some something like, say, an HTTP API wrapper module, MIT/BSD style licenses are quite sufficient. There shouldn't be something patentable there. Apache, unfortunately, isn't compatible with GPL v2.

But if you're building something like node.js, nginx, or Lucene, choosing MIT/BSD is likely a terrible idea. Apache gives huge protections for unforeseen scenarios: automatic property rights assignment for contributions, poison-pill–like protections against patent suits, &c.

I highly recommend this book on Proprietary Information and Open Source: http://www.amazon.com/Intellectual-Property-Open-Source-Prot...

--

Aside — Sean, I took your CS101 class in '07. Crazy running into you randomly here ;)

⬐ SeanLuke

Hi Kenneth!

The job would have be trivial enough to make it clear to everyone concerned that there was nothing patentable in it, I suppose.

As to GPL compatibility, I've seen this play out with the AFL too (I use the AFL a lot). My take on it is: GPL incompatibility with well-designed, modern licenses like the AFL and Apache is not their fault. It's the fault of the FSF for producing licenses with outstanding flaws. As someone firmly in the BSD camp, I'm not too concerned about the FSF's foibles.

⬐ kenneth_reitz

> GPL incompatibility with well-designed, modern licenses like the AFL and Apache is not their fault. It's the fault of the FSF for producing licenses with outstanding flaws.

+100. I love this attitude.

⬐ rbanffy

> It's the fault of the FSF for producing licenses with outstanding flaws.

Please, tell that to Linux users. Now, compare the vibrant ecosystem around Linux with the vibrant ecosystem around FreeBSD and try to think why it happens and what's the difference between them.

⬐ scq

Are you seriously saying that Linux is popular because it's GPL licenced?

⬐ rbanffy

There are many reasons for Linux's popularity. A cooperative environment with little risk of competition is one of them.

This may be a bit more than you're looking for, but Van Lindberg's book, Intellectual Property and Open Source, is pretty good: https://www.amazon.com/Intellectual-Property-Open-Source-Pro...

I found this to be an excellent resource for this topic.

http://www.amazon.com/Intellectual-Property-Open-Source-Prot...

While this has "open source" in the title, it's still an excellent book related to this topic.

Another good thing about this book is that it draws analogies between software source code and law statutes, making it very easy for software folks to understand these legal issues.

I'm conflicted, but against. (Disclosure) I don't have any software patents.

I am also ignorant about a lot of the details.

Can anyone recommend this book?: http://www.amazon.com/dp/0596517963/

The best single work I've read on the subject is Van Lindberg's _Intellectual Property and Open Source_ (http://www.amazon.com/dp/0596517963/). I don't think it's quite "talk to me like I'm a 3 year old" territory -- it assumes a basic understanding of code and property -- but I don't think it's a waste of time.

Intellectual Property and Open Source. It is a must-read for anyone starting a business or working on an open source project.

http://www.amazon.com/Intellectual-Property-Open-Source-Prot...

http://oreilly.com/catalog/9780596517960/