Re: ocaml, QPL and the DFSG: QPL 6c argumentation.
On Fri, Jul 23, 2004 at 10:23:00PM +0100, Edmund GRIMLEY EVANS wrote:
> Sven Luther <sven.luther@wanadoo.fr>:
>
> > > So I see two chances of getting 6c past debian-legal:
> > >
> > > (1) Claim that the cost of administration is negligible. I think this
> > > goes against tradition.
> >
> > Could you define more precisely what is meant by cost of administration ? I
> > think i am going this way, but it is unclear to me under what assumption you
> > can separate these so called administrative costs from the costs of data
> > transfer. It seems to me to be an artificial distinction. And notice that
> > nothing in QPL 6 is stopping you from charging the upstream author for the
> > binary.
>
> Some things that could come under administration and might not be
> chargeable to the initial developer:
>
> 1. Time spent in forwarding the request to the appropriate person and
> replying to it.
LOL.
> 2. Ensuring copies of the software are kept.
> 3. Getting legal approval for each release to the initial developer.
Well, here i have to say something about this. I am thinking that the 'when
distributed par' also could be gotten to mean that while you are distributing
it, you also has to distribute it to upstream, if asked. No i wonder what a
judge would say once you have EndOfLived the software in question, and the
request comes. While you are distributing it, you have to keep an archive of
it anyway.
> 4. Insurance for the consequences of accidentally releasing
> confidential material.
ReLOL.
And how does this costs don't apply to software released under another free
licence ?
And are you serious about considering this ?
> It wouldn't surprise me if many companies would prefer to send all the
> software upstream at the same as releasing it to avoid the risk of
Ok, cool then.
> dealing with requests later. From the company's point of view the
> situation is then very similar to the situation of being compelled to
> make the software available to the general public.
Why ? You could ask upstream not to release it. And again, if you don't make
public announcement, upstream has no way to know about said software, and if
he does, you have a leak somewhere.
Again, do we really want to care about such far fetched cases ?
> > > In either case you'd still have to cope with the privacy problem,
> >
> > Privacy problem ? Could you clearly define that. If the author is able to make
> > a request to you, your privacy is already lost anyway. This is if i understand
> > this argument right.
>
> As I explained earlier, it might be public knowledge (because of press
> releases and job adverts) that you are modifying compiler X to exploit
> the new CPU architecture that you are developing and that you are
> distributing a prototype of the compiler to partners. However, you
So, if you distribute it to partners, based on the work done by the upstream
author, you can as well distribute it to the upstream authors. And if you
don't like it, don't modify its software. Nowhere in the DFSG does it say that
you have a right to make modifications not widely available. There is enough
licences out there which allow this kind of thing. And in the ocaml case, if
you really like to do this, you become an Ocaml consortium member, and get the
ocaml compiler suite under another licence which is less restrictive.
> don't want to publicly release the code itself because the code would
> reveal details of the CPU architecture that you do not want the world
> to know about yet.
And do we, as debian, want to encourage this kind of thing ? And if you are
going to do this kind of things, you could either not distribute it, reach an
agreement with upstream that they may get a copy of it, but not distribute it
further (and anyway, upstream may be the best one to comment on CPU support
modifications and such).
> > Still, if it is really a private distribution, the upstream author will not
> > know of it, and thus cannot make a request.
>
> As I said: the existence of the distribution is public knowledge, but
> details contained in the code are confidential.
So what ?
> > Anyway, i doubt the privacy issue is worth mentioning, as you said, it is not
> > covered by the DFSG right now, and would need a new guideline to be added, i
> > think. And finally, what do the free software gain by mandating the
> > possibility of private distribution ?
>
> Obviously we can't mandate it; we can just encourage it by Debian
> disapproving of licences that don't allow private distribution.
But this is not what the DFSG says right now. You are naturally free to
propose a GR to add a new DFSG entry about it.
> Gain for Debian: greater confidence that people won't be
> inconvenienced by the licences that apply to stuff in main.
>
> Gain for free software: more people using it.
>
> Loss for Debian: less stuff in main.
>
> Loss for free software: some stuff not being released to the public,
> or not being released so early.
>
> It's anyone's guess whether the gains or the losses are bigger.
Well, i don't know. I suppose that you would then have an NDA that restrict
the partner from speaking about it, or redistributing, thus limiting the
amount of freeness he should normally get. Do we really want to do this ?
> Anyway, there's a third chance of getting 6c past debian-legal, which
> someone brought up in a different thread and which might be the
> strongest yet:
>
> (3) Claim that the rights granted in section 3 of the QPL are
> sufficient to make the software free so there is no need to even look
> at section 6.
No, since they apply to two different things. QPL 3 and 4 is for modifications
of the original software, while QPL 6 is for applications linking with the
software.
Friendly,
Sven Luther
Reply to: