7

We are a small group of developers who are looking to base a product we have in development on a OSL 3.0 licensed Project (OroCRM). I have been having trouble understanding the exact terms of the OSL 3.0 license.

Because the product we are developing will be a commercial product, and we will sell access to it as SAAS, will we be required to open source all of our code that we develop and allow access to anyone?

On Rosenlaw I find this:

The OSL 3.0 Approach To Derivative Works

OSL 3.0 is far simpler, with the entire copyright and copyleft bargain stated in a short § 1 that echoes the provisions of 17 USC 106 and similar copyright laws. Section 1(a) authorizes licensees to make "copies [of the Original Work], either alone or as part of a collective work", and § 1(b) authorizes licensees "to translate, adapt, alter, transform, modify, or arrange the Original Work, thereby creating derivative works ("Derivative Works") based upon the Original Work."

Then § 1(c) requires any copies of that Original Work and any Derivative Works that are distributed to be distributed under OSL 3.0 and, for those works, the Licensor promises to provide Source Code [§ 3]. In this way, the OSL 3.0 license remains with the work and all its subsequent versions, and that software always remains open source. That's reciprocity.

I believe this means that if we distribute our product, that we must use the OSL license, however if we never plan to distribute the code, but only sell access to the product we develop, will we still be required to open up our source code?

3 Answers 3

8

Yes; OSL 3.0 is a copyleft license that also applies if you provide network access to the output of your software, as in SaaS. From the source:

External Deployment Defined

OSL 3.0 requires that the External Deployment of software be treated the same as a distribution. The effect, of course, is that copies of the Original Work or Derivative Works that are externally deployed (i.e., that are used in-house to provide services to third parties) must be distributed reciprocally under OSL 3.0, just as if those third parties had received actual copies of the Original Work or Derivative Works.

This is similar to what AGPL does; even if you don't distribute binaries, if you provide access to the output of your software, you are still bound by the license terms and must provide source under the same license. If you continue reading the Rosen Law page, they make the comparison with AGPL too:

There is a version of GPL, the Affero GPL or AGPL, that also plugs the external deployment loophole, but that license brings along all the other baggage associated with the GPL that I've already criticized. The two-sentence External Deployment provision in OSL 3.0 [§ 5] plugs the loophole.

Here's the actual text from the aforementioned clause #5 in the license, which says pretty much the same thing:

5) External Deployment. The term "External Deployment" means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c).

(bold is mine)

2
  • Thank you for pointing that out. It is unfortunate for us, because we cannot justify putting several hundred thousand dollars of work into a project that will be open source. I have reached out to them to investigate other licensing options and will continue to look. It seems to me OSL 3.0 makes it very difficult for for profit corporations to work with and contribute to the open source project.
    – June Lewis
    Commented Jun 3, 2016 at 2:48
  • Hi @JoelLewis, do you have an update on what happened? and if you can use the software as SaaS without exposing source code?
    – Jorjani
    Commented Jul 9, 2018 at 15:45
1

I would like to add my understanding of OSL 3.0. The point is that OSL 3.0 license applies to Derivative Works.

The OSL 3.0 Approach To Derivative Works

OSL 3.0 is far simpler, with the entire copyright and copyleft bargain stated in a short § 1 that echoes the provisions of 17 USC 106 and similar copyright laws. Section 1(a) authorizes licensees to make "copies [of the Original Work], either alone or as part of a collective work", and § 1(b) authorizes licensees "to translate, adapt, alter, transform, modify, or arrange the Original Work, thereby creating derivative works ("Derivative Works") based upon the Original Work."

Then § 1(c) requires any copies of that Original Work and any Derivative Works that are distributed to be distributed under OSL 3.0 and, for those works, the Licensor promises to provide Source Code [§ 3]. In this way, the OSL 3.0 license remains with the work and all its subsequent versions, and that software always remains open source. That's reciprocity.

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).

Source Code Disclosure

Only the Source Code of the Original Work or the Source Code of a modified (altered, etc.) Derivative Work must be disclosed. [§§ 1(c), 3] The GPLv2 and GPLv3 ambiguities about linking are gone from OSL 3.0. The avoidance of technical terms of art such as "linking" and a definition of "Derivative Works" that relies on well-understood copyright verbs, are some of the reasons why OSL 3.0 imposes a less-burdensome reciprocity requirement than GPL.

· If linking (by whatever technical means) can be accomplished by making and using unmodified copies of the Original Work, then 1(a) and 1(c) permit that; only the Source Code of the Original Work must be disclosed.

· Otherwise, if modifications (or alterations, etc.) to the Original Work create a Derivative Work, then 1(b) and 1(c) permit that; only the Source Code of the modified (or altered, etc.) Derivative Work must be disclosed.

· As for independent works (in the copyright sense), or the independent components of collective works, the OSL 3.0 grant of copyright license in § 1 does not affect those works at all or place any source code requirements upon them. That independent source code need not be disclosed. In this respect, OSL 3.0 is more like LGPL than GPL in its effect, although it accomplishes that with far fewer words and far less uncertainty.

I made the most interesting part of the text in bold style.

OroCRM is a CRM system built with extensibility in mind. There's no need to modify it's source code in order to change the way it works. In other words there's no need to create a Derivative Work from the Original Work.

So according to the license you are free to build your solution on top of OroCRM (if you're not going to modify its code) and provide access to it via SaaS without a need to make your solution Open Source.

0

No, the restriction from section 1(c)

to distribute or communicate copies of the Original Work and Derivative Works to the public

only applies to Original Work or Derivative Works which is defined in section 1(b):

to translate, adapt, alter, transform, modify, or arrange the Original Work, thereby creating derivative works ("Derivative Works") based upon the Original Work;

So only if you modify the OSL 3.0 project that you are using you are obligated to publish the source of this project, not the whole code that was built using that project.

Magento is distributed with that license and we don't see the source code of thousands of stores built in Magento published, do we?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.