[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OSD && DFSG - different purposes - constructive suggestion!

On Sun, Mar 09, 2003 at 10:19:16PM -0600, Steve Langasek wrote:
> > Does it make it anything you might want to do with free software
> > technically any more difficult? I don't think so -- you have to be asked
> > by the original author, and they have to cover your costs in fulfulling
> > the request.
> I believe that there IS a fundamental difficulty with such licenses.
> Consider the case where a company's modifications encode certain business
> logic details.  

This doesn't make something more difficult; it makes you likely to
choose not to base your work on that piece of software. Patch clauses
and notification clauses make things more difficult.

> The information they want to keep secret isn't something
> that can simply be moved out of the code; their secrets are woven into
> the functionality of the code itself.  If the original author is a
> competitor, or a competitor buys off the original author, any "you must
> provide your changes when asked" condition makes it non-viable to use
> this software for certain applications which are otherwise protected by
> current free software licenses.

Sure. Compare this to some code using the GPL; same sort of information,
same problem with it: their trade secrets are woven into the functionality
of the code itself. If one of your customers is a competitor, or a
competitor buys out a user, any requirement to distribute source to your
users makes it non-viable to use the software for certain applications
which are, eg, protected by BSD-style licenses.

What's the difference? Why should Debian choose to ensure one company
can merge in their trade secrets into any part of Debian, but not ensure
the other company can do likewise?

The argument "not requiring public access is important because privacy
is important" is circular, so invalid. It might be what you think,
but it doesn't form an argument, so you're left with reasonable people
disagreeing, and given the QPL's set a fairly unsubtle precedent on this,
you can't standardise on it just because you feel that it's right.

Arguments about practicality, that this makes doing legitimate things harder
or impossible in some situations for purely technical reasons (the stranded
on an island test does this), are valid, but I haven't really seen any.

Arguments that certain people might be forced to choose a different
program to work with to protect IP concerns don't seem relevant unless
they are clearly worse than the BSD v GPL case.

Another possibility is that getting such clauses *right*, in a way that
can't be abused by the author to harass the user, or otherwise create
an undue burden on the user, is impossible -- that we haven't seen any
examples which do this remotely well; but that the possibility remains
that one day we would, and we'd be willing to accept that license into
main. That is, there isn't anything fundamentally wrong with this,
as long as the user's costs can be minimised [0].

Maybe there are other possibilities?

(And yes, I do realise I was arguing the other side of this just a day
or two ago)


[0] Which is the reason my example limits this to the original author,
    and only kicks in when the original author specifically asks, and
    then requires the original author to cover the user's costs.

Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
        you are now certified as a Red Hat Certified Engineer!''

Attachment: pgpWUk3niLyak.pgp
Description: PGP signature

Reply to: