Change ot topic, back to OVPL

[Smith, McCoy]

FSF has an FAQ on this point:
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLRequireSourcePoste
dPublic


-----Original Message-----
From: Lawrence Rosen [mailto:lrosen at rosenlaw.com] 
Sent: Wednesday, August 24, 2005 4:39 PM
To: 'David Barrett'; license-discuss at opensource.org
Subject: RE: Change ot topic, back to OVPL

> (At least, this is what I was told by MySQL when I asked 
> about how widely I could internally use private modifications 
> to a MySQL server. 
> They told me the GPL allowed me to make and use one server 
> without releasing the source, but two or more constitutes 
> distribution.)

Such misinformation shouldn't have informed your license. This is not
true.

If you intended to accomplish this, you're past the OSD. You cannot
control
your customers' internal activities or require reporting of their
internal
uses. Disclosure and reciprocal licensing can be demanded only when they
distribute -- which in the open source world is interpreted to mean
*outside
the licensee's organization*. 

The confusion about this point is not surprising. Many licenses are
ambiguous or don't address the topic at all. But I know of licenses that
were rejected by OSI because they tried to reach to licensees' internal
activities.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  *  fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and 
   Intellectual Property Law" (Prentice Hall 2004) 
   [Available also at www.rosenlaw.com/oslbook.htm]
 
 

> -----Original Message-----
> From: David Barrett [mailto:dbarrett at quinthar.com] 
> Sent: Wednesday, August 24, 2005 4:22 PM
> To: license-discuss at opensource.org
> Subject: Re: Change ot topic, back to OVPL
> 
> Wilson, Andrew wrote:
> > You tell me: if I create an enhanced version of OVPL code 
> and put it 
> > on my company's internal server, have I made it available?
> > 
> > If the intention is to give the ID rights to demand only 
> > externally-distributed Modifications, the definition of Licensed 
> > Modification could easily be changed to say that explicitly.
> 
> Ahh, I think I see what you're saying.  In this case you're 
> saying the developer can deny changes to the public, but not 
> to the ID -- and you would find the requirement that the ID 
> be given access when the public is not to be objectionable.
> 
> However, I'm not sure if this is true; so far as I know, once you make
> *any* distribution, you need to make the source code 
> available to *everyone*.  In other words, the only way to 
> deny *anyone* the source is to deny *everyone* the source by 
> not distributing your change, in any form.  Putting it on an 
> internal server (presumably so others within the organization 
> can obtain it) constitutes distribution, and thus requires 
> public (to the world) source code release.
> 
> This is the case irrespective of the ID.  Even with the GPL, 
> you can't make and internally distribute private changes 
> because the process of "internal distribution" is -- by 
> definition -- distribution.
> 
> (At least, this is what I was told by MySQL when I asked 
> about how widely I could internally use private modifications 
> to a MySQL server. 
> They told me the GPL allowed me to make and use one server 
> without releasing the source, but two or more constitutes 
> distribution.)
> 
> Specifically, the relevant paragraph in the CDDL (which is 
> taken verbatim by the OVPL) for public disclosure is (hacked 
> up to highlight the relevent bits):
> 
> > 3.1.      Availability of Source Code.
> > 
> > Any Covered Software that You distribute ... in Executable 
> form must 
> > also be made available in Source Code form... You must inform 
> > recipients ... as to how they can obtain such Covered Software in 
> > Source Code form...
> 
> This says the scope of your *notification* can be limited to 
> recipients, but it doesn't say that the scope of your *source 
> code release* can be likewise limited.  Said another way, 
> nowhere does it hint you can deny the source code to 
> non-recipients.  Rather, it says that once you make and 
> distribute a modification, you must:
> 
> 	1) make it available (presumably, to anyone who asks), and
> 	2) notify the recipients how to get the source
> 
> So, the only change introduced by the OVPL is to make an additional
> requirement:
> 
> 	3) notify the ID how to get the source
> 
> However, this only affects who you notify; not to whom you 
> release.  And indeed, that doesn't seem terribly onerous.  In 
> effect, the ID is basically treated like a recipient of any 
> changes.  He's not given any special access, he's only 
> notified when changes are made.
> 
> This just ensures that the ID knows about all the code to 
> which he is legally entitled; it prevents developers from 
> creating a secret fork to which the ID has his unique rights, 
> but simply was never notified existed.
> 
> Now, you could argue that this notification right is 
> unnecessary or objectionable, but that's a different debate.
> 
> -david