Approval for OWFa

[Lawrence Rosen]

Board, would anyone object if I submitted the OWF Agreement to OSI for its approval as an open source license?

 

I assume I would wait until our announcement before doing so.

 

/Larry

 

 

[DeWitt Clinton]

As an open source license, or compatible with open source licenses?

I had never imagined the OWFa being applied to source code.  We have great licenses already for that.

-DeWitt

[David Rudin]

Larry,

It's definitely an interesting idea, but I'm curious how OWFa would meet the Open Source Definition.  In particular:

2. Source Code

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

Unless you can argue that a specification is source code, I'm not sure how this applies.  Also, OWFa does not mandate or prohibit any particular software development model.  Implementers can implement a spec in open source or using proprietary models.  How would OSI treat an OWFa spec implemented in a non-open source piece of software?

Also

3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

OWFa allows this from a copyright perspective, but there are some restrictions around patents for derivative works based on the specification (i.e., subsequent drafts of a specification).

David

[Lawrence Rosen]

DeWitt,

 

I would seek approval as an open source license *and* compatible with other open source licenses. The OWFa is being applied to copyrightable subject matter; that, rather than source code, is the essential characteristic of open source licenses.

 

I have asked several folks to consider whether the OWF Agreement can be used for the HTML5/WHATWG specification now coming out of W3C. One objection that was raised is that the OWF Agreement is not OSI-approved. I'd like to foreclose that objection.

 

/Larry

[Lawrence Rosen]

David,

 

I do argue that the specification is source code. Why not? It is "the preferred form of the Original Work for making modifications to it."

 

Open source copyrightable works can be compatible with proprietary software. :-) Like Apache software, OWFa specifications are available for use in both open source and proprietary software. An OWFa specification or Apache software implemented in proprietary software is not itself open source. That's not a problem for approving the Apache or OWFa license.

 

Finally, I contend that the limitation on derivative works applies only to the patent grant (and that in a very limited way), but does not affect the copyright grant. This is the same as most other open source licenses and should not affect approval by OSI.

 

/Larry

 

 

From: open-we...@googlegroups.com [mailto:open-we...@googlegroups.com] On Behalf Of David Rudin
Sent: Thursday, November 12, 2009 8:18 AM
To: open-we...@googlegroups.com
Subject: [Open Web Board] Re: Approval for OWFa

 

Larry,

[David Rudin]

There are certainly many definitions of software, but here's one from the Linux Information Project - http://www.linfo.org/source_code.html

Source code (also referred to as source or code) is the version of software as it is originally written (i.e., typed into a computer) by a human in plain text (i.e., human readable alphanumeric characters).

The term software refers to all operating systems, application programs and data that is used by products containing microprocessors (also called processors orcentral processing units). Such products include not only personal computers but also a vast array of other products, such as aircraft electronic systems, railway signaling systems, industrial robots, electronic medical equipment, space vehicle guidance systems, electronic cameras and even simple electronic toys.

Source code can be written in any of the hundreds of programming languages that have been developed. Some of the most popular of these are C, C++, Cobol, Fortran, Java, Perl, PHP, Python and Tcl/Tk.

...

To be usable by a computer or other microprocessor-based product, source code must be compiled (i.e., translated by a computer) into machine language by a special program called a compiler. Also referred to as object code or binaries, machine language consists of a sequence of instructions (in the form of zeros and ones) that the processor can understand -- but which is very difficult for humans to read or modify.

At least under this definition, source code must be compiled to be usable.  Specs don't get compiled, they serve as a blueprint for someone to write source code against.  Is there a definition(s) that the OSI has used in the past that might support a spec as software?  My real concern here is that OSI would reject the OWFa.  I'd rather be in limbo than have an OSI objection.

I did notice that the OSI has an "Open Standards Requirement for Software" - http://opensource.org/osr.

Open Standards Requirement for Software

The Requirement

An "open standard" must not prohibit conforming implementations in open source software.

The Criteria

To comply with the Open Standards Requirement, an "open standard" must satisfy the following criteria. If an "open standard" does not meet these criteria, it will be discriminating against open source developers.

1. No Intentional Secrets: The standard MUST NOT withhold any detail necessary for interoperable implementation. As flaws are inevitable, the standard MUST define a process for fixing flaws identified during implementation and interoperability testing and to incorporate said changes into a revised version or superseding version of the standard to be released under terms that do not violate the OSR.
2. Availability: The standard MUST be freely and publicly available (e.g., from a stable web site) under royalty-free terms at reasonable and non-discriminatory cost.
3. Patents: All patents essential to implementation of the standard MUST:
   • be licensed under royalty-free terms for unrestricted use, or
   • be covered by a promise of non-assertion when practiced by open source software
4. No Agreements: There MUST NOT be any requirement for execution of a license agreement, NDA, grant, click-through, or any other form of paperwork to deploy conforming implementations of the standard.
5. No OSR-Incompatible Dependencies: Implementation of the standard MUST NOT require any other technology that fails to meet the criteria of this Requirement.

I think that the OWFa is close, but it does not  "define a process for fixing flaws identified during implementation and interoperability testing and to incorporate said changes into a revised version or superseding version of the standard to be released under terms that do not violate the OSR."  OWFa doesn't mandate ANY process - we leave that to the communities.

Also, #5 might also be problematic since OWF doesn't get involved with implementations or how a spec is written.  For example, there is nothing stopping an OWFa covered spec from making the choice to normatively reference a royalty based standard, such as a video codec.

David

[Lawrence Rosen]

Source code can be written in any of the hundreds of programming languages that have been developed.

 

Or in English. Quite frankly, I think the "source code" of a useful open web specification is the Word document in which it is written, but I'm willing to translate a printout using OCR software if that's the best source code you give me for my specification. It is still open source if I can freely copy, modify and distribute the specification without restriction or payment of royalty.

 

At least under this definition, source code must be compiled to be usable.  Specs don't get compiled, they serve as a blueprint for someone to write source code against.  

 

Your term "blueprint" is helpful. Like a copyrighted architectural specification for a building, a software specification can either be open source or proprietary. It is "compiled" by human beings who translate the specification into other forms of source code or into actual buildings. Sometimes the specification serves directly as code; ask anyone in IETF about that subtlety. It is open source if you receive useful "source" under an open source license. Whether and how you compile it is up to you.

 

I did notice that the OSI has an "Open Standards Requirement for Software" - http://opensource.org/osr.

 

That is interesting, informative and influential. But it is not the Open Source Definition. Nevertheless, I will comfortably argue that the OWFa is an honest attempt to satisfy those Open Standards requirements in the context of the Open Web. Some of the authors of that document are already members of OWF and will almost certainly support this effort to approve OWFa as an OSI-approved open source license because they support the OWFa itself.

 

I'm liaising as fast as I can.

 

/Larry

 

 

 

 

From: open-we...@googlegroups.com [mailto:open-we...@googlegroups.com] On Behalf Of David Rudin
Sent: Thursday, November 12, 2009 8:54 AM
To: open-we...@googlegroups.com
Subject: [Open Web Board] Re: Approval for OWFa

 

There are certainly many definitions of software, but here's one from the Linux Information Project - http://www.linfo.org/source_code.html

 

Source code (also referred to as source or code) is the version of software as it is originally written (i.e., typed into a computer) by a human in plain text (i.e., human readable alphanumeric characters).

 

The term software refers to all operating systems, application programs and data that is used by products containing microprocessors (also called processors orcentral processing units). Such products include not only personal computers but also a vast array of other products, such as aircraft electronic systems, railway signaling systems, industrial robots, electronic medical equipment, space vehicle guidance systems, electronic cameras and even simple electronic toys.

 

Source code can be written in any of the hundreds of programming languages that have been developed. Some of the most popular of these are C, C++, Cobol, Fortran, Java, Perl, PHP, Python and Tcl/Tk.

 

...

 

To be usable by a computer or other microprocessor-based product, source code must be compiled (i.e., translated by a computer) into machine language by a special program called a compiler. Also referred to as object code or binaries, machine language consists of a sequence of instructions (in the form of zeros and ones) that the processor can understand -- but which is very difficult for humans to read or modify.

 

At least under this definition, source code must be compiled to be usable.  Specs don't get compiled, they serve as a blueprint for someone to write source code against.  Is there a definition(s) that the OSI has used in the past that might support a spec as software?  My real concern here is that OSI would reject the OWFa.  I'd rather be in limbo than have an OSI objection.

 

I did notice that the OSI has an "Open Standards Requirement for Software" - http://opensource.org/osr.

 

Open Standards Requirement for Software

The Requirement

An "open standard" must not prohibit conforming implementations in open source software.

The Criteria

To comply with the Open Standards Requirement, an "open standard" must satisfy the following criteria. If an "open standard" does not meet these criteria, it will be discriminating against open source developers.

1.    No Intentional Secrets: The standard MUST NOT withhold any detail necessary for interoperable implementation. As flaws are inevitable, the standard MUST define a process for fixing flaws identified during implementation and interoperability testing and to incorporate said changes into a revised version or superseding version of the standard to be released under terms that do not violate the OSR.

2.    Availability: The standard MUST be freely and publicly available (e.g., from a stable web site) under royalty-free terms at reasonable and non-discriminatory cost.

3.    Patents: All patents essential to implementation of the standard MUST:

§  be licensed under royalty-free terms for unrestricted use, or

§  be covered by a promise of non-assertion when practiced by open source software

4.    No Agreements: There MUST NOT be any requirement for execution of a license agreement, NDA, grant, click-through, or any other form of paperwork to deploy conforming implementations of the standard.

5.    No OSR-Incompatible Dependencies: Implementation of the standard MUST NOT require any other technology that fails to meet the criteria of this Requirement.

[David Rudin]

Larry - You might want to raise this on the legal list.

David

[Lawrence Rosen]

I'm sure it will come up on license...@opensource.org and I'll be glad to argue it there as well as on OWF-legal. In the meantime, let me make sure that the OWF board is supportive.

[Brady Brim-DeForest]

Larry,

I think this is a great idea. While there are clearly some questions regarding whether a spec can be open-sourced, I don't think we'll reach a conclusion until we propose this to OSI (perhaps informally at first).

You have my full support in this effort.

Brady

--
Brady Brim-DeForest
www.brimdeforest.com (the blog)
www.tubefilter.tv (the company)

Follow me: twitter.com/bradybd

This email is:   [ ] bloggable    [X] ask first   [ ] private

[Gabe Wachob]

I'd really be interested in the OSI's feedback (perhaps informally at
first) on the FSA, but I think it would actually be *confusing* to
have it evaluated as a Open Source license as the OSI typically does -
confusing to third parties at the very least. I think it actually
detracts from the message that the FSA is something qualitatively
different than an open source license we're used to seeing today and
apply to source code.

That being said, I think *compatibility* is a great goal (and perhaps
a neccesary one) with OSI qualifications for open source licenses (in
other words, that the FSA produces a spec which can be implemented in
open source, at least as far as patent and IPR issues stemming from
potential claims of contributors to the spec).

Whether or not the OSI "approves" the FSA or not (ie whether we seek
such an approval) is something perhaps we should discuss. The lesson
of OASIS' attempts as "open source friendly" licensing regime should
be a lesson in how things can go wrong (some of us here having been on
both sides of that process!)

-Gabe

--
Gabe Wachob / gwa...@wachob.com \ http://beatslacker.com

[DeWitt Clinton]

I'm actually not supportive of proposing the OWFa as a new source code license.  The world has enough open source licenses -- further proliferation does little good, and some bad, if you ask me.

Getting the OWFa vetted by the OSI for compatibility with OSI-approved licenses, on the other hand, would be fantastic, and I'd wholeheartedly support that.

-DeWitt

On Thu, Nov 12, 2009 at 12:09 PM, Lawrence Rosen <lro...@rosenlaw.com> wrote:

[David Recordon]

+1

[Tantek Celik]

Strongly agreed DeWitt. Positioning OWFa as complementary to OS licenses makes the most sense to me. I see OWFa as more like the patent rights piece that common copyright licenses have lacked to date. -Tantek

---

From: DeWitt Clinton <dew...@google.com>

Date: Thu, 12 Nov 2009 13:17:18 -0800

[Lawrence Rosen]

I see OWFa as more like the patent rights piece that common copyright licenses have lacked to date. -Tantek

 

Only the BSD/MIT licenses, and their ilk, lack a patent grant. All other modern FOSS licenses contain a patent rights grant. Even the classic GPL, although it isn't phrased as such.

 

If there's a copyright grant in the license, it must be approved by OSI as an OSD-compatible copyright license. If it were just a patent non-assert, OSI would have nothing to say about it.

 

The world has enough open source licenses -- further proliferation does little good, and some bad, if you ask me. - DeWitt

 

I didn't ask, but thanks for reminding me of that argument. :-) That is a lousy excuse not to seek approval for a new good open source license. If non-proliferation was your goal, I could have recommended any of several great *existing* and *non-proliferating* open source licenses that are already suitable for Open Web Standards. You were the ones who wanted a new agreement; now let's get it approved so the authors of various important standards can use it for their copyrighted "software" works.

 

/Larry

 

 

 

</html

[Roy T. Fielding]

On Nov 12, 2009, at 8:53 AM, David Rudin wrote:

> There are certainly many definitions of software, but here's one from the Linux Information Project - http://www.linfo.org/source_code.html
>
>> Source code (also referred to as source or code) is the version of software as it is originally written (i.e., typed into a computer) by a human in plain text (i.e., human readable alphanumeric characters).
>>
>> The term software refers to all operating systems, application programs and data that is used by products containing microprocessors (also called processors orcentral processing units). Such products include not only personal computers but also a vast array of other products, such as aircraft electronic systems, railway signaling systems, industrial robots, electronic medical equipment, space vehicle guidance systems, electronic cameras and even simple electronic toys.
>>
>> Source code can be written in any of the hundreds of programming languages that have been developed. Some of the most popular of these are C, C++, Cobol, Fortran, Java, Perl, PHP, Python and Tcl/Tk.
>>
>> ...
>>
>> To be usable by a computer or other microprocessor-based product, source code must be compiled (i.e., translated by a computer) into machine language by a special program called a compiler. Also referred to as object code or binaries, machine language consists of a sequence of instructions (in the form of zeros and ones) that the processor can understand -- but which is very difficult for humans to read or modify.
>>
> At least under this definition, source code must be compiled to be usable. Specs don't get compiled, they serve as a blueprint for someone to write source code against. Is there a definition(s) that the OSI has used in the past that might support a spec as software? My real concern here is that OSI would reject the OWFa. I'd rather be in limbo than have an OSI objection.

Er, no, that definition is awful -- clearly not written by
someone with a degree in the field. See

http://www.google.com/search?q=define%3A+software

In software engineering, software is anything having to do with
a computer that isn't hardware (non-modifiable) or wetware (people).
Documentation and protocol specs are generally considered software
even though they only indirectly instruct the computer what to do.

This is not to imply that I think an open spec should have a
typical open source license. I don't like the idea of people
changing several paragraphs in a spec and then redistributing it
without also making significant modifications to the title page
and highlighting every change from the original. I think it is
possible to write an open source license for documentation
that has very specific requirements on authenticity and noting
of modifications, but I haven't done it yet.

....Roy

[Brett McDowell]

On Nov 12, 2009, at 4:17 PM, DeWitt Clinton wrote:

> Getting the OWFa vetted by the OSI for compatibility with OSI-approved licenses [...] would be fantastic, and I'd wholeheartedly support that.
>

+1

Since everyone agrees with this part of the idea, how about Larry just go and get this feedback?

The other issue about whether OWFa should be an open-source license itself seems like a distraction that is delaying action on the consensus view. If Larry pursues the consensus request, it doesn't lock-in or preclude the other (distracting) issue.

-- Brett

[Eran Hammer-Lahav]

Such a shame to have such an interesting debate on a list on one will ever read...

This would *still* be a useful conversation on the legal list.

And I am supporting in seeking feedback. Using it for other purposes - don't care either way.

EHL

> -----Original Message-----
> From: open-we...@googlegroups.com [mailto:open-web-
> bo...@googlegroups.com] On Behalf Of Roy T. Fielding
> Sent: Thursday, November 12, 2009 8:07 PM
> To: open-we...@googlegroups.com
> Subject: [Open Web Board] Re: Approval for OWFa
>
>

[DeWitt Clinton]

Response inline:

On Thu, Nov 12, 2009 at 8:07 PM, Roy T. Fielding <roy.fi...@gmail.com> wrote:

Er, no, that definition is awful -- clearly not written by
someone with a degree in the field.  See

http://www.google.com/search?q=define%3A+software

In software engineering, software is anything having to do with
a computer that isn't hardware (non-modifiable) or wetware (people).
Documentation and protocol specs are generally considered software
even though they only indirectly instruct the computer what to do.

I don't know, that's certainly a liberal definition of software.  Colloquially speaking, software tells a machine what to do.  Specifications tell a human what to do.  The [define:software] link tends to confirm that as well, as least as far as general understanding goes.

So it follows that a source code license confers rights to a particular implementation or its derivatives, whereas a specification license confers rights to many possible implementations.  The work at the OWF has been focused on easing the path to the latter.

As David said, the answer to "is the OWFa compatible with the OSI requirements?" seems to me to be pretty clear from the requirements set forth at http://opensource.org/osr, with a possible open question about requirement #5, but I'd say that is outside the scope of the OWF agreement to define, and instead entirely dependent on the particular specification.  (I.e., the OWF agreement does not preclude compatibility.)

-DeWitt

 

[Lawrence Rosen]

DeWitt wrote:

So it follows that a source code license confers rights to a particular implementation or its derivatives, whereas a specification license confers rights to many possible implementations.  The work at the OWF has been focused on easing the path to the latter.

 

Many possible implementations of a particular copyrighted specification. Perhaps they are not derivative works, but as independent works they are still covered by the patent grant tied to a particular specification. I don't understand the practical distinction you're drawing between "derivatives" and "many possible implementations" when it comes to software standards. I didn't even understand it when we removed the term "derivative works" from the patent grant in OWFa. But I agree to keep the concepts separate as long as you don't make too big a deal of keeping them apart.

 

But then again, as Eran suggested, perhaps this discussion ought to be moved somewhere else where people are actually interested in the esoteric subjects of copyright and patent law, and where angels dancing on pins is a joy to debate.

 

/Larry

 

 

 

From: open-we...@googlegroups.com [mailto:open-we...@googlegroups.com] On Behalf Of DeWitt Clinton
Sent: Friday, November 13, 2009 8:46 AM
To: open-we...@googlegroups.com
Subject: [Open Web Board] Re: Approval for OWFa

 

Response inline:

[Chris Messina]

+1 to Dewitt's point about not supporting proposing the OWFa as a new
source code license
+1 to Tantek's point about positioning OWFa as complementary to OS
licenses.
+1 to Brett's suggestion that Larry approach the OSI about getting
OWFa vetted for compatibility with OSI-approved licenses.

I would only add that it's extremely important that we keep the scope
of this document narrow and explicit.

The branding that we're going for is something akin to a Creative
Commons that applies to patents related to computer formats and
protocols. We're not really dealing with copyrights here (as has been
pointed out) and since there's enough confusion in the marketplace
already, we must stick to the area of law where we can make the most
significant amount of impact (while also raising awareness to the
problem that gave rise to the OWF originally).

Thus, especially while we're still establishing ourselves, I would not
spend any efforts pursuing adjacent goals, regardless of how
meritorious they may be on their own.

Chris

[Lawrence Rosen]

Chris Messina wrote:
> +1 to Brett's suggestion that Larry approach the OSI about getting
> OWFa vetted for compatibility with OSI-approved licenses.

Danese Cooper, long on the OSI board, has joined our License Drafting
Subcommittee. I'm sure we'll get her vetting help.

/Larry

> -----Original Message-----
> From: Chris Messina [mailto:chris....@gmail.com]
> Sent: Monday, November 16, 2009 7:39 PM
> To: open-web-board
> Subject: [Open Web Board] Re: Approval for OWFa
>

> --
> You received this message because you are subscribed to the Google
> Groups "open-web-board" group.
> To post to this group, send email to open-we...@googlegroups.com
> To unsubscribe from this group, send email to
> open-web-boar...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/open-web-board?hl=en
> For more information: http://openwebfoundation.org/