Re: Future code ownership

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

    Frank> Hi -
    Frank> Speaking merely as an interested individual sympathetic
    Frank> outsider, I wonder if jifl correctly understands SPI's
    Frank> relationship to other projects it is associated with:

    >> 6) Software in the Public Interest, Inc. is a US not-for-profit
    >> organisation. <http://www.spi-inc.org/> Its goals are to advance open
    >> source. They are well known already as the copyright holders of many
    >> well known projects like Debian Linux, GNOME, LSB as well as owners of
    >> the Open Source marque, and so on.

    Frank> A quick cursory browse of a bunch of pieces of the gnome
    Frank> distribution shows copyright notices from all sorts of
    Frank> players, FSF, Red Hat, and many individuals. I didn't
    Frank> actually see any SPI copyright notices.

Initial discussions with SPI have already happened, courtesy of Jifl.
AFAIK it is correct that for their other projects SPI do not bother
with copyright assignments, but the different projects can operate
under different rules. For something like GNOME, I suspect there was
never any real possibility of a single copyright holder because bits
of initial code were taken from anywhere if it helped the project.
eCos was managed differently from the beginning.

    Frank> There were a few listed drawbacks of a mixed-copyright
    Frank> future for eCos. Maybe they are not too serious:

    Frank> The problem of lack of single copyright enforcement agent
    Frank> would not be diminished if some of the new code was
    Frank> assigned to SPI or somesuch, for there would still be Red
    Frank> Hat (C) code in there. (Or is one of the ideas to get Red
    Frank> Hat to reassign to SPI too?)

Ideally Red Hat would assign to SPI as well, simplifying the whole
situation. But if they do not, copyright enforcement is still an awful
lot simpler when there only two copyright holders than when there are
hundreds. Also, if a case did arise of copyright or license
infringement then I consider it unlikely that Red Hat would interfere.
Depending on the severity of the infringement they might well choose
to cooperate, in the interest of open source generally.

    Frank> The problem of uncertainty about the trustworthiness of
    Frank> contributors to submit code unimpeded by corporate
    Frank> copyright is not going to go away in any case. You might
    Frank> try requiring submitters to specify the appropriate
    Frank> copyright notice for the new code, in effect making it
    Frank> their onus to determine/state corporate impact. You could
    Frank> then take it at face value.

The assignment process for a corporate employee also involves a
disclaimer form that has to be signed by an officer of the company, as
per the FSF. It would be very hard for a company to then claim the
assignment was invalid and sue for damages. Even if somehow a case
came to court, there would be clear documentation showing that the
maintainers had acted in good faith and had taken all reasonable
precautions. Offhand I cannot remember a single instance where an FSF
project had to remove a contributed patch because the assignment was
invalid.

    Frank> The problem of shipping relicensed (non-GPL) eCos
    Frank> derivatives is probably moot unless Red Hat Officials Of
    Frank> Great Highness see it fit to come to an agreement with you
    Frank> guys. (I clearly have no clue about this.) If no such
    Frank> agreement occurs, then license revenue matters become moot.
    Frank> (... or you could rewrite all that existing code! :-)

The relicensing issue is moot if Red Hat management choose not to
cooperate. Rewriting all the code is theoretically possible (and there
are a few bits that really should be rewritten), but working on new
functionality is a far better use of everybody's time.

Bart