Open Software License 3.0 Explained

Lawrence Rosen, former legal counsel for the Open Source Initiative, posted his article on OSL 3.0: A Better License for Open Source Software recently.

I like the OSL 3.0, and his article has affirmed my view. On the other hand, Rosen's article really is just an article that "explains why it (OSL 3.0) is a better license for software than the GPL", and says little, if not nothing at all, on what could make the GPL a better software license than the GPL.

It seems to me that what makes the GPL compelling is the community usage and backing of the FSF. I have seen a ranking of open source license popularity that places the OSL near the top-middle of the list... but on closer inspection the GPL, at #1, is far ahead of the #2 (the (modified) BSD license, if I remember correctly). For all the confusing nature of various versions of the GPL, the FSF has backed it up with its own arguments and explanations. Some might be legally... disputed, but with such an organisation to back you up and with major open source players using it, the GPL does seem like a good bet.

So, after reading Rosen's arguments, would you consider the OSL 3.0 for an open source software project for which you want a reciprocal license? Or would you stick with the GPL, or some other reciprocal/copyleft license? If so, why?

One problem I have with the GPL and LGPL is with a library I own.

My (proprietary) library supports feature A, B, and C.

a GPL Library supports feature D.

I would like to make a new library that has feature A, B, C, and D, but is released under the LGPL, so that I can use the library in my proprietary application.

This obviously benefits the open source community because they get my proprietary code, it benefits me because I get to use feature D in my application. I cannot however relase the source for the application under the GPL as I dont own the application itself, just the library.

Feature A autoselects which sub-feature to use, feaure B or feature C/D with a prefereance for C if both C and D are supported by the device.

Because feature D is specifically GPL, not LGPL, it propogates GPL status to feature A.

Because feature A is now GPL, it cannot be used as part of a proprietary application, therefore I cannot release feature A B and C at all.

My beef is similar to abachler's but with less variables. If I'm going to open-source a tool, I want people to be able to use it without worrying about license conflicts. Since GPL is most widely used, you sort of maximize you're compatability by using it. I've experienced this problem with the EPL (formerly IBM's CPL) and GPL code.

To answer you're original questions, I'd consider the OSL so long as it doesn't have compatabiltiy issues with the GPL.

You could just release it under a dual license...

Quote:

---

One problem I have with the GPL and LGPL is with a library I own.
...
Because feature A is now GPL, it cannot be used as part of a proprietary application, therefore I cannot release feature A B and C at all.

---

That seems to be more of a problem with the GPL than the LGPL since your problem would disappear if the library with feature D was released under the LGPL (linking issues aside). According to Rosen's analysis, if the library with feature D was under the OSL 3.0, you could release your new library under another license since:

Quote:

---

The definition of Derivative Works in § 1(b) is particularly important. For one thing, that defined term includes no reference whatsoever to linking or to any other technical manner of making programs interoperate. The verbs used in § 1(b) ["translate, adapt, alter, transform, modify, or arrange"] reflect the kinds of activities that we generally do to create derivative literary or other expressive works, and those things—not functional linking—create Derivative Works as defined in this license. As a result, linking an unchanged Original Work with another independently-written work does not, absent more, create a Derivative Work subject to § 1(b); such an act is merely the incorporation of a copy of that Original Work into a collective work, authorized by § 1(a).

---

Well, my issue is that I want to use the resultant library ABCD with my application. The application code must remain proprietary as it contains a lot of other IP unrelated to ABCD. I am unsure if there is a method for incorporating D into my current library ABC without propogating GPL status to my application.
The GPL is a bit vague on the matter of whether a GPL library can be dynamically linked by a proprietary application without the application becoming GPL.

There isn't. That's the whole point of the GPL: that it benefits open-source programmers but not proprietary programmers. The GPL is viral for a reason.

True, but in this case it is (IMO) actually counter-productive. Adding feature A B and C to library D would make library ABCD unusable by me (for commercial purposes). Even though I am willing to release ABCD under the GPL, I would be prohibited from using ABCD in my existing application. However, if I incorporate D into a system service [D] that accepts interfaces only through network connections, I can then use [D] from my proprietary program by passing the data across the socket stack without releasing ABC under the GPL. Granted that D should probably have been released under the LGPL, particularly since there is a commercially available version of D ($D$). Inclusion of ABC into D would make D much better than $D$, but at the cost of putting the contributor at a competitive disadvantage, since I must either prohibit commecrial use of ABC, or allow its use by competing commercial software. Since passing the data across the stack is really no different that linking, except for the legal definitions under the GPL, it makes it trivial to circumvent the GPL and use GPL code in commercial applications without propogating those changes to the proprietary code. This is a hole in the GPL that is big enough to drive a proverbial truck through. I see no way to plug this hole that would not also make any browser (i.e. IE) that accesses a web server built from GPL source into open source itself, much to the authors chagrin.

If A is proprietary code and B is GPL code, then either -

1) A can access B and remain proprietary

or

2) A cannot access B and remain propritary

if 1 then all GPL code can be wrapped into a system service and used by proprietary software.

if 2 then Internet Explorer and by extension Windows itself, is GPL.

I think the courts would find the first case to be the most applicable.

Quote:

---

Originally Posted by robwhit

You could just release it under a dual license...

---

Yeah, try getting a company to go for that. We ended up just relicensing under EPL for compatibility with the target project.