[okfn-discuss] possible OKD conformant licence: The MirOS Licence
rufus.pollock at okfn.org
Tue Jul 8 19:46:59 BST 2008
On 08/07/08 17:49, Patrick Anderson wrote:
>> b) Importantly the OKD talks about works as primary and licenses as
> I'm confused by this idea.
> Are you saying the work itself can determine whether or not it is open?
Not sure what you mean here? The relevant statement was:
"A work is open if its *manner of distribution* satisfies the following
conditions" (emphasis added)
It is not the work that determines anything but the manner of its
> Isn't it the license or licenses that determine that?
> Am I misreading your intent?
> Could you give me an example of a work that uses an 'open' license, or
> is in the Public Domain, but still does not meet the OKD because of
> something specific to that work?
Yes quite easily. Take a painting or a score that is very old (and in
the public domain) but to which access is denied (or to which access is
only given under the condition that you don't photograph it etc).
> Or is there an example of a work under a 'closed' license that still
> meets the OKD?
>> These conditions extend beyond specific requirements on the licence
> How could that be? What would cause an end-user to add these extra
Not releasing something.
> Maybe you are saying the OKD is about how each instance of a work is
> 'handled' or 'hosted' by a user, and not about the constraints
> enforced by the licensing over all instances?
That is correct. We hoped this was clear from the statements on the site.
> If that is the case, I would like to talk more about this.
>> specifically item 1 (Access) mandates that the work must be made available
>> (this is similar to the idea behind 'Affero' type clauses).
> But "the work" is usually the end-user 'binary' or 'object' code. It
> might be a rendered 3D model, or maybe lossy-compressed media (such as
> .mp3 or .jpg) or the rendered HTML for a wiki.
> The "sources" of such data are the pre-rendered state of that data
> such as the .3ds file for a 3D model, or the very large .wav file for
> the .mp3, or the bitmap file for the .jpg, or for the wiki it would be
> the "input text" that you modify in the edit-box.
I quite agree that the 'source' concept extends to other areas however
it seems clear that the GPL /was/ drafted focused on traditional
This issue with the source motivated the statement in item 1 of the OKD
"The work shall be available as a whole and at no more than a reasonable
reproduction cost, preferably downloading via the Internet without
charge. *The work must also be available in a convenient and modifiable
form.*" (emphasis added again).
There is also item 4 on technological restriction.
> The GNU AGPL does not require the rendered binaries be made available,
> and does not require distribution except to those that have interacted
> with the program.
> Sorry to be nitpicky here, but many people think the GNU [A]GPL
> licenses require blanket distribution - which would disallow private
> copies. This is false. These licenses only require the "Sources" and
> "Corresponding Sources" be made available, and ONLY to those that
> received the "Object" or, for the GNU AGPL, for those that used the
> program even without receiving the "Object" code.
Sure but this is an issue about the licence. I think we would all agree
that a privately modified copy of a work that was *not* made available
(and I'm not saying it should be) would not be 'open'.
>> I am not quite sure what the GPL delivers here above CC by-sharealike.
> The GNU GPL is extremely popular for software because of the
> protections it enforces. It is a form of defense.
> The CC-SA is incompatible with the GNU GPL, and does not defend the
> community from those that would withhold sources to make the work no
> longer open.
Right you mean that people would release the pdf but not the 'source'.
This takes us back to the point about licenses sometimes needing to be
subject specific. I, at least, am not clear about what the exact
interpretation (by a court) of 'source code' would be for a pdf derived
from a latex file.
>> will be clauses that are specific to that particular area -- e.g. GPL makes
>> frequent reference to 'source code' and 'object code' which does not,
>> necessarily, make much sense for a e.g. play or a sound-recording).
> Hmm... I'm going to have to disagree.
> The "sources" for a play would be the scripts and descriptions of some
> other things like maybe how to run the lights.
> The "sources" for a sound recording are the uncompressed original
> tracks if it was a lossy compression.
I agree that in many cases one can think of plausible 'sources' for
creative works but I do think that it is not usually as clear-cut as it
is for software ...
> On the other hand, sometimes even software doesn't have distinct
> 'object' and 'source' forms. An interpreted language that is never
>> may be different IP rights (or the same IP rights applied differently) in
>> different areas. For example, the EU, has a sui generis "database right"
>> specifically for 'databases (whereas for normal code it is copyright --
>> though I would note that in many common-law jurisdictions data collections
>> have also traditionally been protected by copyright). To see how difficult
>> things can get see this article  which was about copyright in Huffman
>> encoding tables.
> Well, lawyers have incentive to keep non-lawyers perplexed, so the
> unnecessary complexity is not surprising.
Perhaps though it may also arise out of distinctions people wish to
create between different subject areas and the scope of the associated
IP (monopoly) rights.
More information about the okfn-discuss