Preferred Open Source License


#1

I was asked on the other forum if I would consider using an OS license other that the GPL.

Truth is, I hadn’t really put that much thought into the choice of license.

Which leads me to a few questions for the community:

  1. What are your views on the pros/cons of the various OS license models?

  2. Do you have a preferred license?

  3. Is there a license you would refuse to work with?


#2

I prefer the BSD-style licenses because they are “more free,” in that they don’t limit the kinds of re-use allowed. I do understand why GPL-style licenses are in use. BSD licenses mean you are free to be a jerk and lock away your improvements.

Not being a developer myself I’ve resolved to just abide by the author’s choice–but when I do give away things online, my personal choice is to give them away without strings attached.

There is no license I know of that I would refuse to work with, but I also don’t know a lot about the field other than the general BSD/GPL division.


#3

I use MIT license on my own things when I have the option. It’s my preferred license, by far.

Most everything I do personally (as in not for work), if I release it publicly, then I don’t care what anyone does with it. If they share back, fine, if they don’t, fine. If they use it to make something else, great. Even if they make money off it, I just don’t care. To me it just doesn’t matter. I released it open source so other could use it. I just don’t want to be blamed for anything, so I use MIT license.

Whatever license you decide to use doesn’t really matter to me, I’ll still help out if I can. I know a lot of folks won’t want to if it’s GPL, but I’m not sure that will really matter in the long run. You’ll probably get enough help either way.


#4

This type of discussion can definitely set off some healthy debate, with a fair number of people entrenched on both sides of the GPL.

From my personal perspective, my philosophies and world view tend to be founded on libertarian principles. I’m a live and let live kind of guy, as you long don’t tread on my ability to live as I choose, and my choice doesn’t tread on you… I’m not big on forcing my will onto others.

That would seem to rule out a GPL type license, right? Well, not really. Because if its my work, I should be able to set some rules on how the world uses it. If the world doesn’t like the license, and does not want to live by it, they have the choice to not use the work that is covered by it.

I also am a big believer that competition drives innovation. And, innovation thrives when it is least impeded by artificial restrictions. In that regards, ‘more free’ licenses, like MIT, are attractive because they protect the original developer while liberating others’ from those artificial restrictions.

Perhaps if the goals of this project are laid out, and the licenses compared against achieving those, it will be easier to divine a solution.


#5

I think the GPL is an anti-open source license. I think you should either open up your source code or you should keep it closed. You shouldn’t pretend it is open and then use it as a way of forcing other people to open up their source code. Utilities and libraries under the GPL are poison to a project. Anything under the Affero GPL license is even worse.

One thing that is very telling about the GPL is that they strongly recommend that you do not modify the license and they state that modified versions of the GPL are not compatible with the GPL. In other words, they say they believe in open source, except when it comes to their own license.

I will not touch GPL’d source code. I will use software which has source code under the GPL, but I prefer not to.

When I release source code, it is under a modified MIT license that adds a single restriction (plus a clarification). Nobody can take my code, modify it, and then put it under a more restrictive license. This means it is not compatible with the GPL and nobody can GPL my code. Yes, I realize that somebody can take my work and use it commercially and not release their changes or updates. That isn’t a disadvantage because it encourages innovation. If somebody creates a proprietary innovation on top of my software, it is likely to be one of (1) a huge innovation with a lot of work behind it that the developer deserves to be able to keep proprietary, (2) something small but useful, which will be duplicated by others, or (3) something that nobody except one developer cares about. If my software can help any of those happen, I’m happy. Overall, the pros of actually being open and free outweigh the disadvantages.

There is another approach. You do not force a single license on the entire project. This would allow somebody to contribute a module which is under a license that they prefer. This would take some thought, but I think it would be possible. Not surprisingly, this approach is not compatible with the GPL.

Here is my modified license, in Python source. Of course you are free to take it and even modify it.

license_text = """
__PRODUCT_DESCRIPTION_HERE__

Copyright (c) __YEAR_AND_CREATOR__

Written by __AUTHOR__

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
Every individual file within the Software must include either this
entire copyright and permission notice or one of the following
abbreviated notices which incorporates this notice by reference:

  This software is covered by the copyright and license notice
  in <FILENAME>, which can be considered to be included here by
  reference.

  See FILENAME for license notice.

If you create a derivative work of this software, you are not
required to distribute the source code, no matter how you use
the software. However, if you do choose to distribute the source
code of your derivative work, you may only do so under this license,
modified appropriately to add your copyright and/or authorship
in addition to the existing copyright notice. You may not replace
the copyright notice, substitute a different license, or add
an additional license.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
"""

license_note = """
This license is not compatible with the GPL. You may not incorporate
this software or any part of it, or any derivative work of it, into
any project under the GPL.
"""

def get_license():
    return license_text

#6

The point of the GPL is to make sure private groups will not use our code in a private version to compete with us. That might be an advantage if we want to make sure the users keep benefiting from the efforts made here. On the other hand, that would prevent GF from using our code, because they would have to also open they code.

It would be bad to write a bunch of code only to see private companies sell their custom firmwares using all of our work but not contributing back. But I think it would be good to allow collaboration/borrowing/merging of code with GF official.


#7

I’d prefer not to twist anybody’s arm. :slight_smile:

Looks like my preference here is going to be towards an MIT style license. I am opposed to company’s using code I worked on and profiting from it without returning any contributions. Honestly, though, the GPL isn’t really stopping that, and it seems to have some significant downsides.

That being said, some work will need to be under the GPL as it extends existing code that is already under that license. The bulk of the Yocto board support package I put together for the OpenGlow, and any use of the Glowforge kernel modules (the release of which are going to spring my project forward, significantly) fall under that umbrella.

I’m also going to leave the Glowforge Emulator under the GPL, as that is really a learning tool and not intended for any serious projects.


#8

Good to hear! Thanks for updating. Where you must use GPL, well, you must. Segmenting those parts will be important to avoid the viral nature of the GPL. Also, although the GPL folks won’t like it, you can dual license all your additions. For small things, it won’t matter, but if you have something large, it lets you open it up and also have it integrated with something under the GPL.

I had forgotten that Glowforge was GPLing things. Not surprised. My analysis is that the GPL is tilted to the benefit of large companies and corporations (ironic, considering who is championing it). The GPL lets such companies get some of the benefits of open source without actually letting competitors use their code in any practical way. Although Glowforge is a startup, they’re a large, well-funded startup.