Uh-Oh(Slashdot news story)
Danny Jones
Paul F. Johnson
the process of poking various fingers onto keys Danny Jones generated
this:
> http://slashdot.org/articles/03/02/07/2225224.shtml?tid=117&tid=106
Whoa!
If it really is the case, then Castle could really be in the brown smelly
stuff!
TTFN
Paul
Stuart Marshall
> http://slashdot.org/articles/03/02/07/2225224.shtml?tid=117&tid=106
Ouch, this is potentially the worst news this platform has
had since black Thursday.
Someone (in the know) has to fully investigate this, and
if appropriate respond (possibly legally) quickly before
it really gets out of hand -- I've not seen an "Acorn"
type thread grow at such a rate, EVER.
Who made the original accusation, and based on what? I
personally didn't think Castle had anything to do with
the RISC OS license, so are the accusations aimed at
Pace?
Either way it's hardly the press we need.
Regards,
Stuart.
Stuart Marshall
> Who made the original accusation, and based on what? I
> personally didn't think Castle had anything to do with
> the RISC OS license, so are the accusations aimed at
> Pace?
Sorry to follow up my own posting so quickly, but it
looks as though Russell King made the original
accusation - he of ARM Linux fame. Russell is very
well respected in the Linux community and he carries
a great deal of credibility.
... this is very bad, very bad indeed.
It seems to be down to the PCI bridge that the version
of RISC OS in the Iyonix uses.
I'm sure more information on this one will break very
soon...
Regards,
Stuart.
Martin Dann
Stuart Marshall <stu...@spidersoft.co.uk> wrote:
http://lkml.org/archive/2003/2/7/55/index.html
Russell King is publiseing the issue for Linux, and they
allege that some of the PCI stuff and other IO stuff is
copied from Linux GPL source.
People on slashdot are also claiming that some of the
documentation for the PCI stuff is copied from Linux,
and that castle recommend people who want to write
drivers look at the Linux source/documentation for the
drivers.
Could we also ask how much Linux PCI documentation is actually
copyright the developer of the hardware, and thus it is in the
hardware devolopers best interest for castle to distribute the
documentation.
Martin.
--
According to the human genome project, humans are 50-60% bananas.
Chris Williams
On Fri, 7 Feb 2003, Danny Jones wrote:
> Read here:
> http://slashdot.org/articles/03/02/07/2225224.shtml?tid=117&tid=106
Also here:
http://www.drobe.co.uk/riscos/artifact556.html
--
Chris Williams | http://arabella.diodesign.co.uk/
John Cartmell
[SNIP]
a great deal of nonsense without checking any facts.
Not to mention issuing threats and encouraging guerilla warfare. ;-(
I doubt if anyone understands what has happened and how (if anything) but
the publicity is bad. Some of the bits I do understand show that the
disputants are clearly propagating false statements. That's not surprising.
Let's hope Castle can come up with a clear explanation and turn round the
publicity into Any publicity is ...
--
John Cartmell jo...@cartmell.demon.co.uk FAX +44 (0)8700-519-527
Acorn Publisher magazine & http://www.acornpublisher.com
Fleur Designs (boardgames)
Michael Gerbracht
> In article <60a847c14b%Mar...@f451.freeserve.co.uk>, Martin Dann
> <Mar...@f451.freeserve.co.uk> wrote:
> > People on slashdot are also claiming
> a great deal of nonsense without checking any facts.
> Not to mention issuing threats and encouraging guerilla warfare. ;-(
> I doubt if anyone understands what has happened and how (if anything) but
> the publicity is bad. Some of the bits I do understand show that the
> disputants are clearly propagating false statements. That's not surprising.
> Let's hope Castle can come up with a clear explanation and turn round the
> publicity into Any publicity is ...
I don't like this kind of publicity either but it seems that Castle did not
answer e-mails with that topic before it went public.
However, if you read what Justin Flatcher writes about it than you will see
that there are some interesting facts that show that the code used in RISC OS
5 and the code produced by compiling the linux kernel are very common.
You will find a link to Justins page in this article (Update-Section):
http://www.drobe.co.uk/riscos/artifact556.html
Michael
Michael Gerbracht
> Read here:
> http://slashdot.org/articles/03/02/07/2225224.shtml?tid=117&tid=106
So is this why some people said that RISC OS 5 is illegal? All rumors
concentrated on a licensing issue between Castle and Pace.
Michael
Simon Challands
John Cartmell <jo...@cartmell.demon.co.uk> wrote:
> In article <60a847c14b%Mar...@f451.freeserve.co.uk>,
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > People on slashdot are also claiming
>
> [SNIP]
>
> a great deal of nonsense without checking any facts.
>
> Not to mention issuing threats and encouraging guerilla warfare. ;-(
>
> I doubt if anyone understands what has happened and how (if anything) but
> the publicity is bad. Some of the bits I do understand show that the
> disputants are clearly propagating false statements. That's not surprising.
It certainly seems like that at the moment. Has there been any evidence
whatsoever that Castle has broken the GPL? Or is it a completely un-
justified piece of scaremongering? AFAICT it's all based on the suggestion
from Castle that developers look to Linux to help develop drivers.
> Let's hope Castle can come up with a clear explanation and turn round the
> publicity into Any publicity is ...
If it was the other way around (bits of RISC OS wandering into something
GPLed, for Linux) then most of those Slashdotters would probably be leaping
on the defence. You're right, Castle need to come up with a statement
ASAP.
This whole debacle has revealed Slashdot readers as being as ignorant,
or as keen to attack at the slightest rumour, as Microsoft might do to
them. And it's not the first time this has happened (I'm thinking of some
of the posts that were made when the Iyonix was first released).
--
Simon Challands, creator of
The Acorn Elite Pages: http://elite.acornarcade.com/
Three Dimensional Encounters: http://www.3dfrontier.fsnet.co.uk/
John Kortink
<please...@hotmail.com> wrote:
>In message <4bc14b7...@cartmell.demon.co.uk>
> John Cartmell <jo...@cartmell.demon.co.uk> wrote:
>
>> In article <60a847c14b%Mar...@f451.freeserve.co.uk>,
>> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
>> > People on slashdot are also claiming
>>
>> [SNIP]
>>
>> a great deal of nonsense without checking any facts.
>>
>> Not to mention issuing threats and encouraging guerilla warfare. ;-(
>>
>> I doubt if anyone understands what has happened and how (if anything) but
>> the publicity is bad. Some of the bits I do understand show that the
>> disputants are clearly propagating false statements. That's not surprising.
>
>It certainly seems like that at the moment. Has there been any evidence
>whatsoever that Castle has broken the GPL? Or is it a completely un-
>justified piece of scaremongering?
I think the evidence from mr. Fletchers (sponsored ?) work in
comparing the two pieces of code is pretty solid. GPL'ed code
/was/ used.
Which is, for obvious reasons to those who know what GPL means,
pretty serious. The sole fact that code was ripped to solve a
pretty fundamental problem (handling PCI in this case) suggests
that someone decided to cut corners (gosh, we haven't seen that
one before ...) and probably did it without fully realising the
consequences (or didn't expect to be found out).
Bad move. Very bad PR.
I think discussion time would be better spent on fathoming why
hardly anybody in this little RISC OS world seems to want to do
a job (or let a job be done) properly.
John Kortink
Email : kor...@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink
ViewFinder, the high performance graphics card for RISC PC's :
visit http://www.windfall.nl for more details and pricing.
Tim Hill
What has probably happened is what happens every day in every other
industry on this planet.
Someone has a good idea. Someone else, for expedience's sake, adapts and
modifies, rather than re-creates.
It's called 'not re-inventing the wheel'.
Now, whether it is A Good Thing in the RISC OS industry is another
matter. Certainly foolish but how is any project manager to know whether
a programmer has saved himself the hassle of coming up with something
original?
Then again, they could have the same regard for copyright/licensing
issues as many businesses, schools and amdram groups of my experience.
None.
--
mailto: 1...@invalid.org.uk is invalid and will not work
visit www.timil.com to contact me directly.
(Visit http://www.invalid.org.uk/ to obtain your own spam-proof address.)
... "God send everyone their heart's desire !" Much Ado, Act iii, Sc.4
Simon Challands
John Kortink <kor...@inter.nl.net> wrote:
> >It certainly seems like that at the moment. Has there been any evidence
> >whatsoever that Castle has broken the GPL? Or is it a completely un-
> >justified piece of scaremongering?
>
> I think the evidence from mr. Fletchers (sponsored ?) work in
> comparing the two pieces of code is pretty solid. GPL'ed code
> /was/ used.
I saw that after my last post. I don't know how conclusive that evidence
is, since I see some research and a conclusion drawn by someone else. I'm
don't know enough on the subject of compiled code to know if that is a
solid conclusion. Some of it sounded rather contrived (let's do this, that,
and the other to make it fit), but as I said, I don't really know if that
is significant or not.
I smell a rat in any case - the date for the first version of that
analysis was 25th Nov, which seems very soon after the launch of the
Iyonix. What made people start examing the OS code in that sort of detail
so soon?
> Which is, for obvious reasons to those who know what GPL means,
> pretty serious. The sole fact that code was ripped to solve a
> pretty fundamental problem (handling PCI in this case) suggests
> that someone decided to cut corners (gosh, we haven't seen that
> one before ...) and probably did it without fully realising the
> consequences (or didn't expect to be found out).
That would seem unlikely. I think if they intended to use GPL code they
would have had a good read through the GPL first.
If it is true and is down to ignorance of the GPL, then it's not cutting
corners, it's not reinventing the wheel.
> Bad move. Very bad PR.
Bad move if it's true, yes. If it was GPL code, though, have Castle yet
broken the license? Have they said they won't release that bit of source?
Has anyone asked them for it and been refused? Whatever some people might
read from the GPL, it wouldn't make the whole of RISC OS come under it
(even if Castle exclusively owned RO in the first place, which of course
they don't). If it's only the PCI code, and that can be demonstrated as
being quite seperable from the rest, then releasing everything associated
with that ONLY should, if there is a GPL breach, resolve it. There are a
few other issues, based on a quick skimming through that I've done, which
it might be possible to argue around.
> I think discussion time would be better spent on fathoming why
> hardly anybody in this little RISC OS world seems to want to do
> a job (or let a job be done) properly.
That seems like a pretty pointless dig to me.
John Kortink
<please...@hotmail.com> wrote:
>In message <p8s94v4vq3rnalqoh...@4ax.com>
> John Kortink <kor...@inter.nl.net> wrote:
>
>> >It certainly seems like that at the moment. Has there been any evidence
>> >whatsoever that Castle has broken the GPL? Or is it a completely un-
>> >justified piece of scaremongering?
>>
>> I think the evidence from mr. Fletchers (sponsored ?) work in
>> comparing the two pieces of code is pretty solid. GPL'ed code
>> /was/ used.
>
>I saw that after my last post. I don't know how conclusive that evidence
>is, since I see some research and a conclusion drawn by someone else. I'm
>don't know enough on the subject of compiled code to know if that is a
>solid conclusion. Some of it sounded rather contrived (let's do this, that,
>and the other to make it fit), but as I said, I don't really know if that
>is significant or not.
I think mr. Fletcher's elaborate account only reflects that
he chooses to be careful even in the presence of what is
basically overwhelming evidence (if you know anything about
programming and compilers, which some readers on here might
not).
A commendable attitude (for a change). And the result stands,
at least to those who have a detailed understanding of the
issues in hand.
>I smell a rat in any case - the date for the first version of that
>analysis was 25th Nov, which seems very soon after the launch of the
>Iyonix. What made people start examing the OS code in that sort of detail
>so soon?
Yes, I noticed that too. It does seem to be a curious date.
>> Which is, for obvious reasons to those who know what GPL means,
>> pretty serious. The sole fact that code was ripped to solve a
>> pretty fundamental problem (handling PCI in this case) suggests
>> that someone decided to cut corners (gosh, we haven't seen that
>> one before ...) and probably did it without fully realising the
>> consequences (or didn't expect to be found out).
>
>That would seem unlikely. I think if they intended to use GPL code they
>would have had a good read through the GPL first.
Reading it does not equal the willingness to comply with it.
>If it is true and is down to ignorance of the GPL, then it's not cutting
>corners, it's not reinventing the wheel.
It's both.
>> Bad move. Very bad PR.
>
>Bad move if it's true, yes. If it was GPL code, though, have Castle yet
>broken the license? Have they said they won't release that bit of source?
It's not the 'bit of source' they would need to release. It's all
of it. Probably the entire source code of RISC OS, since the PCI
code is not 'the work', as it cannot stand on its own.
They are also required to give proper credit. They don't seem to
have done that.
Hastily removing the function signatures from the object code is
not exactly a sign of good will either.
>Has anyone asked them for it and been refused? Whatever some people might
>read from the GPL, it wouldn't make the whole of RISC OS come under it
>(even if Castle exclusively owned RO in the first place, which of course
>they don't). If it's only the PCI code, and that can be demonstrated as
>being quite seperable from the rest, then releasing everything associated
>with that ONLY should, if there is a GPL breach, resolve it.
They might like to try. It's up to the specifics of the GPL license.
Paul F. Johnson
By the process of poking various fingers onto keys Simon Challands
generated this:
> I smell a rat in any case - the date for the first version of that
> analysis was 25th Nov, which seems very soon after the launch of the
> Iyonix. What made people start examing the OS code in that sort of detail
> so soon?
That doesn't matter - the point is that (via the link on drobe's webpage)
Justin Fletcher has done some analysis on the code and found that GPL was
used.
Now what does that actually mean?
Well, if it is the case that Castle *have* used GPL code as part of the
kernel or any part of their system, then the version of RISC OS used in
the Iyonix also has to be made open source which in effect brings the
value of RISC OS to Pace to be zero. I doubt that Pace would sit around
and do nothing. For one thing, by association, it could make it look like
Pace themselves would be trying to break the GPL unless they deny totally
and unequivicoably (sp?) that their version of RISC OS contained nothing
which was GPL. It would also have a knock on effect for RISCOS Ltd as
FWIU most of Select's main goodies are in the Castle RISC OS - who in
their right mind will then buy Select when they can compile it themselves.
I don't know the full agreement Castle had with Pace over OS 5 so cannot
comment on that, but the use of GPL in a closed source commercial package
is a definate no-no which even Pace understands!
(As an aside, I have had a couple of emails from friends working for M$
who are following this very closely - it would be extremely ironic if the
Castle/GPL affair actually causes the death of both Linux and RISC OS in
one swoop - it is possible that if it is true and Castle get away with
including GPL code in a closed source project that M$ will do the same
with Windows and have UK law as a precedence. It will also add weight to
M$'s current claims that the GPL is anti-competative in the US senate
hearings currently going on).
If it is *not* true (and is proven by Russell King having full access to
the Castle sources as well as the compiled binary and him giving it the
all clear publically [and possibly even Linus himself doing the same])
then we can go on.
One thing is for certain, this is a big blow for Castle's credibility,
especially if the claims that Russell's emails were ignored and the tags
removed to try and hide the code used are true. Given the Iyonix board is
also a good testbed for Intel developers, the sales figures will take a
beating.
The next couple of days will be *very* interesting....
TTFN
Paul
Simon Challands
John Kortink <kor...@inter.nl.net> wrote:
> On Sat, 08 Feb 2003 13:05:11 GMT, Simon Challands
> <please...@hotmail.com> wrote:
>
> >If it is true and is down to ignorance of the GPL, then it's not cutting
> >corners, it's not reinventing the wheel.
>
> It's both.
If you've got something that already works it's daft not to reuse it. The
principal of using existing code is perfectly sensible and not in question.
It's just where that code came from, and if they were right to do what
they did.
> >> Bad move. Very bad PR.
> >
> >Bad move if it's true, yes. If it was GPL code, though, have Castle yet
> >broken the license? Have they said they won't release that bit of source?
>
> It's not the 'bit of source' they would need to release. It's all
> of it. Probably the entire source code of RISC OS, since the PCI
> code is not 'the work', as it cannot stand on its own.
I think that could be easily argued out of, and they can't give the whole
of RISC OS away, anyway, since it isn't theirs to give away. If the code
originated from Pace that might be another matter altogether. I think it
would be possible to argue that the PCI code is separate enough to be
considered on its own, and since you could put together a working version
of RO without it. I can't see at all how it would affect all the other
modules that make up RO that have nothing to do with PCI.
> They are also required to give proper credit. They don't seem to
> have done that.
This is still making the assumption that they are guilty as charged, and
there's been no definitive proof yet. Remember "innocent until proven
guilty". If they are proven to be guilty then they could say they will add
it where appropriate, although I don't know where it could be added other
than in manuals.
> Hastily removing the function signatures from the object code is
> not exactly a sign of good will either.
Have they?
> >Has anyone asked them for it and been refused? Whatever some people might
> >read from the GPL, it wouldn't make the whole of RISC OS come under it
> >(even if Castle exclusively owned RO in the first place, which of course
> >they don't). If it's only the PCI code, and that can be demonstrated as
> >being quite seperable from the rest, then releasing everything associated
> >with that ONLY should, if there is a GPL breach, resolve it.
>
> They might like to try. It's up to the specifics of the GPL license.
And exactly how you define the various terms in it. There are always
different interpretations about everything, and certainly enough ambiguity
to cause lots of legal wrangling.
John Kortink
<please...@hotmail.com> wrote:
>In message <ll0a4vksobdr7mmao...@4ax.com>
> John Kortink <kor...@inter.nl.net> wrote:
>
>> On Sat, 08 Feb 2003 13:05:11 GMT, Simon Challands
>> <please...@hotmail.com> wrote:
>>
>> >If it is true and is down to ignorance of the GPL, then it's not cutting
>> >corners, it's not reinventing the wheel.
>>
>> It's both.
>
>If you've got something that already works it's daft not to reuse it. The
>principal of using existing code is perfectly sensible and not in question.
>It's just where that code came from, and if they were right to do what
>they did.
Sure. But 'not reinventing the wheel' is pretty odd terminology when
applying to a case where the source code is basically stolen goods
and/or is misprepresented and/or is not being paid for ... If you
use someone elses code, at the /very least/ authorship should come
forward somewhere. It's nowhere to be seen here.
>> >> Bad move. Very bad PR.
>> >
>> >Bad move if it's true, yes. If it was GPL code, though, have Castle yet
>> >broken the license? Have they said they won't release that bit of source?
>>
>> It's not the 'bit of source' they would need to release. It's all
>> of it. Probably the entire source code of RISC OS, since the PCI
>> code is not 'the work', as it cannot stand on its own.
>
>I think that could be easily argued out of, and they can't give the whole
>of RISC OS away, anyway, since it isn't theirs to give away.
That's their problem. They still have a license to comply to.
E.g. they'd have to buy the source from Pace.
>If the code
>originated from Pace that might be another matter altogether. I think it
>would be possible to argue that the PCI code is separate enough to be
>considered on its own, and since you could put together a working version
>of RO without it. I can't see at all how it would affect all the other
>modules that make up RO that have nothing to do with PCI.
But unfortunately those parts are never sold seperately from the
others ...
>> They are also required to give proper credit. They don't seem to
>> have done that.
>
>This is still making the assumption that they are guilty as charged, and
>there's been no definitive proof yet. Remember "innocent until proven
>guilty". If they are proven to be guilty then they could say they will add
>it where appropriate, although I don't know where it could be added other
>than in manuals.
So, go on Iyonix owners, scan your manuals.
>
>> Hastily removing the function signatures from the object code is
>> not exactly a sign of good will either.
>
>Have they?
Allegedly.
>> >Has anyone asked them for it and been refused? Whatever some people might
>> >read from the GPL, it wouldn't make the whole of RISC OS come under it
>> >(even if Castle exclusively owned RO in the first place, which of course
>> >they don't). If it's only the PCI code, and that can be demonstrated as
>> >being quite seperable from the rest, then releasing everything associated
>> >with that ONLY should, if there is a GPL breach, resolve it.
>>
>> They might like to try. It's up to the specifics of the GPL license.
>
>And exactly how you define the various terms in it. There are always
>different interpretations about everything, and certainly enough ambiguity
>to cause lots of legal wrangling.
I suppose the outcome of a lawsuit would establish that one.
Dickon Hood
: In message <p8s94v4vq3rnalqoh...@4ax.com>
: John Kortink <kor...@inter.nl.net> wrote:
:> >It certainly seems like that at the moment. Has there been any evidence
:> >whatsoever that Castle has broken the GPL? Or is it a completely un-
:> >justified piece of scaremongering?
:> I think the evidence from mr. Fletchers (sponsored ?) work in
:> comparing the two pieces of code is pretty solid. GPL'ed code
:> /was/ used.
: I saw that after my last post. I don't know how conclusive that evidence
: is, since I see some research and a conclusion drawn by someone else. I'm
: don't know enough on the subject of compiled code to know if that is a
: solid conclusion. Some of it sounded rather contrived (let's do this, that,
: and the other to make it fit), but as I said, I don't really know if that
: is significant or not.
Having read it, I'd say the Justin's analysis is probably correct: GPLled
code was almost certainly ripped off from a 2.5.x Linux kernel tree.
: I smell a rat in any case - the date for the first version of that
: analysis was 25th Nov, which seems very soon after the launch of the
: Iyonix. What made people start examing the OS code in that sort of detail
: so soon?
PCI is a complex system, and initialising devices is not a particularly
easy thing to do. In the absense of any example code from the chipset
manufacturers (common), you tend to look elsewhere rather than the
documentation (which is often inaccurate, buggy, and incomplete). The
Linux kernel is an obvious place to look for 'inspiration'. Anyone
interested in PCI on ARM devices, particularly anyone with an interest in
RISC OS as well, would have looked in the OS for interest's sake, just to
see how they'd done it.
I've worked on PCI devices under RISC OS, and having other source to look
at was very helpful. And no, I didn't copy it and compile, I used it to
check that what I was doing was correct.
A better place to look is, of course, the various BSDs. Their licence
basically says 'do what you like with it, just credit us in the docs'.
Had they 'stolen' the code from NetBSD/arm32 (a logical place to look),
this issue wouldn't have arisen; Acorn did the same thing with the IP
stack.
:> Which is, for obvious reasons to those who know what GPL means,
:> pretty serious. The sole fact that code was ripped to solve a
:> pretty fundamental problem (handling PCI in this case) suggests
:> that someone decided to cut corners (gosh, we haven't seen that
:> one before ...) and probably did it without fully realising the
:> consequences (or didn't expect to be found out).
: That would seem unlikely. I think if they intended to use GPL code they
: would have had a good read through the GPL first.
: If it is true and is down to ignorance of the GPL, then it's not cutting
: corners, it's not reinventing the wheel.
:> Bad move. Very bad PR.
: Bad move if it's true, yes. If it was GPL code, though, have Castle yet
: broken the license? Have they said they won't release that bit of source?
: Has anyone asked them for it and been refused?
According to Russel King's email, yes, someone asked and got ignored.
: Whatever some people might
: read from the GPL, it wouldn't make the whole of RISC OS come under it
: (even if Castle exclusively owned RO in the first place, which of course
: they don't).
This is one of the grey areas in the licence. RMS says it would, my
non-lawyerish reading says it should, but I have difficulty believing
anyone could make it stick.
GNU have been after a test case for quite some time, as currently the GPL
is untested and nobody knows if it can actually be made to stick. Most
cases are settled amicably out of court, though, as it's usually fairly
easy to prove the case and the companies concerned would rather reduce the
bad publicity to a minimum. I should imagine Castle will do the same.
: If it's only the PCI code, and that can be demonstrated as
: being quite seperable from the rest, then releasing everything associated
: with that ONLY should, if there is a GPL breach, resolve it. There are a
: few other issues, based on a quick skimming through that I've done, which
: it might be possible to argue around.
If the code is buried in the RISC OS kernel, in theory the kernel may have
to be GPLled. If, OTOH, it's in a module in the ROM, there's a good
chance you could argue that only that module would need to be open
sourced (as it'd clearly be a derivative work). It all gets a bit
complex, however...
:> I think discussion time would be better spent on fathoming why
:> hardly anybody in this little RISC OS world seems to want to do
:> a job (or let a job be done) properly.
: That seems like a pretty pointless dig to me.
And the answer seems fairly clear to me: money. There isn't much in this
market, so corner-cutting should be expected.
--
Dickon Hood
Due to constant nagging to change it, my .sig is temporarily unavailable.
Normal service will be resumed as soon as possible. We apologise for the
inconvenience in the meantime.
Steffen Huber
[snip]
> I think the evidence from mr. Fletchers (sponsored ?) work in
> comparing the two pieces of code is pretty solid. GPL'ed code
> /was/ used.
I think there is one fundamental point that has not been proven at all: that
the code in question was only ever licenced under GPL by its original
authors. The fact that the code is also used by the Linux kernel does not
prove anything.
[snip]
Steffen
--
steffe...@gmx.de ste...@huber-net.de
GCC for RISC OS - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/
Simon Challands
John Kortink <kor...@inter.nl.net> wrote:
> On Sat, 08 Feb 2003 13:48:30 GMT, Simon Challands
> <please...@hotmail.com> wrote:
>
> >If you've got something that already works it's daft not to reuse it. The
> >principal of using existing code is perfectly sensible and not in question.
> >It's just where that code came from, and if they were right to do what
> >they did.
>
> Sure. But 'not reinventing the wheel' is pretty odd terminology when
> applying to a case where the source code is basically stolen goods
> and/or is misprepresented and/or is not being paid for ... If you
> use someone elses code, at the /very least/ authorship should come
> forward somewhere. It's nowhere to be seen here.
I think there's some confusion between us here - it sounded to me like
you were objecting to the very principal of not always starting from
scratch. If something is available to use then it makes sense that it
should be. The issue here is that it seems that it wasn't available to
use.
> >I think that could be easily argued out of, and they can't give the whole
> >of RISC OS away, anyway, since it isn't theirs to give away.
>
> That's their problem. They still have a license to comply to.
> E.g. they'd have to buy the source from Pace.
That would mean that Pace would be forced to sell if Castle have to buy it.
I can't see any legal reason why Pace should be forced to do anything if
they hadn't put any GPLed code into RISC OS. I'm guessing here, but Castle
probably have a license that says they can't release the source. Forcing
them to do so would be putting the GPL license before the Pace one, and
forcing control from another party (Pace) without any good reason to. If
this wasn't so then anyone could force a bit of illegal GPL code into
anything as an easy way to make the whole thing open source, which would
be rather ridiculous.
> >If the code
> >originated from Pace that might be another matter altogether. I think it
> >would be possible to argue that the PCI code is separate enough to be
> >considered on its own, and since you could put together a working version
> >of RO without it. I can't see at all how it would affect all the other
> >modules that make up RO that have nothing to do with PCI.
>
> But unfortunately those parts are never sold seperately from the
> others ...
Does that matter? If a suite of programs are always sold together, even
though they are completely independent, and one of them was entirely nicked
GPL stuff and the rest were entirely original then even if there is
something in the GPL that says the others should be made open source I
very much doubt that would stand up in a lawsuit. Of course the issue here
is a lot more blurred.
Grant Randall- Spam trapped
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
Just now - page not available, does this mean it has been removed?
--
Regards,
Grant Randall
--
Grant Randall <grant.rand...@ntlworld.com> Yorkshire, GB
http://homepage.ntlworld.com/grant.randall Randalls Home Page
During shift periods, I may be slow to reply, please bear with me...
Ray Dawson
Grant Randall- Spam trapped <grant.rand...@ntlworld.com> wrote:
> In article <60a847c14b%Mar...@f451.freeserve.co.uk>,
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > http://lkml.org/archive/2003/2/7/55/index.html
> Just now - page not available, does this mean it has been removed?
I just clicked on the above and the page is still there.
Ray D
--
Ray Dawson
r...@magray.freeserve.co.uk
MagRay - the audio & braille specialists
Richard Walker
"Paul F. Johnson" <paulf....@ukonline.co.uk> wrote:
> Well, if it is the case that Castle *have* used GPL code as part of the
> kernel or any part of their system, then the version of RISC OS used in
> the Iyonix also has to be made open source
Hmm...
Just wondering about this sort of thing... what about those binary kernel
modules, such as the NVidia display drivers? How are they licensed? Do
they not include parts of the Linux kernel?
> which in effect brings the value of RISC OS to Pace to be zero.
I disagree. So what if *a* version of RISC OS (that for Iyonix) was forced
open? How does that directly affect other RISC OS versions? It doesn't,
really. There is no reason why Pace couldn't carry on selling their
versions - they are different.
Of course, a technical person might decide that taking the 'open' code and
hacking it about will cost less than licensing a version from Pace, but such
a possibility doesn't *force* Pace to stop selling RISC OS - if you get what
I mean! :-)
> If it is *not* true (and is proven by Russell King having full access to
> the Castle sources as well as the compiled binary and him giving it the
> all clear publically [and possibly even Linus himself doing the same])
> then we can go on.
Why should anyone outside of Castle be given access to their source code on
the basis of an *assumed* GPL violation?
> One thing is for certain, this is a big blow for Castle's credibility,
If this is true, I agree. However, they are still a *MILLION* miles ahead
of RISCOS Ltd., RiscStation and MicroDigital in that game. If any of those
companies are sitting rubbing their hands with glee, then they need not
bother.
> Given the Iyonix board is also a good testbed for Intel developers, the
> sales figures will take a beating.
What?! I don't think so...
--
Richard.
"Michelle, ma belle. These are words that go together well, my Michelle."
Annraoi
<snip>
> This whole debacle has revealed Slashdot readers as being as ignorant,
> or as keen to attack at the slightest rumour, as Microsoft might do to
> them. And it's not the first time this has happened (I'm thinking of some
> of the posts that were made when the Iyonix was first released).
As the people making the assertions do not have the source to RISC OS
5 I don't see how they can DEFINATELY assert that RO5 is a copy of GPL
source (the best they can say is that it PROBABLY is, and then the
case is ARGUABLE). The burden of proof is that they must PROVE their
case... if they do then RO5 will have to have the PCI driver subsystem
redesigned (and any GPL source removed).
As to Castle not replying to emails - why should they THEY DID NOT
WRITE THE OS.
Regards
Annraoi
Paul Stewart
a...@globalcafe.ie (Annraoi) wrote:
Whether Castle did or did not write the OS is not under any dispute. We
all know who wrote the OS. The real question is who wrote the PCI
subsystem - Castle or PACE?
If Castle wrote it, then it is up to them to reply to these alegations.
--
Paul Stewart
RISC OS Select 4.33
Member of Hemel Hempstead RISC OS User Group
http://www.hhrug.org.uk
Be Bold. Dare To Be Different. Use RISC OS.
John Kortink
<please...@hotmail.com> wrote:
>In message <9n5a4vcdkfdk0l40b...@4ax.com>
> John Kortink <kor...@inter.nl.net> wrote:
>
>> On Sat, 08 Feb 2003 13:48:30 GMT, Simon Challands
>> <please...@hotmail.com> wrote:
>>
>
>> >If you've got something that already works it's daft not to reuse it. The
>> >principal of using existing code is perfectly sensible and not in question.
>> >It's just where that code came from, and if they were right to do what
>> >they did.
>>
>> Sure. But 'not reinventing the wheel' is pretty odd terminology when
>> applying to a case where the source code is basically stolen goods
>> and/or is misprepresented and/or is not being paid for ... If you
>> use someone elses code, at the /very least/ authorship should come
>> forward somewhere. It's nowhere to be seen here.
>
>I think there's some confusion between us here - it sounded to me like
>you were objecting to the very principal of not always starting from
>scratch.
I object to it being called 'not reinventing the wheel'. If there
is intent to abuse other people's source code, surely 'cutting
corners' is much more applicable.
Even without that intent, consider what 'not reinventing the wheel',
as you put it, has caused in this case.
>If something is available to use then it makes sense that it
>should be.
Depends on the situation. You could eventually be spending more
time moulding and debugging the 'borrowed' code than you would
have starting from scratch.
>The issue here is that it seems that it wasn't available to
>use.
But, of course, it /was/ available to use. Just not in this way.
It's pretty certain arrangements could have been made to be able
to use it legally without compromising too much.
>> >I think that could be easily argued out of, and they can't give the whole
>> >of RISC OS away, anyway, since it isn't theirs to give away.
>>
>> That's their problem. They still have a license to comply to.
>> E.g. they'd have to buy the source from Pace.
>
>That would mean that Pace would be forced to sell if Castle have to buy it.
They would not be forced to. It's just that Castle would have a
serious problem if they didn't.
>I can't see any legal reason why Pace should be forced to do anything if
>they hadn't put any GPLed code into RISC OS. I'm guessing here, but Castle
>probably have a license that says they can't release the source. Forcing
>them to do so would be putting the GPL license before the Pace one, and
>forcing control from another party (Pace) without any good reason to. If
>this wasn't so then anyone could force a bit of illegal GPL code into
>anything as an easy way to make the whole thing open source, which would
>be rather ridiculous.
Sure, but I'm not implying Pace would be forced to sell. Just that
it could be one way for Castle to get out of the fix.
>> >If the code
>> >originated from Pace that might be another matter altogether. I think it
>> >would be possible to argue that the PCI code is separate enough to be
>> >considered on its own, and since you could put together a working version
>> >of RO without it. I can't see at all how it would affect all the other
>> >modules that make up RO that have nothing to do with PCI.
>>
>> But unfortunately those parts are never sold seperately from the
>> others ...
>
>Does that matter?
Of course it does. A very important question is what is considered
to be 'the work' that the GPL'ed code is part of. An answer will
probably be sought in finding the smallest part of the product
(incorporating the GPL'ed code) that is marketable seperately.
>If a suite of programs are always sold together, even
>though they are completely independent, and one of them was entirely nicked
>GPL stuff and the rest were entirely original then even if there is
>something in the GPL that says the others should be made open source I
>very much doubt that would stand up in a lawsuit.
Yes, but that is only because such a suite of programs could be
split up easily. It'll be pretty hard to prove that parts of RISC
OS are marketable on their own.
Dickon Hood
: Simon Challands <please...@hotmail.com> wrote in message news:<540a86c14b.3dfro...@3dfrontier.fsnet.co.uk>...
: <snip>
:> This whole debacle has revealed Slashdot readers as being as ignorant,
:> or as keen to attack at the slightest rumour, as Microsoft might do to
:> them. And it's not the first time this has happened (I'm thinking of some
:> of the posts that were made when the Iyonix was first released).
: As the people making the assertions do not have the source to RISC OS
: 5 I don't see how they can DEFINATELY assert that RO5 is a copy of GPL
: source (the best they can say is that it PROBABLY is, and then the
: case is ARGUABLE).
Civil matter: balance of probabilities is all that's required, not a
'beyond all reasonable doubt' burden of proof. And having looked at the
evidence, it's pretty damning...
: The burden of proof is that they must PROVE their
: case... if they do then RO5 will have to have the PCI driver subsystem
: redesigned (and any GPL source removed).
Correct. They may be liable for damages, too.
: As to Castle not replying to emails - why should they THEY DID NOT
: WRITE THE OS.
They could at least say that. We're all assuming that Castle wrote the
PCI controller bits of their version of RISC OS 5 (which seems reasonable:
even if they did get a contractor in to actually do the job, they
essentially wrote it) and if that's the case, they could be in trouble.
Of course, it could have been Pace that did that, but I'd be *very*
surprised if it was them, and as far as I can see, nobody has suggested
that it was.
Derek.Moody
<URL:mailto:steffe...@gmx.de> wrote:
> John Kortink wrote:
> [snip]
> > I think the evidence from mr. Fletchers (sponsored ?) work in
> > comparing the two pieces of code is pretty solid. GPL'ed code
> > /was/ used.
>
> I think there is one fundamental point that has not been proven at all: that
> the code in question was only ever licenced under GPL by its original
> authors. The fact that the code is also used by the Linux kernel does not
> prove anything.
Or to go back one more step:
This code addresses a hardware interface problem - there can be very few
worthwhile algorithms and in all probability only one really efficient
approach. All such code is going to be at least similar. If much of it is
based on the published specification/definition of the interface then many
different coders would come up with remarkably similar results.
To take an absurdly simple hypothetical case - reacting to the Big Red
Button; comes down to an 'Is this bit set?' test which would make it an even
bet that two out of three independent coders would come up with the same
solution.
It is not at all unlikely that the eventual code is strongly shaped by prior
publication(s).
Hmmm. And as all publicity is, in the long run, good publicity this
probably won't hurt Iyonix sales in the slightest.
Let's see what next week brings.
Cheerio,
--
>> derek...@clara.net
Paul F. Johnson
By the process of poking various fingers onto keys Richard Walker
generated this:
> In message <pan.2003.02.08....@ukonline.co.uk>
> "Paul F. Johnson" <paulf....@ukonline.co.uk> wrote:
> Just wondering about this sort of thing... what about those binary
> kernel modules, such as the NVidia display drivers? How are they
> licensed? Do they not include parts of the Linux kernel?
The licence for display drivers can be the same as that for RealPlayer - a
binary only (or library only with associated header file). Some folks
(like nVidia) are happy for the linux community to know what is going on.
>> which in effect brings the value of RISC OS to Pace to be zero.
>
> I disagree. So what if *a* version of RISC OS (that for Iyonix) was
> forced open? How does that directly affect other RISC OS versions? It
> doesn't, really. There is no reason why Pace couldn't carry on selling
> their versions - they are different.
Okay, look at this way. OS 5 (Castle) is made open. It is 32 bit clean,
contains a hell of a lot of the goodies from Select. Who in their right
mind will buy the precompiled kernel when an ISO of the sources (with
associated make files) is available? No one (okay, there may be a few, but
like the rest of GPL projects, there is usually a precompiled binary
posted by someone). The Pace version may be different, but unless there is
a radical difference between them, no one will want it. The upshot is the
value of the operating system is zero (financially at least)
> Of course, a technical person might decide that taking the 'open' code
> and hacking it about will cost less than licensing a version from Pace,
> but such a possibility doesn't *force* Pace to stop selling RISC OS - if
> you get what I mean! :-)
Of course it doesn't. But see above why it would not be viable.
>> If it is *not* true (and is proven by Russell King having full access
>> to the Castle sources as well as the compiled binary and him giving it
>> the all clear publically [and possibly even Linus himself doing the
>> same]) then we can go on.
>
> Why should anyone outside of Castle be given access to their source code
> on the basis of an *assumed* GPL violation?
Can you think of a better way to deny an allegation? If the story is true,
Castle have already tried to hide the evidence by removing the tags but
the code is still in there. Given that evidence, would you actually trust
Castle to tell the truth?
>> One thing is for certain, this is a big blow for Castle's credibility,
>
> If this is true, I agree. However, they are still a *MILLION* miles
> ahead of RISCOS Ltd., RiscStation and MicroDigital in that game. If any
> of those companies are sitting rubbing their hands with glee, then they
> need not bother.
They are currently. However look at it again. Did the GPL code problem
come from Pace or Castle? Pace is a *big* company and I personally doubt
they will now just sit there - they will be trying to clean their hands
with some meaty actions in their defence. If one of those actions went
against Castle, it is quite likely that the Iyonix will be operating
system-less. Irt then doesn't matter how far ahead Castle are past ROS Ltd,
RS or MD, they will suddenly find themselves back with just the RPC.
>> Given the Iyonix board is also a good testbed for Intel developers, the
>> sales figures will take a beating.
>
> What?! I don't think so...
Why? The way it works is that if a company has ripped something as well
respected as the GPL off, why won't they do it again? The trust factor
will have gone.
TTFN
Paul
Sandy Morton
Derek.Moody <derek...@clara.net> wrote:
> Hmmm. And as all publicity is, in the long run, good publicity this
> probably won't hurt Iyonix sales in the slightest.
Publicity is normally good but not always - however - I have read a lot of
posts on this subject and I have understood a few.
I really don't care which system I am using if it does the job which I
want it to do.
I am very happy with Prophet, Pluto, Impression the AntSuite and almost
Oregano. I find the PC which is about 5 feet away from me to be more
difficult to use but there are parts which work better. I don't actually
understand either machines internal idiosyncrassies - I do know how to
turn them on.
However to get back on topic - how many people who use computers have any
understanding of the issues being discussed - .00001% seems to me to be a
high percentage?
Therefore, let us not be judgemental, let the companies and people
directly involved sort this out. Let the lawyers make a few more coppers.
But - please - don't speculate, if you have informed information that's
fine but scoring cheap points helps noone.
--
A T (Sandy) Morton
on the Bicycle Island
In the Global Village
http://www.sandymillport.fsnet.co.uk
Danny Jones
"Grant Randall- Spam trapped" <grant.rand...@ntlworld.com> wrote in
message news:4bc199b6a1grant...@ntlworld.com...
> In article <60a847c14b%Mar...@f451.freeserve.co.uk>,
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > http://lkml.org/archive/2003/2/7/55/index.html
> Just now - page not available, does this mean it has been removed?
>
"/. effect".
--
Danny.
====
Guy Inchbald
>John Kortink wrote:
>[snip]
>> I think the evidence from mr. Fletchers (sponsored ?) work in
>> comparing the two pieces of code is pretty solid. GPL'ed code
>> /was/ used.
>
>I think there is one fundamental point that has not been proven at all: that
>the code in question was only ever licenced under GPL by its original
>authors. The fact that the code is also used by the Linux kernel does not
>prove anything.
>
You mean maybe the code was completely free code, borrowed by the GPL
developers? Or maybe Castle/Pace have a commercial license from the
developer? Or maybe ... maybe let's wait and see.
Meanwhile, AIUI the GPL allows GPL executables to lie alongside
proprietary executables, e.g. some free modules alongside some non-free
modules. How much of RO5 is 'infected' and how much remains in
independent bits?
Neil Fazakerley
<g...@steelpillow.com> wrote:
>
> Steffen Huber <steffe...@gmx.de> writes
> >John Kortink wrote:
> >[snip]
> >> I think the evidence from mr. Fletchers (sponsored ?) work in
> >> comparing the two pieces of code is pretty solid. GPL'ed code
> >> /was/ used.
> >
> >I think there is one fundamental point that has not been proven at all:
> that
> >the code in question was only ever licenced under GPL by its original
> >authors. The fact that the code is also used by the Linux kernel does not
> >prove anything.
> >
>
> You mean maybe the code was completely free code, borrowed by the GPL
> developers?
No, he means that one reason the GPL has never been tested in court is that
it embodies one well-known potential fault line, in legal terms. The
original authors of all the code that the GPL is based on have never
officially signed over their rights (legally speaking). So one of the first
things a defence team would do is question the foundation of the GPL itself.
However, let's get real here. If Castle, rather than Pace, were to face some
kind of challenge it's most unlikely that it would involve any kind of court
case. Castle consisting of what, half a dozen core people?, would simply
have to agree to 'cease and desist' and find some way out of any code mess
they might be left in. Perhaps by releasing the main PCI driver section as
open source in future and incorporating some kind of very rudimentary
keyboard/mouse/video bios-like driver code in RO5 to keep it free standing
from the GPL'd bit (don't know if this would be possible). Their main
concern would be to keep extra coding costs down to a level that kept Ionyx
viable (which is presumably why any GPL code might have been 'borrowed' in
the first place).
-Neil F.
--
- f a z @ a r g o n e t . c o . u k -
Neil Fazakerley
<f...@argonet.co.uk> wrote:
>....
snip
> Their main
> concern would be to keep extra coding costs down to a level that kept
^^^^^^
PS. Must learn how to spell Iyonix ;-)
Ralph Corderoy
> As the people making the assertions do not have the source to RISC OS
> 5 I don't see how they can DEFINATELY assert that RO5 is a copy of GPL
> source (the best they can say is that it PROBABLY is, and then the
> case is ARGUABLE).
A prosecution doesn't normally `DEFINATELY assert', it `proves beyond
reasonable doubt'. And in a civil matter it only needs `the balance of
probabilities'.
Can you tell us if you've a technical background, and if so what it is,
when suggesting that without the RO5 source you can't see how they can
prove beyond reasonable doubt that the GPL'd source was taken? Only
from my background, which does cover grovelling through compiler output
on various hardware/OS platforms, I think it's easily possible.
Especially when the copyright infringer has done such a poor job.
Cheers,
--
Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/
Ralph Corderoy
> No, he means that one reason the GPL has never been tested in court is
> that it embodies one well-known potential fault line, in legal terms.
> The original authors of all the code that the GPL is based on have
> never officially signed over their rights (legally speaking).
Are you referring to Linux specifically? Only contributors to GNU
projects, e.g. GNU groff, have to sign and return a copyright assignment
of the work they do to the FSF precisely so the FSF, as copyright
holders, can take action over copyright infringement.
Eben Moglen, Professor of Law and Legal History at Columbia Uni., has
written about GPL enforcement. And he should know.
http://emoglen.law.columbia.edu/
http://emoglen.law.columbia.edu/publications/lu-12.html
http://emoglen.law.columbia.edu/publications/lu-13.html
John Campbell Rees
in message <pan.2003.02.08....@ukonline.co.uk> wrote:
> Okay, look at this way. OS 5 (Castle) is made open. It is 32 bit clean,
> contains a hell of a lot of the goodies from Select. Who in their right
> mind will buy the precompiled kernel when an ISO of the sources (with
> associated make files) is available? No one (okay, there may be a few, but
> like the rest of GPL projects, there is usually a precompiled binary
> posted by someone).
I have heard some deeply stupid things in my time, but this one takes
the biscuit. When the majority of people buy computers, they don't want
the hassle of compiling the operating system before they can use it,
they want to open the box, set th machine up and start using it strait
away. That is why there are so many Windows based computers out there.
even amongst the RISC OS community, most users are not compete techies,
they may know more technical info that the average user, but in the end,
they still want to "plug and play".
--
"Like shooting flies with a laser cannon, the aims a bit tricky, but
it certainly deals with the flies." - Lord Miles Vorkosigan.
From "Komarr" by Lois McMaster Bujold
Paul F. Johnson
By the process of poking various fingers onto keys John Campbell Rees
generated this:
> I have heard some deeply stupid things in my time, but this one takes the
> biscuit. When the majority of people buy computers, they don't want the
> hassle of compiling the operating system before they can use it, they want
> to open the box, set th machine up and start using it strait away. That
> is why there are so many Windows based computers out there. even amongst
> the RISC OS community, most users are not compete techies, they may know
> more technical info that the average user, but in the end, they still want
> to "plug and play".
In that case, they get a machine with the GPL kernel et al pre-installed.
It is not just Windows & RISC OS which comes with a pre-installed OS -
Linux is preinstalled (Lindows) as is MacOSX (BSD based IIRC).
There is nothing deeply stupid about it either. If anything, it's actually
the opposite!
TTFN
Paul
Michael Gilbert
Balls. The only issue is with RISC OS 5 as released by Castle for
Iyonix. They know precisely how many copies they have sold, they can fix
the problem and release a clean bit of code. Of course, this won't
happen tomorrow, and it will break Iyonix in the meantime.
If the GPL really does have this effect, of infecting everything it
comes into contact with, I can well understand Microsoft's attitude to
it.
[snip]
My major concern with all this is that there is a RISC OS programmer
involved in two stages. First, in inserting the code covered by the GPL
into RISC OS 5. Second, in leaking the matter to whoever.
The number of RISC OS programmers on this planet with the ability to do
the stuff needed to make RO5 is not large. Or so we keep being told. In
that case, who is responsible for this? Making up names, say Fred did
the dirty. Did he then report the fact to whatever GPL person himself?
Or did he tell Joe in the pub?
And, I would have thought, if Fred was contracted by Castle to do a
specific job, he is in for a very heavy breach of contract suit from
Castle.
This business reinforces my growing belief that the programming
community is infested with idle gits who know that their customers ain't
gonna be able to check their work, so foist piles of broken and
festering crap on the rest of us. Please note that I really, really
don't mean all programmers are like this. It's probably the tender
mentality, where "best value" means "lowest invoice" rather than
anything longer term. Doing it cheap gets the job, and stuff the
consequences.
So, do we have names for the prime suspects in this case? Do any of them
have the cojones to stand up and be counted?
--
Michael Gilbert: in his own write
"If the Xbox console falls and hits someone, especially a small child,
it may cause serious injury"
Stephen Crocker
John Cartmell <jo...@cartmell.demon.co.uk> wrote:
> In article <60a847c14b%Mar...@f451.freeserve.co.uk>,
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > People on slashdot are also claiming
>
> [SNIP]
>
> a great deal of nonsense without checking any facts.
Usenet/Slashdot in a nutshell.
> Not to mention issuing threats and encouraging guerilla warfare. ;-(
Slashdot in a nutshell.
> I doubt if anyone understands what has happened and how (if anything) but
> the publicity is bad. Some of the bits I do understand show that the
> disputants are clearly propagating false statements. That's not surprising.
> Let's hope Castle can come up with a clear explanation and turn round the
> publicity into Any publicity is ...
Indeed, but I suspect that a lot of damage has been done already. It's up
to Castle to convince prospective customers that they aren't the Satan
worshippers some of the Slashdot crowd seem to think they are and that Iyonix
is a machine worth buying.
OTOH, if it hasn't blackened the name of RISC OS, it might give Omega a
breather if it ever appears...
--
x^ ( ) _________ // Email: mailto:cr...@crok.demon.co.uk
< U O |_|_|_|_|_| O || WWW: http://www.crok.demon.co.uk
\, |/|\ _________ [ ]
. |/^\ . 2 . /__\
...The potato viciously mends the mug, for a lampshade is boredly anvil-like.
Paul F. Johnson
By the process of poking various fingers onto keys Michael Gilbert
generated this:
> In article <pan.2003.02.08....@ukonline.co.uk>, Paul F.
> Johnson <URL:mailto:paulf....@ukonline.co.uk> wrote:
>> Okay, look at this way. OS 5 (Castle) is made open. It is 32 bit clean,
>> contains a hell of a lot of the goodies from Select. Who in their right
>> mind will buy the precompiled kernel when an ISO of the sources (with
>> associated make files) is available? No one (okay, there may be a few,
>> but like the rest of GPL projects, there is usually a precompiled binary
>> posted by someone). The Pace version may be different, but unless there
>> is a radical difference between them, no one will want it. The upshot is
>> the value of the operating system is zero (financially at least)
>
> Balls. The only issue is with RISC OS 5 as released by Castle for
> Iyonix.
Yup. If (as it seems is the case) their version of RISC OS does contain
GPL code, they have to release the source. As theirs is the only 32 bit
clean, hardware abstracted version, then I could well imagine MD, Explan
(if they want a RISC OS laptop) and RiscStation (as well as anyone else)
jumping with joy as they won't be tied down to any one version of RISC OS.
This is the main problem though, Castle can't even though the GPL licence
supercedes any licence they had from Pace. Who do they choose to annoy the
most? Pace (big company, lots of lawyers) or FSF (massive US organisation
who has taken on M$ and won before now). According to gerph over on
channel drobe, Castle have again denied any wrong doing although the
smoking gun is firmly saying the opposite!
> They know precisely how many copies they have sold, they can fix the
> problem and release a clean bit of code. Of course, this won't happen
> tomorrow, and it will break Iyonix in the meantime.
That's not the point. The point is that they distributed something
containing something it shouldn't. Irrespective of it they knew or not,
Castle did the deed. No matter how many denials, it's there for those to
see.
> If the GPL really does have this effect, of infecting everything it comes
> into contact with, I can well understand Microsoft's attitude to it.
Yup. Couldn't agree more. Who'd want to see Windows working properly due
to having a kernel which doesn't screw up every hour or so ;-p
> This business reinforces my growing belief that the programming community
> is infested with idle gits who know that their customers ain't gonna be
> able to check their work, so foist piles of broken and festering crap on
> the rest of us.
Oi. That's incredibly unfair. Unless something is a port, just about
everything for RISC OS is written cleanly. Referring to sources from
someone else but not using them is common right across the programming
community (I've been reading some of my RiscStation source code to help me
out on a Linux project I'm currently working on - it helps to illustrate a
solution to a problem, but I'm careful not to use the same code in the
linux project - if you're interested in what it is, have a look on google
for "Scribus")
TTFN
Paul
Ralph Corderoy
> > The upshot is the value of the operating system is zero (financially
> > at least)
>
> Balls.
I agree.
> If the GPL really does have this effect, of infecting everything it
> comes into contact with, I can well understand Microsoft's attitude to
> it.
It does. That's why people refer to it as `viral'. But it isn't all
bad. It has reasons for this behaviour that can be beneficial.
> My major concern with all this is that there is a RISC OS programmer
> involved in two stages. First, in inserting the code covered by the
> GPL into RISC OS 5. Second, in leaking the matter to whoever.
Are you suggesting here they are the same person? Only we know that
Justin Fletcher was the person who has made public his GPL infringement
detection.
> The number of RISC OS programmers on this planet with the ability to
> do the stuff needed to make RO5 is not large. Or so we keep being
> told. In that case, who is responsible for this? Making up names, say
> Fred did the dirty. Did he then report the fact to whatever GPL person
> himself? Or did he tell Joe in the pub?
Is `Joe' Justin Fletcher? Doesn't matter. There's no need for Justin
to have been `tipped off' by anyone. Simple curiosity would have made
him initially look.
> And, I would have thought, if Fred was contracted by Castle to do a
> specific job, he is in for a very heavy breach of contract suit from
> Castle.
*If* Castle sub-contracted the work out, and had a written contract that
said the `work' must be that of the sub-contractors alone and that the
sub-contractor should be able to transfer all copyright to Castle, and
do so, then Castle would have a claim. Although IANAL. That's why I
mentioned in another post that the subby might have professional
indemnity insurance that *might* cover this. But it's still Castle that
have to answer to the GPL infringement as they shipped the binaries.
Ralph Corderoy
> > Not to mention issuing threats and encouraging guerilla warfare.
> > ;-(
>
> Slashdot in a nutshell.
Don't read Slashdot without filtering for just +5 comments first. Then
it gets decent enough to skim.
Ralph Corderoy
> This is the main problem though, Castle can't even though the GPL
> licence supercedes any licence they had from Pace.
What does it mean for a licence between A and B to supercede a licence
between A and C?
Paul F. Johnson
By the process of poking various fingers onto keys Ralph Corderoy
generated this:
> Hi Paul,
>
>> This is the main problem though, Castle can't even though the GPL
>> licence supercedes any licence they had from Pace.
>
> What does it mean for a licence between A and B to supercede a licence
> between A and C?
That the newer licence takes priority over the old licence.
TTFN
Paul
Paul Stewart
"Paul F. Johnson" <paulf....@ukonline.co.uk> wrote:
I'm sure PACE would have a differing view to that.
Okay, say the in theory Castle are held to the GNU license and are told
to disclose the Source code to RO5, which no doubt would be in breach of
their License with PACE, PACE would then withdraw their license from
Castle, leaving them without any access to RO5 source code, they would
then be unable to disclose it.
In the end it must come down to who owns the product in the first place,
which is PACE.
--
Paul Stewart
RISC OS Select 4.33
Member of Hemel Hempstead RISC OS User Group
http://www.hhrug.org.uk
RISC OS 5, now available with IYONIX.
Ralph Corderoy
> > > This is the main problem though, Castle can't even though the GPL
> > > licence supercedes any licence they had from Pace.
> >
> > What does it mean for a licence between A and B to supercede a
> > licence between A and C?
>
> That the newer licence takes priority over the old licence.
But that only applies when a licence between A and B is superceded by a
licence between A and B. When you've three parties, what then?
C's licence with A can't be superceded just because A gets into bed with
B later.
Paul F. Johnson
By the process of poking various fingers onto keys Ralph Corderoy
generated this:
> C's licence with A can't be superceded just because A gets into bed with B
> later.
No, then you have a problem. Irrespective if A uses a product from B which is in
direct contravention with the licence from C, then they are bound by the
licence of B over C - even if in this case it makes no sense whatsoever!
TTFN
Paul
Ralph Corderoy
> > C's licence with A can't be superceded just because A gets into bed
> > with B later.
>
> No, then you have a problem. Irrespective if A uses a product from B
> which is in direct contravention with the licence from C, then they
> are bound by the licence of B over C - even if in this case it makes
> no sense whatsoever!
Sorry Paul, I don't understand that. Going back to what you originally
said before I confused matters with A, B, and C:
This is the main problem though, Castle can't even though the GPL
licence supercedes any licence they had from Pace.
Castle agree a licence with Pace. They then implicitly agreed to the
GPL by using the Linux code. I think that means they've agreed to both
licences, even though that means they can't help but be in violation of
one of them due to their contradictory terms. But you're saying that
Castle can tear up their Pace agreement because the GPL supercedes it.
And that's where I fail to understand your reasoning. Might you expand?
Paul Stewart
ra...@inputplus.co.uk (Ralph Corderoy) wrote:
The PACE license cannot be superceded by GPL as GPL does not have any
licensing control over RISC OS, as it's a PACE product.
Only PACE or whoever the ligitiment owener of RISC OS can supercede any
licensing agreements already in place.
--
Paul Stewart
RISC OS Select 4.33
Member of Hemel Hempstead RISC OS User Group
http://www.hhrug.org.uk
Be Bold. Dare To Be Different. Use RISC OS.
Simon Challands
Paul Stewart <pa...@pstewart.freeserve.co.uk> wrote:
> In message <pan.2003.02.09....@ukonline.co.uk>
> "Paul F. Johnson" <paulf....@ukonline.co.uk> wrote:
> >
> > That the newer licence takes priority over the old licence.
> I'm sure PACE would have a differing view to that.
>
> Okay, say the in theory Castle are held to the GNU license and are told
> to disclose the Source code to RO5, which no doubt would be in breach of
> their License with PACE, PACE would then withdraw their license from
> Castle, leaving them without any access to RO5 source code, they would
> then be unable to disclose it.
That seems far more likely. If there's GPL code in RO5 and it is impossible
for Castle to satisfy both licenses (as seems to be the case) then there
is no legal way out of it. They would have to withdraw everything that
relates to one license and possibly pay damages for breaking it in the
first place. The easier one to withdraw from is the GPL, so, as I've said
in another thread on the same topic, I would think it most likely that
RO5 would be withdrawn, any penalties paid, and eventually re-released
using entirely clean code.
> In the end it must come down to who owns the product in the first place,
> which is PACE.
Right, and I would be very surprised if Pace was forced to lose control
of their property due to the actions of a third party licensee.
--
Simon Challands, creator of
The Acorn Elite Pages: http://elite.acornarcade.com/
Three Dimensional Encounters: http://www.3dfrontier.fsnet.co.uk/
Annraoi
> Hi Annraoi,
>
Hi Ralph !
>
> Can you tell us if you've a technical background, and if so what it is,
I work for a software company (programming, database support). No
granted I don't spend my time disassembling other peoples OS'es to see
if they contain GPL code (mind you that would be in violation of the
RISC OS license anyway wouldn't it ?).
> when suggesting that without the RO5 source you can't see how they can
> prove beyond reasonable doubt that the GPL'd source was taken? Only
> from my background, which does cover grovelling through compiler output
> on various hardware/OS platforms, I think it's easily possible.
> Especially when the copyright infringer has done such a poor job.
I think you mean "alledged" copyright infringer don't you ?
Any analysis without the source for both RISC OS 5 PCI subsystem and
the Linux kernel, will surely only throw up a result which results in
"probabilities" not certainties.
If Castle or Pace (or the easter bunny) has used GPL code they should
come clean, appologies, and indicate that they remove the GPL code at
the earliest oppertunity. As the purchasers of equipment were not
aware of the (alleged) GPL violation they should be temporarily
excepted from legal redress under the condition that they upgrade the
RISC OS 5 system with a version CLEAR of GPL code at the earliest
oppertunity.
There's always a chance the Linux "lunatic fringe" may choose to go
for blood and allow no quarter. If that the case it may require a
"fire with fire" response. A RISC OS desktop look alike is supplied
with some Linux distros, additionally one would have to look carefully
at products like ArmLinux to see that they did not reverse engineer
any code from RISC OS to get the system up and running (such reverse
engineering would run foul of DMCA in the states, and may be a
copyright infringment elsewhere (but again I am not a Lawyer)).
If you look at Slashdot you can see that they really want a case to
test the GPL and the extent of (any) damage done (how many Iyonixs are
out there to date anyway ?) is likely to very minor - while (from
their [Linux nutters] viewpoint) the benefits of a validatory case
regarding the GPL might be too mouthwatering a prospect to pass up.
I am not attempting to minimise the seriousness of the situation, the
use of GPL code is WRONG (if that is what's occurred). The solution is
to develope a non-GPL PCI support code system that can use the
existing ROS calls forthwidth.
By the way does ANYONE know if the PCI code is in a relocatable
module, if that is the case then GPL that module and make the source
available (that should satisfy the Linux heads - especially if a
suitable grovelling appology is forthcoming). By the way a lot of
stuff is on the ROS ROM's that are NOT the OS (for example !Draw,
!Paint, !Edit, the Font system, the printer manager etc., etc.,) these
wouldn't be included in a GPL release of RO5 surely.
Regards
Annraoi
Stephen Crocker
Simon Challands <please...@hotmail.com> wrote:
> I smell a rat in any case - the date for the first version of that
> analysis was 25th Nov, which seems very soon after the launch of the
> Iyonix. What made people start examing the OS code in that sort of detail
> so soon?
Actually, that's _before_ the release of Iyonix. Iyonix was released at the
ARM club show on 30th November.
--
x^ ( ) _________ // Email: mailto:cr...@crok.demon.co.uk
< U O |_|_|_|_|_| O || WWW: http://www.crok.demon.co.uk
\, |/|\ _________ [ ]
. |/^\ . 2 . /__\
... Bored at 3:00 a.m.? PSSSTTT - got a modem?
Paul Stewart
a...@globalcafe.ie (Annraoi) wrote:
SNIP
So in otherwards, Castle, probably PACE, and the GPL group could be in
protracted litigation for years as one sues the other over copyright
infringes. Sounds like they could be opening up a whole can of worms.
Michael Gilbert
<URL:mailto:paulf....@ukonline.co.uk> wrote:
> Hiya,
>
> By the process of poking various fingers onto keys Michael Gilbert
> generated this:
> > If the GPL really does have this effect, of infecting everything it comes
> > into contact with, I can well understand Microsoft's attitude to it.
>
> Yup. Couldn't agree more. Who'd want to see Windows working properly due
> to having a kernel which doesn't screw up every hour or so ;-p
That isn't the point. Most authors of anything want to be able to make a
living out of it. If your income depends on something you have created,
why should you lose the right to that income if someone else happens to
connect your work to something else?
>
> > This business reinforces my growing belief that the programming community
> > is infested with idle gits who know that their customers ain't gonna be
> > able to check their work, so foist piles of broken and festering crap on
> > the rest of us.
>
> Oi. That's incredibly unfair. Unless something is a port, just about
> everything for RISC OS is written cleanly. Referring to sources from
> someone else but not using them is common right across the programming
> community (I've been reading some of my RiscStation source code to help me
> out on a Linux project I'm currently working on - it helps to illustrate a
> solution to a problem, but I'm careful not to use the same code in the
> linux project - if you're interested in what it is, have a look on google
> for "Scribus")
>
What's incredibly unfair, Paul, is that you snipped the end of my
posting without saying so, and in so doing changed the meaing of the
paragraph in question. I'll just restore it, shall I:
> Please note that I really, really
> don't mean all programmers are like this. It's probably the tender
> mentality, where "best value" means "lowest invoice" rather than
> anything longer term. Doing it cheap gets the job, and stuff the
> consequences.
>
> So, do we have names for the prime suspects in this case? Do any of them
> have the cojones to stand up and be counted?
>
And the "just about everything for RISC OS is written cleanly" line is
the nub of it. We have here a case where something is not written
cleanly.
Michael Gilbert
<URL:mailto:ra...@inputplus.co.uk> wrote:
> Hi Michael,
>
> > > The upshot is the value of the operating system is zero (financially
> > > at least)
> >
> > Balls.
>
> I agree.
>
> > If the GPL really does have this effect, of infecting everything it
> > comes into contact with, I can well understand Microsoft's attitude to
> > it.
>
> It does. That's why people refer to it as `viral'. But it isn't all
> bad. It has reasons for this behaviour that can be beneficial.
>
> > My major concern with all this is that there is a RISC OS programmer
> > involved in two stages. First, in inserting the code covered by the
> > GPL into RISC OS 5. Second, in leaking the matter to whoever.
>
> Are you suggesting here they are the same person? Only we know that
> Justin Fletcher was the person who has made public his GPL infringement
> detection.
I'm not suggesting anything. Gerph posted something on Drobe, which is
an analysis of the matter. As far as I'm aware there's no indication
that he discovered the problem in the first place.
>
> > The number of RISC OS programmers on this planet with the ability to
> > do the stuff needed to make RO5 is not large. Or so we keep being
> > told. In that case, who is responsible for this? Making up names, say
> > Fred did the dirty. Did he then report the fact to whatever GPL person
> > himself? Or did he tell Joe in the pub?
>
> Is `Joe' Justin Fletcher? Doesn't matter. There's no need for Justin
> to have been `tipped off' by anyone. Simple curiosity would have made
> him initially look.
As I said, "making up names". I could have put <madeupname1> and
<madeupname2>, but was being lazy.
>
> > And, I would have thought, if Fred was contracted by Castle to do a
> > specific job, he is in for a very heavy breach of contract suit from
> > Castle.
>
> *If* Castle sub-contracted the work out, and had a written contract that
> said the `work' must be that of the sub-contractors alone and that the
> sub-contractor should be able to transfer all copyright to Castle, and
> do so, then Castle would have a claim. Although IANAL. That's why I
> mentioned in another post that the subby might have professional
> indemnity insurance that *might* cover this. But it's still Castle that
> have to answer to the GPL infringement as they shipped the binaries.
>
I suppose Caste will stand in the same relation to the
contractor/employee as a building contractor to the subby who used
below-spec components to build a wall. The lawyers make the dosh.
Again, though, the arsehole who thought it was a good idea to do this is
the person to blame, if anyone. I avoid all iterations of the current
"blame culture", but this stands out a mile. Whether it was a direct
employee of Castle, or a subby, or whoever, someone has passed off
something as their own work in the full knowledge that they haven't
actually done it. In publishing, of course, both author and publisher
are liable.
David Boddie
> If the GPL really does have this effect, of infecting everything it
> comes into contact with, I can well understand Microsoft's attitude to
> it.
It just means that, if you are going to release software to the (paying)
public, you need to check the licensing terms for any code you want to
use. Just because the source is there for you to read, doesn't mean that
it's "unfair" if you don't agree with the terms of the license.
After all, you wouldn't steal commercial code and include it in your
own product, would you? ;-)
David
--
dav...@mcs.st-and.ac.uk is not my real address.
Michael Gilbert
<URL:mailto:dav...@mcs.st-and.ac.uk> wrote:
> Michael Gilbert <mgil...@eclipse.co.uk> wrote in message news:<ant0820053139GWx@riscp
> c.local>...
>
> > If the GPL really does have this effect, of infecting everything it
> > comes into contact with, I can well understand Microsoft's attitude to
> > it.
>
> It just means that, if you are going to release software to the (paying)
> public, you need to check the licensing terms for any code you want to
> use. Just because the source is there for you to read, doesn't mean that
> it's "unfair" if you don't agree with the terms of the license.
>
> After all, you wouldn't steal commercial code and include it in your
> own product, would you? ;-)
If I ever happened to write any, no. But that's not the point. Even if I
did, the owner of that bit of code would only have a claim over it, and
not over the rest of the program or whatever that included it.
The whole thing is a can of worms.
druck
> By the way does ANYONE know if the PCI code is in a relocatable
> module, if that is the case then GPL that module and make the source
> available (that should satisfy the Linux heads - especially if a
> suitable grovelling appology is forthcoming). By the way a lot of
> stuff is on the ROS ROM's that are NOT the OS (for example !Draw,
> !Paint, !Edit, the Font system, the printer manager etc., etc.,) these
> wouldn't be included in a GPL release of RO5 surely.
The PCI code is question is in the Iyonix HAL section of the RISC OS 5 ROM,
so is the responsibility of Castle rather than Pace. I have to concur that
core PCI routines do bear an incontrovertible similarity to binaries produced
from various Linux kernel sources released under the GPL.
---druck
--
The ARM Club * http://www.armclub.org.uk/
Michael J. Schülke
> In article <4de76ee2.03020...@posting.google.com>, David Boddie
> <URL:mailto:dav...@mcs.st-and.ac.uk> wrote:
>
> > After all, you wouldn't steal commercial code and include it in your
> > own product, would you? ;-)
>
> If I ever happened to write any, no. But that's not the point. Even if I
> did, the owner of that bit of code would only have a claim over it, and
> not over the rest of the program or whatever that included it.
It's simply a different way of paying for the license to use someone
else's code: With commercial code, you hand over a money; with GPLed
code, you pay by agreeing to GPL your code as well.
In either case, it's your choice. You don't have to use that code. But
if you do, you have to pay the price.
> The whole thing is a can of worms.
That's the point. GPLed software creates more GPLed software.
Regards,
Michael
Ian K (N)
In article <da993ac2...@druck.freeuk.net>,
Although this is all still technically hearsay noone I would expect to
know what there taking about and normally support Castle seems to be
disputing the claims.
This is indeed a dark day for RISC OS while I don't think there is any
likelihood that RISC OS 5 would be released as GPL, there's no way Pace
would allow it. It would render RISC OS a virtually worthless product.
The best case scenario if these claims are found to be true is Castle
claiming that this isn't a part of the OS and it stands on its own, by
supplying the code as a module or something similar.
The worst case is although I think this is unlikely that Castle will be
getting a big law suite. And Pace taking a very dim view of all the fuss,
taking away there licence consequently making the Iyonix as dead as Pheobe
and quite possibly Castle at the same time.
What I expect will happen is Castle will suspend sales for a few months
while they remove the offending code and pay a fine then the whole matter
will be dropped.
I hope this was just a silly mistake rather than deliberate as this could
do Castle's reputation serious damage that they may never recover from.
Regards
Ian K
* "Eere I got an electric twit for christmas!" The Goon Show
David Boddie
> In article <4de76ee2.03020...@posting.google.com>, David Boddie
> <URL:mailto:dav...@mcs.st-and.ac.uk> wrote:
> > After all, you wouldn't steal commercial code and include it in your
> > own product, would you? ;-)
>
> If I ever happened to write any, no. But that's not the point. Even if I
> did, the owner of that bit of code would only have a claim over it, and
> not over the rest of the program or whatever that included it.
As has been mentioned elsewhere, I think that releasing the source code of
the entire work is just one of the conditions you must fulfil to be given
the priviledge of copying the code by the copright holder(s). If you don't
comply then the right to copy is simply not extended to you, and copyright
law kicks in. Or something like that; I'm too lazy to read all the GPL
stuff again...
I don't think that releasing the source code of the entire work is being
given in the license as a demand or punishment for license breakers.
So that puts paid to the "open source RISC OS" project on Sourceforge. ;-)
> The whole thing is a can of worms.
Which need not be opened, if careful.
Thomas Leonard
> In message <pan.2003.02.08....@ukonline.co.uk>>> Well, if it is the case that Castle *have* used GPL code as part of the
>> kernel or any part of their system, then the version of RISC OS used in
>> the Iyonix also has to be made open source
>
> Hmm...
>
> Just wondering about this sort of thing... what about those binary kernel
> modules, such as the NVidia display drivers? How are they licensed? Do
> they not include parts of the Linux kernel?
AIUI, the Linux developers make a special exception for binary drivers
for a subset of the kernel's interface. If a module declares itself as
being GPL then it gets the full interface, otherwise it only gets access
to the approved functions.
I'm not sure that binary drivers would be legal using the GPL alone.
--
Thomas Leonard http://rox.sourceforge.net
tal...@ecs.soton.ac.uk tal...@users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
Richard Walker
druck <ne...@druck.freeuk.com> wrote:
> I have to concur that core PCI routines do bear an incontrovertible
> similarity to binaries produced from various Linux kernel sources released
> under the GPL.
Blimey! I was expecting a slightly more sugar-coated comment from you,
Dave! :-)
--
Richard.
"Well, my heart went "boom", when I crossed that room."
Richard Walker
> By the process of poking various fingers onto keys Richard Walker
> generated this:
>
> > Just wondering about this sort of thing... what about those binary
> > kernel modules, such as the NVidia display drivers? How are they
> > licensed? Do they not include parts of the Linux kernel?
>
> The licence for display drivers can be the same as that for RealPlayer - a
> binary only (or library only with associated header file). Some folks
> (like nVidia) are happy for the linux community to know what is going on.
Erm... I know about stuff like RealPlayer - that's obviously not a problem/
I was thinking of kernel modules (drivers) for certain pieces of hardware,
such as video cards. Surely kernel modules are compiled with the aid of
kernel header files? Now, if the whole kernel is GPL-ed, are binary modules
not affected?
In all honesty, I don't believe that a binary-only Linux kernel module is a
violation of the GPL, but I just want to understand *why*.
> > Why should anyone outside of Castle be given access to their source code
> > on the basis of an *assumed* GPL violation?
>
> Can you think of a better way to deny an allegation?
No, but I'm no expert.
> If the story is true, Castle have already tried to hide the evidence by
> removing the tags but the code is still in there.
We don't know that for sure. It *could* be a coincidence.
> Given that evidence, would you actually trust Castle to tell the truth?
On balance, yes.
> > > this is a big blow for Castle's credibility,
> >
> > If this is true, I agree. However, they are still a *MILLION* miles
> > ahead of RISCOS Ltd., RiscStation and MicroDigital in that game. If any
> > of those companies are sitting rubbing their hands with glee, then they
> > need not bother.
>
> They are currently.
What? Who? Are you saying that the other manufacturers are enjoying the
situation?! :-)
> However look at it again. Did the GPL code problem come from Pace or
> Castle? Pace is a *big* company and I personally doubt they will now just
> sit there - they will be trying to clean their hands with some meaty
> actions in their defence.
It doesn't matter if it's from Pace or Castle - the company selling the kit
is Castle, so the buck stops with them.
> If one of those actions went against Castle, it is quite likely that the
> Iyonix will be operating system-less.
I suspect that Castle would be quick to offer a GPL-less version of the
code.
> It then doesn't matter how far ahead Castle are past ROS Ltd, RS or MD,
> they will suddenly find themselves back with just the RPC.
Even if that happened, Castle would still:
a) be selling the fastest and most expandable RISC OS machine
b) have a million times the respect that I have for the others
> > > Given the Iyonix board is also a good testbed for Intel developers,
> > > the sales figures will take a beating.
> >
> > What?! I don't think so...
>
> Why?
How on earth is Iyonix a good testbed for Intel developers?!
> The way it works is that if a company has ripped something as well
> respected as the GPL off, why won't they do it again? The trust factor
> will have gone.
So? Do people trust:
a) Castle over the slippage of Oregano 2?
b) CJE over their theft of Aleph One's ARM 3 cache control software?
c) MicroDigital for the 'unfinished' nature of the Mico? (no USB etc.)
d) MicroDigital for the Omega saga?
e) RiscStation for the Evolution and portable myths?
f) XYZ over the alledged supply of systems with stolen software?
...
--
Richard.
"Take these broken wings and learn to fly all your life."
Dickon Hood
: In message <pan.2003.02.08....@ukonline.co.uk>
: "Paul F. Johnson" <paulf....@ukonline.co.uk> wrote:
:> By the process of poking various fingers onto keys Richard Walker
:> generated this:
:> > Just wondering about this sort of thing... what about those binary
:> > kernel modules, such as the NVidia display drivers? How are they
:> > licensed? Do they not include parts of the Linux kernel?
:>
:> The licence for display drivers can be the same as that for RealPlayer - a
:> binary only (or library only with associated header file). Some folks
:> (like nVidia) are happy for the linux community to know what is going on.
: Erm... I know about stuff like RealPlayer - that's obviously not a problem/
: I was thinking of kernel modules (drivers) for certain pieces of hardware,
: such as video cards. Surely kernel modules are compiled with the aid of
: kernel header files? Now, if the whole kernel is GPL-ed, are binary modules
: not affected?
: In all honesty, I don't believe that a binary-only Linux kernel module is a
: violation of the GPL, but I just want to understand *why*.
I suspect it depends on how you look at it. The binary-only device
drivers (certainly in nVidia's case) come with a small amount of glue.
Each kernel revision, you have to recompile that glue to match the kernel
symbols and addresses, before you can install the module. nVidia provide
binary RPMs and suchlike for certain distributions, but these will only
work on the stock kernel, and will break if you compile your own.
I don't know of anyone else doing the same thing, but it seems likely
that's the approach to take. Your binary is your own, but you open the
glue. That leaves people free to modify the glue for their own purposes
(eg, if nVidia decide to drop support) whilst allowing them to retain
control of their IPR.
:> > Why should anyone outside of Castle be given access to their source code
:> > on the basis of an *assumed* GPL violation?
:> Can you think of a better way to deny an allegation?
: No, but I'm no expert.
:> If the story is true, Castle have already tried to hide the evidence by
:> removing the tags but the code is still in there.
: We don't know that for sure. It *could* be a coincidence.
And pigs have been spotted dogfighting at 20,000 ft...
To produce code that close to the Linux kernel version without actually
copying and modifying it beggars belief.
:> Given that evidence, would you actually trust Castle to tell the truth?
: On balance, yes.
:> > > this is a big blow for Castle's credibility,
:> > If this is true, I agree. However, they are still a *MILLION* miles
:> > ahead of RISCOS Ltd., RiscStation and MicroDigital in that game. If any
:> > of those companies are sitting rubbing their hands with glee, then they
:> > need not bother.
:>
:> They are currently.
: What? Who? Are you saying that the other manufacturers are enjoying the
: situation?! :-)
Wouldn't you? :-)
:> However look at it again. Did the GPL code problem come from Pace or
:> Castle? Pace is a *big* company and I personally doubt they will now just
:> sit there - they will be trying to clean their hands with some meaty
:> actions in their defence.
: It doesn't matter if it's from Pace or Castle - the company selling the kit
: is Castle, so the buck stops with them.
Correct.
:> If one of those actions went against Castle, it is quite likely that the
:> Iyonix will be operating system-less.
: I suspect that Castle would be quick to offer a GPL-less version of the
: code.
Indeed. And as I've said before, it would make a lot of sense from their
PoV to take the code from NetBSD/arm32 (or possibly one of the other BSD
variants, but that is the closest they're going to get to a RISC OS OS) as
I'm reasonably sure they'll have much the same initialisation code, but
implemented in a slightly different way.
:> It then doesn't matter how far ahead Castle are past ROS Ltd, RS or MD,
:> they will suddenly find themselves back with just the RPC.
: Even if that happened, Castle would still:
: a) be selling the fastest and most expandable RISC OS machine
Albeit one that's $LARGE_N years out of date.
: b) have a million times the respect that I have for the others
:> > > Given the Iyonix board is also a good testbed for Intel developers,
:> > > the sales figures will take a beating.
:> > What?! I don't think so...
:> Why?
: How on earth is Iyonix a good testbed for Intel developers?!
Full OS, etc. I don't buy it either, TBH. They'd be better off with one
of their own development boards and a bootloader for the OS of choice.
Which would almost certainly be linux or WinCE.
:> The way it works is that if a company has ripped something as well
:> respected as the GPL off, why won't they do it again? The trust factor
:> will have gone.
: So? Do people trust:
: a) Castle over the slippage of Oregano 2?
Knowing the company (having worked for them in a former life) that's
almost certainly Oregan's fault.
: b) CJE over their theft of Aleph One's ARM 3 cache control software?
: c) MicroDigital for the 'unfinished' nature of the Mico? (no USB etc.)
: d) MicroDigital for the Omega saga?
Least said about that the better, IMHO. Going to be released next month
again, isn't it? :-)
: e) RiscStation for the Evolution and portable myths?
Politics got in the way of that, or so I'm told.
: f) XYZ over the alledged supply of systems with stolen software?
This is why Open Source is good. You know you're not breaking anyone's
licence agreements when you're using it for your own personal use on your
own personal desktop machine...
: ...
--
Dickon Hood
Due to constant nagging to change it, my .sig is temporarily unavailable.
Normal service will be resumed as soon as possible. We apologise for the
inconvenience in the meantime.
Torben Ægidius Mogensen
> To produce code that close to the Linux kernel version without actually
> copying and modifying it beggars belief.
Or they could both be based on a third common source.
Torben Mogensen
Steffen Huber
The big problem is that you never know for sure if you are not breaking
anyone's licence agreement. The fact that someone gives you a piece
of code with a licence does not mean that he is allowed to do it.
The whole licencing stuff is a nightmare, and open source has not changed
that - you still have to trust people/companies that they are not lying.
Steffen
--
steffe...@gmx.de ste...@huber-net.de
GCC for RISC OS - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/
Ray Dawson
What was that then? Of all the companies in the RISC OS market, CJE have
to be the most trustworthy.
Cheers,
Ray D
--
Ray Dawson
r...@magray.freeserve.co.uk
MagRay - the audio & braille specialists
Richard Walker
Dickon Hood <dicko...@fluff.org> wrote:
> In article <c197b2c24...@proton.acorn>, Richard Walker <runny...@ntlworld.com> wrote:
>
> > I was thinking of kernel modules (drivers) for certain pieces of
> > hardware, such as video cards. Surely kernel modules are compiled with
> > the aid of kernel header files? Now, if the whole kernel is GPL-ed, are
> > binary modules not affected?
>
> I suspect it depends on how you look at it. The binary-only device
> drivers (certainly in nVidia's case) come with a small amount of glue.
> Each kernel revision, you have to recompile that glue to match the kernel
> symbols and addresses, before you can install the module. nVidia provide
> binary RPMs and suchlike for certain distributions, but these will only
> work on the stock kernel, and will break if you compile your own.
>
> I don't know of anyone else doing the same thing, but it seems likely
> that's the approach to take. Your binary is your own, but you open the
> glue. That leaves people free to modify the glue for their own purposes
> (eg, if nVidia decide to drop support) whilst allowing them to retain
> control of their IPR.
Ahh. I see. That makes sense.
I suspect that Castle have not followed this path, though...
> > So? Do people trust:
> >
> > a) Castle over the slippage of Oregano 2?
>
> Knowing the company (having worked for them in a former life) that's
> almost certainly Oregan's fault.
;-)
Yes, and I'd agree. However, as far as Oregano customers are concerned,
that's irrelevant - the product is sold by Castle, so it's their
responsibility.
> > f) XYZ over the alledged supply of systems with stolen software?
>
> This is why Open Source is good. You know you're not breaking anyone's
> licence agreements when you're using it for your own personal use on your
> own personal desktop machine...
Yeah, but the Open Source desktop software is, well, not up to scratch. :-)
--
Richard.
"Man, you should have seen them kicking Edgar Alan Poe."
Richard Walker
Ray Dawson <R...@magray.freeserve.co.uk> wrote:
> In article <c197b2c24...@proton.acorn>,
> Richard Walker <runny...@ntlworld.com> wrote:
> >
> > b) CJE over their theft of Aleph One's ARM 3 cache control software?
>
> What was that then? Of all the companies in the RISC OS market, CJE have
> to be the most trustworthy.
Years ago, many developers produced ARM 3 upgrades. It was a simple-ish PCB
and chip, with some cache control software (a required extra for RISC OS 2,
but included by default in RISC OS 3).
Anyway, CJE decided to sell their ARM 3 upgrade with Aleph One's software
(and no doubt under-cut Aleph One's ARM 3 upgrade price). Blatant theft.
--
Richard.
"Will you still need me, will you still feed me. When I'm sixty-four."
dgs
Ray Dawson <R...@magray.freeserve.co.uk> wrote:
> In article <c197b2c24...@proton.acorn>,
> Richard Walker <runny...@ntlworld.com> wrote:
> >
> > b) CJE over their theft of Aleph One's ARM 3 cache control software?
>
> What was that then? Of all the companies in the RISC OS market, CJE have
> to be the most trustworthy.
Even being very trustworthy doesn't necessarily prevent one from making
mistakes now and then.
(Not that I know to what Richard refers - all my ARM3 machines were that
way when I bought them, so I had no interest in the area of ARM3 upgrades).
--
d...@argonet.co.uk | RISC OS user in London? http://www.jellybaby.net/rougol/
"It's just that RISC OS 3.7 is 20% more inefficient in desktop
operation than RISC OS 4, not that RISC OS 4 is any faster."
- James MacDonald
Bruce Goatly
Richard Walker <runny...@ntlworld.com> wrote:
> Years ago, many developers produced ARM 3 upgrades. It was a simple-ish PCB
> and chip, with some cache control software (a required extra for RISC OS 2,
> but included by default in RISC OS 3).
>
> Anyway, CJE decided to sell their ARM 3 upgrade with Aleph One's software
> (and no doubt under-cut Aleph One's ARM 3 upgrade price). Blatant theft.
So, was the company ever prosecuted for theft? That must have been in a news
programme I missed.
Or it didn't happen.
--
bruce <*> (Delete "bit-bucket." to avoid the spam trap.)
The children are our future. And that is why, ultimately, we're screwed
unless we do something about it. -- Scott Adams, "The Dilbert Future"
Ralph Corderoy
> Anyway, CJE decided to sell their ARM 3 upgrade with Aleph One's
> software (and no doubt under-cut Aleph One's ARM 3 upgrade price).
> Blatant theft.
You seem to know so much about it, you could have almost been there!
Anyway, IIRC CJE stated they believed the software that came with it was
generally free for use, hadn't intentionally breached AO's copyright,
replaced the software with their own, and made an agreed payment to
charity.
Bear in mind the ARM 3 support module does very little and its interface
was defined by Acorn, i.e. all upgrade manufacturers had to copy Acorn's
API to avoid creating compatibility problems.
You might want to reconsider that `Blatant theft' line.
Jess
<snip>
> By the way does ANYONE know if the PCI code is in a relocatable
> module, if that is the case then GPL that module and make the source
It must be a module. If it weren't it would not be a HAL but a
monolithic design. Also their statement could not possibly be true
otherwise.
> available (that should satisfy the Linux heads - especially if a
> suitable grovelling appology is forthcoming). By the way a lot of
Is there a time limit within which the code must be supplied?
Who must it be supplied to?
> stuff is on the ROS ROM's that are NOT the OS (for example !Draw,
> !Paint, !Edit, the Font system, the printer manager etc., etc.,) these
> wouldn't be included in a GPL release of RO5 surely.
--
Jess icq: 91353267 msn: phant...@hotmail.com http://www.kentwebnet.com
Hotmail is my spam trap - don't use for email
mailto:nos...@itworkshop.uklinux.net
RISC OS 4.33 SA233T 144+2M Castle Storm DMA + 17GB 586-133 Smoothwall
Michael Gilbert
<URL:mailto:runny...@ntlworld.com> wrote:
> In message <4bc318...@raydawson.com>
> Ray Dawson <R...@magray.freeserve.co.uk> wrote:
>
> > In article <c197b2c24...@proton.acorn>,
> > Richard Walker <runny...@ntlworld.com> wrote:
> > >
> > > b) CJE over their theft of Aleph One's ARM 3 cache control software?
> >
> > What was that then? Of all the companies in the RISC OS market, CJE have
> > to be the most trustworthy.
>
> Years ago, many developers produced ARM 3 upgrades. It was a simple-ish PCB
> and chip, with some cache control software (a required extra for RISC OS 2,
> but included by default in RISC OS 3).
>
> Anyway, CJE decided to sell their ARM 3 upgrade with Aleph One's software
> (and no doubt under-cut Aleph One's ARM 3 upgrade price). Blatant theft.
>
Daniel Ellis
<URL:mailto:phant...@hotmail.com> wrote:
> In message <dab3e751.03020...@posting.google.com>
> a...@globalcafe.ie (Annraoi) wrote:
>
> <snip>
>
> > By the way does ANYONE know if the PCI code is in a relocatable
> > module, if that is the case then GPL that module and make the source
>
> It must be a module. If it weren't it would not be a HAL but a
> monolithic design. Also their statement could not possibly be true
> otherwise.
You appear to be ignorant of what the term 'relocatable module' means in RISC
OS, or alternatively, unaware of how a lump of code can be made use of with
RISC OS without being in a relocatable module.
The whole point of the HAL is to provide functionality independantly of RISC
OS, and hence independantly of the concept of RISC OS relocatable modules.
--
Dan Ellis
mailto:d...@pod51.demon.co.uk
Chris Evans
<URL:mailto:d...@argonet.co.uk> wrote:
> In article <4bc318...@raydawson.com>,
> Ray Dawson <R...@magray.freeserve.co.uk> wrote:
>
> > In article <c197b2c24...@proton.acorn>,
> > Richard Walker <runny...@ntlworld.com> wrote:
> > >
> > > b) CJE over their theft of Aleph One's ARM 3 cache control software?
> >
> > What was that then? Of all the companies in the RISC OS market, CJE have
> > to be the most trustworthy.
>
> Even being very trustworthy doesn't necessarily prevent one from making
> mistakes now and then.
Yes we messed up:-( a few early copies of the ARM3 control software we
supplied were Aleph One's, later copies were from another source that we had
commissioned. We made a payment to AlephOne to cover royalties on the copies
of thier software we had supplied.
Chris Evans
--
CJE Micro's / NCS / Fourth Dimension 'RISC OS Specialists'
Telephone: (01903) 523222 Fax: (01903) 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN, UK.
Richard Walker
ra...@inputplus.co.uk (Ralph Corderoy) wrote:
> You might want to reconsider that `Blatant theft' line.
I suppose it was a little harsh. I didn't mean it to sound anti-CJE or
anything. Please read 'theft', rather than 'blatant theft'.
I certainly don't have an axe to grind with CJE, and they've only done good
things for me!
--
Richard.
"Got to be good looking, cos it's so hard to please."
Richard Walker
Bruce Goatly <ha...@bit-bucket.capersoft.com> wrote:
> In message <e22336c34...@proton.acorn>
> Richard Walker <runny...@ntlworld.com> wrote:
>
> > Anyway, CJE decided to sell their ARM 3 upgrade with Aleph One's
> > software (and no doubt under-cut Aleph One's ARM 3 upgrade price).
> > Blatant theft.
>
> So, was the company ever prosecuted for theft? That must have been in a
> news programme I missed.
>
> Or it didn't happen.
Chris Evans has just posted on the subject. I distinctly remember reading
about it in Acorn User - and possibly also Archive.
--
Richard.
"Cellophane flowers of yellow and green. Towering over your head."
Jess
Daniel Ellis <d...@pod51.demon.co.uk> wrote:
> In article <345b48c...@invalid.itworkshop.invalid.co.uk.invalid>, Jess
> <URL:mailto:phant...@hotmail.com> wrote:
> > In message <dab3e751.03020...@posting.google.com>
> > a...@globalcafe.ie (Annraoi) wrote:
> >
> > <snip>
> >
> > > By the way does ANYONE know if the PCI code is in a relocatable
> > > module, if that is the case then GPL that module and make the source
> >
> > It must be a module. If it weren't it would not be a HAL but a
> > monolithic design. Also their statement could not possibly be true
> > otherwise.
>
> You appear to be ignorant of what the term 'relocatable module' means in RISC
> OS, or alternatively, unaware of how a lump of code can be made use of with
> RISC OS without being in a relocatable module.
That's why I was careful to use the generic term module (ie not in RO
programming terms) and not "relocatable module"
> The whole point of the HAL is to provide functionality independantly of RISC
> OS, and hence independantly of the concept of RISC OS relocatable modules.
--
Daniel Ellis
<URL:mailto:phant...@hotmail.com> wrote:
> In message <ant120041965#m...@pod51.demon.co.uk>
> Daniel Ellis <d...@pod51.demon.co.uk> wrote:
>
> > In article <345b48c...@invalid.itworkshop.invalid.co.uk.invalid>, Jess
> > <URL:mailto:phant...@hotmail.com> wrote:
> > > In message <dab3e751.03020...@posting.google.com>
> > > a...@globalcafe.ie (Annraoi) wrote:
> > >
> > > <snip>
> > >
> > > > By the way does ANYONE know if the PCI code is in a relocatable
> > > > module, if that is the case then GPL that module and make the source
> > >
> > > It must be a module. If it weren't it would not be a HAL but a
> > > monolithic design. Also their statement could not possibly be true
> > > otherwise.
> >
> > You appear to be ignorant of what the term 'relocatable module' means in
> > RISC OS, or alternatively, unaware of how a lump of code can be made use
> > of with RISC OS without being in a relocatable module.
>
> That's why I was careful to use the generic term module (ie not in RO
> programming terms) and not "relocatable module"
Sorry, I misread your comment in that case.
Here we are talking about a dichotomy between OS and HAL, there are only 2
things in consideration, and they are of a quite different nature, so I think
it's confusing to use the term modular. Although of course you could change
either one of them without altering the other in any way.
Steven Pampling
<runny...@ntlworld.com> wrote:
> In message <2c9b.3e49...@blake.inputplus.co.uk>
> ra...@inputplus.co.uk (Ralph Corderoy) wrote:
> > You might want to reconsider that `Blatant theft' line.
> I suppose it was a little harsh. I didn't mean it to sound anti-CJE or
> anything. Please read 'theft', rather than 'blatant theft'.
> I certainly don't have an axe to grind with CJE, and they've only done
> good things for me!
Best to totally remove the theft bit then, or do you not know that theft is
"removal with the intent to permanently deprive"
The *intent* is the critical item. Both parties seem to have agreed on that
occasion that there was no such intent.
Tim Tyler
: "Paul F. Johnson" <paulf....@ukonline.co.uk> wrote:
:> > > Given the Iyonix board is also a good testbed for Intel developers,
:> > > the sales figures will take a beating.
:> >
:> > What?! I don't think so...
:>
:> Why?
: How on earth is Iyonix a good testbed for Intel developers?!
Well, it has an Intel chip on it, that's a start - and it is one of the
few such devices with a fair size screen and keyboard ;-)
--
__________
|im |yler http://timtyler.org/ t...@tt1.org
Stuart Halliday
Tim Tyler <t...@tt1.org> wrote:
> Richard Walker <runny...@ntlworld.com> wrote:
> : "Paul F. Johnson" <paulf....@ukonline.co.uk> wrote:
>
> :> > > Given the Iyonix board is also a good testbed for Intel developers,
> :> > > the sales figures will take a beating.
> :> >
> :> > What?! I don't think so...
> :>
> :> Why?
>
> : How on earth is Iyonix a good testbed for Intel developers?!
>
> Well, it has an Intel chip on it, that's a start - and it is one of the
> few such devices with a fair size screen and keyboard ;-)
Intel developers in my work just use a cross compiler so they use a standard
x86 PC 2.5GHz, in my case, running Linux Redhat 8.0 and gcc and it outputs
code for pretty much any chip on the market. Why would they run it on a slow
600Mhz Xscale?
At my work we've got a Xscale Intel development board with a LCD screen,
Compact flash and IDE interface device. It allows hardware to be easily
added to it too. No idea how much we paid for it though.
At my work we have developed a number of hardware devices using the ARM,
StrongARM and Xscale.
In fact if anyone wants a ARM based piece of kit developed then ask us.
http://www.ecs-tech.com/
[Followups redirected to the correct newsgroup.]
--
Stuart Halliday
The Acorn Cybervillage
http://acorn.cybervillage.co.uk/
Support us - http://www.cafepress.com/AcornCV/
Remove 'takeoutthisbit' to reply to my mail.
Annraoi
>
<snip>
> So in otherwards, Castle, probably PACE, and the GPL group could be in
> protracted litigation for years as one sues the other over copyright
> infringes. Sounds like they could be opening up a whole can of worms.
>
Perhaps not !
People sometimes can be more sensible, I just spotted an article on
http://www.businessweek.com/technology/cnet/stories/984769.htm
In the article you'll see that Intel originally had their ACPI source
under a commercial (closed source) CA license and also under GPL with
Red Hat. But near the end the following quote may give cause for hope:
"Intel proposed the BSD license change in December on the Linux kernel
mailing list. Torvalds was among those who chimed in about the move,
saying that dual licenses cover several other important sections of
Linux kernel software."
This shows people CAN be reasonable. More significantly the statement
that "dual licenses cover several other important sections of Linux
kernel software" may mean that perhaps that's the case with the RO5
HAL. If not it may indicate that the GPL community are likely to show
more leeway than might hetherto been expected (perhaps even more so
than some naysayers you see here from time to time). So long as people
don't trample over their rights they're prepared to be reasonable and
Castle's offering of providing the HAL source may well be sufficient.
Kind Regards
Annraoi
Colin Granville
This is not a shift in linux policy - the GPL has nothing to do with
linux anyway. The GPL does not require you to release code under a
GPL it requires you to release it under a GPL compatible licence.
The modified BSD licence is only one such licence which allows you
to comply with the GPL so there is nothing wrong with linux having
BSD code and never has been. But you can take the BSD code out of
Linux and use that under the BSD licence.
--
Colin
Ralph Corderoy
GPL discussions again! You can see why lawyers are never out of work
:-)
> This is not a shift in linux policy - the GPL has nothing to do with
> linux anyway. The GPL does not require you to release code under a GPL
> it requires you to release it under a GPL compatible licence.
Oh, if you're right then I'm wrong. I thought that the GPL required the
GPL be used. A GPL compatible license allows the source it covers to be
merged with the GPL'd work and the deriative work to still be licenced
under the GPL.
http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
http://www.gnu.org/licenses/gpl-faq.html#TOCWhatDoesCompatMean
> The modified BSD licence is only one such licence which allows you to
> comply with the GPL so there is nothing wrong with linux having BSD
> code and never has been.
True.
> But you can take the BSD code out of Linux and use that under the BSD
> licence.
Hmm. Possibly not if you got it under just the GPL given the above. Of
course, if you could go back to the source before it was merged into the
GPL'd work, or if the copyright holders dual-licence it, then you can.
What do you think?
Colin Granville
>Hi Colin,
>
>GPL discussions again! You can see why lawyers are never out of work
>:-)
Definitely and I hope you realize the sacrifice I'm making replying
- my spam count has gone up since I joined in this discussion :-)
>
>> This is not a shift in linux policy - the GPL has nothing to do with
>> linux anyway. The GPL does not require you to release code under a GPL
>> it requires you to release it under a GPL compatible licence.
>
>Oh, if you're right then I'm wrong. I thought that the GPL required the
>GPL be used. A GPL compatible license allows the source it covers to be
>merged with the GPL'd work and the deriative work to still be licenced
>under the GPL.
>
> http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
> http://www.gnu.org/licenses/gpl-faq.html#TOCWhatDoesCompatMean
These tell you that, given that 2 licences are not mutually
exclusive, that combining programA (which is my copyright and
licence) and programB (your copyright and licence) must be
releasable under the terms of the most restrictive licence - in
this case the GPL. This doesn't make code from A GPL it means that
its licence doesn't break the GPL.
I can add code to a GPL'd program under a BSD licence and it stays
BSD. Zlib for example can be added to a GPL program under the Zlib
licence it doesn't change its licence (you can't change its
licence). You don't have to look around for a GPL'd version of Zlib
to use it in a GPL'd program - in fact it's unlikely you'll find
one because there is no need for them to release it under GPL. If I
want to Zlib I can remove it from any GPL'd program.
>
>> The modified BSD licence is only one such licence which allows you to
>> comply with the GPL so there is nothing wrong with linux having BSD
>> code and never has been.
>
>True.
>
>> But you can take the BSD code out of Linux and use that under the BSD
>> licence.
>
>Hmm. Possibly not if you got it under just the GPL given the above. Of
>course, if you could go back to the source before it was merged into the
>GPL'd work, or if the copyright holders dual-licence it, then you can.
>
>What do you think?
As I said above there is no need for a dual licence. In effect the
term 'program' is a notional concept. What is actually copyrighted
is individual source code files.
--
Colin
Ralph Corderoy
> These tell you that, given that 2 licences are not mutually exclusive,
> that combining programA (which is my copyright and licence) and
> programB (your copyright and licence) must be releasable under the
> terms of the most restrictive licence - in this case the GPL. This
> doesn't make code from A GPL it means that its licence doesn't break
> the GPL.
>
> I can add code to a GPL'd program under a BSD licence and it stays
> BSD. Zlib for example can be added to a GPL program under the Zlib
> licence it doesn't change its licence (you can't change its licence).
> You don't have to look around for a GPL'd version of Zlib to use it in
> a GPL'd program - in fact it's unlikely you'll find one because there
> is no need for them to release it under GPL. If I want to Zlib I can
> remove it from any GPL'd program.
OK, Zlib is released under a GPL-compatible licence, agreed. And I
understand I can't change Zlib's licence. But it would seem from
http://www.gnu.org/licenses/gpl-faq.html#TOCWhatDoesCompatMean
What does it mean to say a license is "compatible with the GPL".
It means that the other license and the GNU GPL are compatible; you
can combine code released under the other license with code released
under the GNU GPL in one larger program.
We're OK up to here.
The GPL permits such a combination provided it
Presumably, `it' means the combination of myprog and Zlib.
is released under the GNU GPL.
So the deriative work, not Zlib alone, is released under the GPL.
The other license is compatible with the GPL if it permits this too.
And the Zlib licence allows this.
I understand your point of view but if you're right then the FAQ answer
seems misleading.
Colin Granville
>Hi Colin,
>
>> These tell you that, given that 2 licences are not mutually exclusive,
>> that combining programA (which is my copyright and licence) and
>> programB (your copyright and licence) must be releasable under the
>> terms of the most restrictive licence - in this case the GPL. This
>> doesn't make code from A GPL it means that its licence doesn't break
>> the GPL.
>>
>> I can add code to a GPL'd program under a BSD licence and it stays
>> BSD. Zlib for example can be added to a GPL program under the Zlib
>> licence it doesn't change its licence (you can't change its licence).
>> You don't have to look around for a GPL'd version of Zlib to use it in
>> a GPL'd program - in fact it's unlikely you'll find one because there
>> is no need for them to release it under GPL. If I want to Zlib I can
>> remove it from any GPL'd program.
>
>OK, Zlib is released under a GPL-compatible licence, agreed. And I
>understand I can't change Zlib's licence. But it would seem from
>
> http://www.gnu.org/licenses/gpl-faq.html#TOCWhatDoesCompatMean
>
> What does it mean to say a license is "compatible with the GPL".
>
> It means that the other license and the GNU GPL are compatible; you
> can combine code released under the other license with code released
> under the GNU GPL in one larger program.
>
>We're OK up to here.
yup.
>
> The GPL permits such a combination provided it
>
>Presumably, `it' means the combination of myprog and Zlib.
>
> is released under the GNU GPL.
>
>So the deriative work, not Zlib alone, is released under the GPL.
It may be more accurate to say that the derivative work is
releasable. It fulfills the licences of all parts. This is a
requirement of all licences not just the GPL. If all the works had
to have a GPL licence then it couldn't use any non GPL
libraries/code as you can't change their licence.
You can't even say the binary is GPL only as certain parts of the
binary is produced by source with a different licence.
>
> The other license is compatible with the GPL if it permits this too.
>
>And the Zlib licence allows this.
yes
>
>I understand your point of view but if you're right then the FAQ answer
>seems misleading.
I think that it is just oversimplifies a complex situation.
--
Colin
Geoff Lavallin
I have being trying to follow the licence arguments.
I have written this analogy and I think it makes sense.
You arrive on a tennis court will your whites and own rackets.
There is a sign on a board which says' All Tennis Balls are Free'
You take a tennis ball and play your game.At the end of the game the
players
decide to take the tennis balls because they are free and better
quality than your own.
The balls are put with your kit and you leave the court.
As you leave the court the sign still says 'All Tennis Balls Are
Free'.
The tennis balls in your kit are still free but your kit is your
own.You can sell or give away your tennis kit but the balls are still
free.
If you leave your tennis kit and it is stolen then you can rightfully
claim on your insurance for a new kit but you cannot claim for the
tennis balls because they were free and not your property to start
with.The thief only stole your kit but did not steal the tennis balls
because they are FREE to EVERYONE.
Logically if only the tennis balls were taken then they were not
stolen because
They Were Free !!
For kit read GPL application licence.
For tennis balls read BSD licence.
How to improve free tennis balls.
You want to improve the performance of the tennis balls but you cannot
use equipment in your kit as it belongs to a different licence to the
free tennis balls.The only way to improve them is to take them back to
the original tennis court and use the equipment provided.
You can still sell your kit but the status of the balls cannot
change.The now
super balls are still free.If no charge is made for the balls you can
freely
include them with your kit when you sell it but the balls are still
FREE to
EVERYONE.
Ian Molton
glav...@freeuk.com (Geoff Lavallin) wrote:
>
> You want to improve the performance of the tennis balls but you cannot
> use equipment in your kit as it belongs to a different licence to the
> free tennis balls.
You were fine up to there.
the BSD license makes NO requirement to contribute back.
Geoff Lavallin
Ian Molton <sp...@f2s.com> wrote:
If the free tennis balls are to remain free should they be identified
in your kit which are your tennis balls and which balls remain free.
Not to identify the free balls appears to encourage entrapment if some
person picked up your balls by accident instead of the free balls.
--
Wey Hey were like monkeys...I can use tools too!