[sclug] Pirate Party UK and Free software
Philip Hands
phil at hands.com
Tue Nov 10 10:53:43 UTC 2009
On Sat, Nov 07, 2009 at 11:14:37PM +0000, Alex Butcher wrote:
> On Sat, 7 Nov 2009, John Barron wrote:
>
>> On Saturday 07 November 2009 13:09:48 Alex Butcher wrote:
...
>> So something based on that is in the current draft, to give software where
>> source code is released (whatever license) a longer period of protection than
>> software released without source code, and which is intended to meet the
>> concerns that RMS raised. We would consider other options, I haven't yet seen
>> any specific proposals however, and also we'd have to persuade RMS/the FSF it
>> was ok... so longer protection for software with source provided is on the
>> table at present.
>
> The main thing then, is to make sure that you've nailed down the definition
> of 'source code' so that deliberately obfuscated source doesn't count. The
> code must build using standard tools, or also include the patches/source
> code for any supplementary tools. It'd be nice to have some build
> requirements and instructions too, but I suppose that might be pushing it.
I'd have thought that the only way of determining that you do have source
is if it's possible for someone independent from the copyright owner
to build a working instance of the copyrighted work (a government test
lab could be used for the cases where one could not already point at
two vendors shipping binaries built from the same source)
That would stop certain vendors from publishing copies under some sort
of shared source scheme, but failing to include the toolchain required
to build it, or simply 'forgetting' that the source they gave out was
not the version that included the DRM code, say.
The main problem is that it seems to regularly happen through simple
incompetence that escrow schemes get a version of source that doesn't
match the shipped product, and wouldn't be buildable anyway. Add malice
to the mix and it's going to be guaranteed.
A formerly binary-only product, seeking to extend its copyright, should
need to publish the code in such a way that it was provable (to the same
standards as when reproducing scientific results for published research)
that it was possible for some unprivileged person to take the published
sources and build something indistinguishable from the work for which the
vendor is seeking to extend cover.
By unprivileged, I mean that they don't get let into the vendors porting
lab, and do the work there, and they don't get access to anything but
the published source and documentation, and standard build tools.
The license for the build tools, if proprietary, would need to be free of
any clauses that would allow the vendor to pull the plug at a later date.
Even then this does not address a vendor that releases code in a
proprietary language, for which they produce the only compiler, and
build the compiler such that it is able to recognise the age of code,
and refuse to build it after a certain date, so that they release code
that does people little good, and then effectively evaporates as it
would have fallen into the public domain.
Writing legal language to differentiate between that, and genuine Free
Software will be a challenge.
That being the case, I'd imagine that vendors with expensive lawyers will
release something a bit like source, and then use that to threaten people
with the choice of cease&desisting or going to court and expensively
proving the the source doesn't match the binary that the defendant has
been distributing.
Given that the vendor will inevitably call the defendant's competence
into question at this point, and point at some not-entirely-independent
lab that has succeeded in building the stuff, the case goes on, the judge
loses the will to live and whoever has the deepest pockets wins.
This seems sub-optimal.
Hence the need for probably independent test labs.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
More information about the Sclug
mailing list