Re: Option 3

Larry, all,

This whole discussion is highly confusing and at the same time
enlightening to me. (I speak for myself here, as an invited expert
that is contributing to the development of the HTML5 specification).

I have a few questions of clarification inline, if I may.


On Thu, Mar 10, 2011 at 3:29 PM, Lawrence Rosen <lrosen@rosenlaw.com> wrote:
> Ian, I'm confused by your references to the GPL, but first, addressing your
> list of use cases:
>
>
>
>> http://lists.w3.org/Archives/Public/public-html/2009Feb/0093.html
>
>>
>
>> If we number the nine use cases in that e-mail consecutively starting
>
>> from 1, then use cases 6 and 7 are first-person use cases for me.
>
>
>
> This is my own analysis of the nine use cases in the earlier email you
> referenced:
>
>
>
> Use Case 1: Satisfied by all options being considered by PSIG.
>
> Use Case 2: Satisfied by all options being considered by PSIG.
>
> Use Case 3: Satisfied by all options being considered by PSIG.
>
> Use Case 4: Satisfied by all options being considered by PSIG.
>
> Use Case 5: Satisfied by all options being considered by PSIG.

I wonder if with use case 5 it is implied that a situation like the
WHATWG's situation is implied. If not, let me just ask this question
of clarification: if somebody was to create an outside organisation
that wanted to develop let's call it HTML2020, and they wanted to copy
all of the spec text of HTML5 and start from there, modifying it and
bringing it out as a new specification, then that is allowed by this
option (or any of the others)?

>From what I've gathered, the answer may be: no, it's not expressly
allowed, but it's also not legally forbidden. Is this correct?

Can you explain why it would not be legally forbidden and how this
somebody would know that it's not legally forbidden, when it's not
expressly allowed?

I'm asking this because in the past for software we have seen the
positive consequences that empowering people to make derivative works
(or source-code forks - see below) has on innovation: those forks that
were successful became the de-facto standards and those that didn't
get support were eventually dropped on the floor. This is in
particular the model of GitHub, which has spawned much more innovation
than e.g. the model of SourceForge, which implicitly allowed people to
make derivative works, but discouraged it because setting up a new
project required a huge amount of effort. I am fully aware that this
comparison is a bit lopsided even still because at least SourceForge's
open source software licenses typically include an explicit statement
that derivative works are allowed. Not including such a statement
introduces a barrier to forking that is often too high.


> Use Case 6: See comment (a) and (b) below.
>
> Use Case 7: See comment (a) below.
>
> Use Case 8: See W3C Document License. Is that enough?
>
> Use Case 9: Satisfied by all options being considered by PSIG.
>
>
>
> Comment (a) regarding Use Cases 6 and 7: Nothing in W3C policy would prevent
> you from referencing the official W3C HTML5 specifications as an external
> specification in any venue and posting descriptions of functional
> modifications to it that you intend to implement; that alone is not a
> derivative work, although you might generically refer to that as a "fork" of
> the specification. To call a "fork" a "derivative work" is to make certain
> assumptions about whether portions are copied or merely referenced, and
> about whether functional parts of specifications are even subject to
> copyright.
>
>
>
> Comment (b) regarding Use Case 6: If W3C or the HTML WG ceases operations,
> why do you doubt that you'd be allowed to continue in a non-W3C venue? Who
> will stop you from forking by reference? There is an apparent paranoia here
> about W3C that predates me, and makes it difficult to nail down the use
> cases. If you don't trust W3C to honor its licenses, why are we bothering?
>
>
>
> Here is where you confused "fork" with "derivative work".
>
>
>
>> As far as I can tell, however, any solution
>
>> compatible with the GPL would automatically enable any forking use
>
>> case, which is why I pay attention to that aspect: I don't mind if my use
>
>> cases are addressed directly with a license that explicitly allows forking
>
>> the specs or indirectly via the GPL.
>
>
>
> All options considered by PSIG allow "forking of the specs or indirectly via
> the GPL." As to whether you could publish *derivative works* of the official
> W3C HTML5 specifications *as a specification*, ask your own lawyer. But I'm
> aware that W3C Members don't want you to do so without obtaining express
> permission from W3C.

Does this mean that the W3C Members explicitly want to avoid another
situation like the WHATWG one? I am confused about this, because I do
wonder where we would be today if the WHATWG hadn't stepped forward
and picked up the ball that W3C dropped. Also, from experience with
software projects and human nature, I can tell you that it will happen
again. In fact, the W3C was initially created because the IETF was not
able to move fast enough with the specs that needed to be created for
the Web to exist, so history has already repeated itself.


> Option 3 does not give you that express permission;
> neither does it expressly forbid it, which gets around the GPL "further
> restrictions" problem.
>
>
>
> You can "fork" as long as you don't distribute a "derivative work" *as a
> specification*.


A "fork" in a software sense cannot be done by reference - you have to
copy the original source code and modify that. Do I understand
correctly that that would be regarded as "derivative work"? It is this
meaning of "source-code forks" that I have used in the above statement
for "derivative work". I apologize if I have used this incorrectly. I
am still trying to understand your use of words that seem to have a
different meaning in the open source community than in legal speak.


> Your concerns about some of the use cases seems to be confused with the
> apparently new requirement for GPL derivative works of the HTML5
> specifications to be published as a specification. Option 3 would explictly
> allow you to write software that implements your own version of the W3C
> HTML5 specification and then to publish *that* software and its
> documentation *under the terms of the GPL without further restrictions*.
> Isn't that enough? Where in the nine use cases does it say that we need the
> ability to create a new specification that is a derivative work of GPL
> software that is in turn a derivative work of the W3C HTML specification?
> Not that I'm telling you that you can't do it under Option 3 (ask your own
> lawyer), but why would you add that requirement to the nine use cases we're
> already considering? Does anyone really need that permission?
>
>
>
> /Larry


Thanks for your patience in clarifying these issues. It will be good
for the future to clarify exactly the implications of what we are
doing today.

Best Regards,
Silvia.

Received on Thursday, 10 March 2011 05:39:12 UTC