inconsistency in OSD- software (#2) v. licenses/rights (every other plank)

[Luis Villa-3]

history/context/clarification question (and last email of the night, I swear):

In doing a quick comparison of the v3 and the OSD, I finally noticed
that section 2 of the OSD is inconsistent with the rest of the
document, since it speaks of qualities of specific software, rather
than rights or qualities of a generic license. This makes it a little
nonsensical to ask the question (as http://opensource.org/approval
does) 'does the license under consideration satisfy plank 2 of the
OSD?'

I know this language comes from OSD's roots in the DFSG. Is there any
particular reason it hasn't been removed (since presumably anyone
writing such a license intends to release source code) or updated to
make it consistent?

If the board were to consider clarifying the language, I might suggest
something like:

===
2. Source Code

The license must apply to the preferred form in which a programmer
would modify the program (typically referred to as source code), and
must allow distribution in this form as well as compiled form.
===

I dropped "Where some form of a product is not distributed with source
code, there must be a well-publicized means of obtaining the source
code..." since translating those clauses into a license requirement
would obviously preclude the BSD and other such licenses.

To replace that language, I might rewrite the Introduction to look
something like:

"Open source doesn't just mean access to source code. To be Open
Source Software, the source code for the software must be distributed
along with the software or otherwise easily obtainable, and it must be
available in the preferred form for modification, without obfuscation
or pre-processing. The source must also be licensed under an Open
Source Initiative Approved license.

To be approved, a license must comply with the following criteria:"

Obviously, I realize the OSD has worked fine for a long time despite
this inconsistency, so this isn't a huge deal. But since there seems
to be some emphasis right now on process, I thought this might be a
good time for a suggestion intended to clarify and improve the
process.

Luis

[Jesse Hannah]

Good find. You're right--whereas the rest of the OSD talks about the  
license or rights granted by the license, #2's wording at least is  
inconsistent. I think the "preferred form in which a programmer would  
modify the program" phrase is still a little vague, since that could  
still include the intermediate forms mentioned in the current  
version...it'd probably be better to just say "source code". Other  
than that, I think those clarifications you suggest are a good idea.
--
jbh

~~~~
Jesse B Hannah
        <jesse.hannah@...>
        <jesse.hannah@...>

Homepage: <http://lifeisleet.com>
IRC Handle: <jbhannah@...>

GPG Key: 0xA6DC3EF3
        Available from the keyservers or at
        <http://files.lifeisleet.com/jesse.asc>


On 31 Jul 2007, at 20:58, Luis Villa wrote:

> history/context/clarification question (and last email of the  
> night, I swear):
>
> In doing a quick comparison of the v3 and the OSD, I finally noticed
> that section 2 of the OSD is inconsistent with the rest of the
> document, since it speaks of qualities of specific software, rather
> than rights or qualities of a generic license. This makes it a little
> nonsensical to ask the question (as http://opensource.org/approval
> does) 'does the license under consideration satisfy plank 2 of the
> OSD?'
>
> I know this language comes from OSD's roots in the DFSG. Is there any
> particular reason it hasn't been removed (since presumably anyone
> writing such a license intends to release source code) or updated to
> make it consistent?
>
> If the board were to consider clarifying the language, I might suggest
> something like:
>
> ===
> 2. Source Code
>
> The license must apply to the preferred form in which a programmer
> would modify the program (typically referred to as source code), and
> must allow distribution in this form as well as compiled form.
> ===
>
> I dropped "Where some form of a product is not distributed with source
> code, there must be a well-publicized means of obtaining the source
> code..." since translating those clauses into a license requirement
> would obviously preclude the BSD and other such licenses.
>
> To replace that language, I might rewrite the Introduction to look
> something like:
>
> "Open source doesn't just mean access to source code. To be Open
> Source Software, the source code for the software must be distributed
> along with the software or otherwise easily obtainable, and it must be
> available in the preferred form for modification, without obfuscation
> or pre-processing. The source must also be licensed under an Open
> Source Initiative Approved license.
>
> To be approved, a license must comply with the following criteria:"
>
> Obviously, I realize the OSD has worked fine for a long time despite
> this inconsistency, so this isn't a huge deal. But since there seems
> to be some emphasis right now on process, I thought this might be a
> good time for a suggestion intended to clarify and improve the
> process.
>
> Luis

[David Woolley (E.L)]

Luis Villa wrote:

> I dropped "Where some form of a product is not distributed with source
> code, there must be a well-publicized means of obtaining the source
> code..." since translating those clauses into a license requirement
> would obviously preclude the BSD and other such licenses.

The BSD license is only really a source code licence.  A BSD derived
binary that has been modified is not open source.  The source code is
easily obtainable for binaries from unmodified source code, even though
one might not get it from the distributor of the binary.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[David Woolley (E.L)]

Jesse Hannah wrote:

> version...it'd probably be better to just say "source code". Other than
> that, I think those clarifications you suggest are a good idea.

Source code includes obfuscated source code and the results of running
pre-processors, like flex and yacc.  The preferred form wording is
intended to ensure that, for example, a parser is distributed as the
yacc input file, not the resulting C "source code" file.

If it is at all vague, it is done that way to reduce the chances of
people finding loopholes to allow the "source code" to be distributed,
but in a way that makes it difficult or impossible for the recipient to
produce non-trivial modifications.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[Jesse Hannah]

Ah, ok :) I get it now, thanks for clearing that up.
--
jbh

~~~~
Jesse B Hannah
        <jesse.hannah@...>
        <jesse.hannah@...>

Homepage: <http://lifeisleet.com>
IRC Handle: <jbhannah@...>

GPG Key: 0xA6DC3EF3
        Available from the keyservers or at
        <http://files.lifeisleet.com/jesse.asc>


On 1 Aug 2007, at 00:00, David Woolley wrote:

> Jesse Hannah wrote:
>
>> version...it'd probably be better to just say "source code". Other  
>> than that, I think those clarifications you suggest are a good idea.
>
> Source code includes obfuscated source code and the results of  
> running pre-processors, like flex and yacc.  The preferred form  
> wording is intended to ensure that, for example, a parser is  
> distributed as the yacc input file, not the resulting C "source  
> code" file.
>
> If it is at all vague, it is done that way to reduce the chances of  
> people finding loopholes to allow the "source code" to be  
> distributed, but in a way that makes it difficult or impossible for  
> the recipient to produce non-trivial modifications.
>
> --
> David Woolley
> Emails are not formal business letters, whatever businesses may want.
> RFC1855 says there should be an address here, but, in a world of spam,
> that is no longer good advice, as archive address hiding may not work.

[John Cowan]

Luis Villa scripsit:

> I know this language comes from OSD's roots in the DFSG. Is there any
> particular reason it hasn't been removed (since presumably anyone
> writing such a license intends to release source code) or updated to
> make it consistent?

It's what it needs to be.  The OSD defines what it means for software
to be Open Source.  OSD #1 and #3-#10 are of the form "Must be released
under a license with property X".  OSD #2 is more direct:  "Must be
available in source form".  This is not inconsistency, though it is lack
of parallelism.

This prevents the claim that some opaque block of binary bits is Open
Source because you have attached the BSD or similar permissive license
to it.

> If the board were to consider clarifying the language, I might suggest
> something like:
>
> ===
> 2. Source Code
>
> The license must apply to the preferred form in which a programmer
> would modify the program (typically referred to as source code), and
> must allow distribution in this form as well as compiled form.
> ===

That's not enough: the license might apply to source, but if you can't
get any source, the software isn't Open Source.

> "Open source doesn't just mean access to source code. To be Open
> Source Software, the source code for the software must be distributed
> along with the software or otherwise easily obtainable, and it must be
> available in the preferred form for modification, without obfuscation
> or pre-processing. The source must also be licensed under an Open
> Source Initiative Approved license.
>
> To be approved, a license must comply with the following criteria:"

That could work, as it's equivalent to what we now have.  I don't
know if it would be less confusing or not.  (However, renumbering
the criteria would be a Bad Thing.)

--
He played King Lear as though           John Cowan <cowan@...>
someone had played the ace.             http://www.ccil.org/~cowan
        --Eugene Field