On Mon, Mar 17, 2003 at 07:30:44PM +1000, Anthony Towns wrote:
[ASP condition]
>
> You should never be forced to give your source changes (and/or
> rights to use/modify them) to people who merely use your program
> (but don't already receive copies).
Hmm, I wonder if this could be softened so that it _in practice_ has
the same effect, but does not put a burden on anyone. This would
be similar to the GPL's approach to charging high prices: it's allowed,
but in practice it doesn't become a problem because of the GPL's
other effects.
I'm thinking of a license that extends the proposed DMCA-subversion
clauses, in such a way that everyone who has access to the source also
has permission to copy it. Then, if you add something similar to
GPL's clause 6 ("You may not impose any further restrictions..."),
you get the effect that a network service that uses this software
can only keep its modifications secret if all the developers involved
agree to keep them secret. This will work for single developers
and small groups, as well as for highly motivated groups (such as
dissidents who risk their lives if the modifications are published),
but rapidly becomes unstable for large groups and corporations.
There are two factors that work against this scheme:
- The "no further restrictions" clause would have to butt heads
with confidentiality agreements in employment contracts. This
may make it unusable in practice. Also, a restriction such as
"We'll fire you if you publish this code" is not necessarily
written down anywhere, but could be effective just the same.
- If a company makes a lot of money from its service, then this
could make even a large group of developers highly motivated to
keep the source secret. This assumes that the profit is shared
with these developers :) IIRC, similar cases have occurred with
the GPL, where all the customers of a software development company
decide that it's in their best interest not to publish the software
that they paid good money for.
Still, an approach like this might slip past Anthony's assumptions
and close the "ASP loophole" indirectly.
Richard Braakman
