Forced distribution licenses (AGPL/OSL/etc): Why not.

Chris Zumbrunn chris at czv.com
Sat Dec 15 09:21:51 UTC 2007


On Dec 15, 2007, at 7:32 , Chris Travers wrote:

> On the subject of whether this is necessary for web application,  
> lest they be taken over by commercial close SAAS vendors....  In  
> general, my feeling is that the best defense against this is an  
> active developer community which is able to do quality software  
> engineering and build things right.  If this is not in place, then  
> the community doesn't stand to benefit from the forced contributions  
> of the SAAS vendors anyway and if it is in place then economic (not  
> market) forces will help ensure that as much gets contributed as  
> possible from these vendors just as happens with more permissive  
> licenses.
>
> I guess I would ask about licenses such as the OSL and AGPL:  Do you  
> *really* want to make everyone who modifies a project (even if it is  
> just a configuration file) to feel like they have to be a  
> distribution point to be safe?  What if you do security releases?   
> Do you really want a large number of distribution points which are  
> likely to be vastly out of date?  (The FOSS community has come a  
> long way in keeping secondary distribution points up to date, but  
> why complicate things?)
>
> Licenses like this, however, encourage a single vendor to control  
> the copyright and then sell additional licenses (i.e. exceptions  
> from the forced distribution, etc). These sorts of things undermine  
> rather than help community-centric development and I would probably  
> avoid using these licenses for any of my own work.

What if we would take the OSL and change 1c) to read:

c) to distribute or communicate copies of the Original Work and  
Derivative Works to the public, with the proviso that modifications  
made to the Original Work are made available to the Licensor under a  
license suitable for inclusion of these modifications in future  
versions of the Original Work;

As some of you might remember, this kind of "copyback" formulation has  
already been discussed once here on this list about two years ago. I  
never pressed forward with a license like that because I didn't feel I  
had found a good enough formulation. But there were many occasions,  
when I noticed again that there would likely be a need/desire for a  
license with these features. Just to put another twist on the  
formulation I mentioned above for an OSL based 1c), here is the last  
wording for the copyback clause discussed back then:
"Modifications and the derivative work that falls within the Work's  
original scope of functionality must be contributed by making a  
reasonable effort to enable the Project to obtain such contributions  
under a license suitable for the inclusion in the Deployment of future  
versions of the Work."
http://zumbrunn.com/Copyback+License/
In other words, a formulation that is intentionally vague, to let  
downstream projects and vendors choose *how* they want to comply. The  
idea being, to come up with a license that provides the community with  
the core benefits of both permissive and copyleft licenses. Code from  
a project licensed under such a license could be reused in proprietary  
products without providing source code to users or the public,  
combined with code under other open source licenses, deployed as a  
service without the requirement to open up more distribution points,  
and in any of these scenarios, the community could still be sure to  
benefit from the modifications that need to be contributed either  
publicly or directly back to the Licensor of the original work.

Wouldn't that be a viable alternative for the problem with forced  
distribution licenses?
Chris Zumbrunn




More information about the License-discuss mailing list