Does this BSD-like license achieve what I want it to? [closed]

Question

I was wondering if this license is:

• self defeating
• just a clone of an existing, better established license
• practical
• any more "corporate-friendly" than the GPL
• too vague/open ended

and finally, if there is a better license that achieves a similar effect?

I wanted a license that would (in simple terms)

• be as flexible/simple as the "Simplified BSD" license (which is essentially the MIT license)
• allow anyone to make modifications as long as I'm attributed
• require that I get a notification that such a derived work exists
• require that I have access to the source code and be given license to use the code
• not oblige the author of the derivative work to have to release the source code to the general public
• not oblige the author of the derivative work to license the derivative work under a specific license

Here is the proposed license, which is just the simplified BSD with a couple of additional clauses (all of which are bolded).

Copyright (c) (year), (author) (email)

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. The copyright holder(s) must be notified of any redistributions of source code.
4. The copyright holder(s) must be notified of any redistributions in binary form
5. The copyright holder(s) must be granted access to the source code and/or the binary form of any redistribution upon the copyright holder's request.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Answer 1

Setting aside the issue of the practicality of this one, roll-your-own licenses are a bad idea for everyone involved. (Apart from lawyers ...)

Unless you have legal training, you should not attempt to invent your own licenses. You may think you know what those words mean, but when interpreted by a law court, they may mean something different to what you intend them to. And the licensee of your software would have the same problem. They would have to talk to their lawyers to get an opinion on what the license would mean for them and their businesses.

If you are lucky, the best that can happen is that lots of potential users / customers will just say "No ... too legally risky". The worst that can happen is that some shyster company / lawyer will figure out how to exploit a loophole in your wording, you take them to court, and you lose big time.

---

The short answer to your headline questions is: Yes, Pass, No, No, Yes, AFAIK No.

Here are some specific problems with your proposed license.

1. The notification clause is onerous on licensees. They are now at legal risk if they accidentally redistribute. That means (if they take this risk seriously) they need to set a compliance system to track their redistributions to ensure that they do send you that email.

2. The notification clause pretty much guarantees that no creditable open source distribution will include your software. The burden it places on them, and on downstream redistribution is simply too great. (And the chances that they will want to help you on this are about zero.)

3. You don't define terms like "notification" and "redistribution". A smart lawyer could probably figure out how to make them mean what they want.

4. Notification of copyright holders is legally problematic for the licensee, considering that the licensee cannot know who all of the copyright holders actually are.

5. You don't mention how the notification would be made. What about the scenario where it is sent by email and the email gets lost? What happens if there is a problem with email at your end? What are you going to do if a smart lawyer demands that you produce evidence that you / your email provider hasn't lost the email.

6. Are you going to expend your time and energy ensure that people comply with the notification requirement? If you don't, a smart lawyer can use that against you. (Read up on "Laches")

---

Finally, you wanted something that is more corporate friendly than GPL. I'd say that this is (in some respects) LESS corporate friendly ... for corporates who are prepared to play by your rules. For example, for corporates who want to be able to ship binary only, clause 5) means they have to grant you unconditional access to any secrets embedded in their code; i.e. no NDA. There is nothing stopping you from exploiting that information, including (for instance) selling it to their competitors.

Answer 2

IMO (3) and (4) are onerous. After all, do you really want an email for every download? Do you want to oblige distributors to create custom FTP/HTTP servers that send an email for every download? Do the other copyright holders want to receive these notifications? If I made an enhancement and distributed the result I'd be signing up for such notifications, and wouldn't want to receive that spam, however, people would be obliged to send it to me anyway. How will parties redistributing the code in source or binary form even assure themselves they have successfully complied with these conditions?

Condition (5) is problematic because "the copyright holders" is going to be a large number of people (potentially), not just the original authors. It is unclear to me how a redistributor can even be certain that they have successfully "granted access" to all copyright holders. That is, I'm not certain that a party acting in good faith can even be sure they're in compliance.

The license appears to be drafted as if you will be the only "copyright holder". That is, it's an attempt at an open source license for a project you're assuming will be unsuccessful as an open source project. In other words, you seem to be assuming that there will be few contributors.

Frankly complying with this license would such a pain in the ass that I'd just prefer not to use the code at all, or even distribute it, even if it did appear to be potentially useful.