SamyGO: replacing television firmware

Posted Nov 14, 2009 16:21 UTC (Sat) by kju (guest, #61936)
Parent article: SamyGO: replacing television firmware

The article claims that samsung has released the RFS sources. Where? On the mentioned page there is no download and the downloadable kernel source for this device contains binary object files for RFS only. Samsung also states that RFS is not GPL but proprietary. So porting RFS to a newer kernel will apparently be a big problem.

SamyGO: replacing television firmware

Posted Nov 14, 2009 16:42 UTC (Sat) by jake (editor, #205) [Link] (24 responses)

> On the mentioned page there is no download and the downloadable kernel
> source for this device contains binary object files for RFS only.

You are indeed correct, and I will try to reflect that in the article. I saw rfs directories and such included with the source, along with some forum comments, and leapt to a conclusion. Interesting that they would provide object files for a binary-only module, doesn't seem like they would need to do that (assuming that the binary module is not a derivative work, which would, of course, require the source to be released as well).

My apologies, and thanks for pointing it out!

jake

SamyGO: replacing television firmware

Posted Nov 14, 2009 17:15 UTC (Sat) by johill (subscriber, #25196) [Link] (16 responses)

You'd think anything using the VFS is a derived work of it since it cannot have been created for another operating system and "just ported".

SamyGO: replacing television firmware

Posted Nov 14, 2009 21:27 UTC (Sat) by ewan (guest, #5533) [Link]

That's not necessarily true, one of the classic early examples of a kernel module that couldn't possibly be a derived work of the kernel was the Andrew File System that did use pre-existing code ported across.

SamyGO: replacing television firmware

Posted Nov 14, 2009 22:35 UTC (Sat) by giggls (subscriber, #48434) [Link]

Looks like they are providing a thin Layer with GPL-Licence just like the Nvidia folks do:

http://www.samsung.com/global/business/semiconductor/prod...

SamyGO: replacing television firmware

Posted Nov 16, 2009 7:25 UTC (Mon) by butlerm (subscriber, #13312) [Link] (13 responses)

"a derived work of it since it cannot have been created for another
operating system"

This is one of the most ridiculous definitions of "derivative work" ever
conceived. It makes absolutely no sense whatsoever.

Two classic tests for derivative work are "access" and "substantial
similarity". Access is a given here. But why should a filesystem first
developed for Linux necessarily have greater similarity to other operating
system source code than one that was ported from another operating system?

A difference so great that one is a derivative work and the other one
isn't? The end products are nearly equivalent. Both rely on access to the
Linux source code. The order of development or porting is completely
irrelevant - either both (in their final form) are derivative works of
Linux or both aren't.

And the theory that either one is a derivative work is pretty thin in any
case. Is a Windows application a derivative work of Windows because that
is the first platform it was developed for? Because it makes extensive use
of hundreds of Win32 APIs? What about a business management application
that relies on the special features of a certain database? Should it be
developed for some brain dead database first, just so it can avoid the
accusation of being a derived work of the good one?

Is the contagion of being ported to a kernel or operating system so great,
that the taint can never be removed in a version for a different kernel or
operating system. That is what SCO's theory was. Derivative status as a
viral construct.

SamyGO: replacing television firmware

Posted Nov 16, 2009 8:39 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (12 responses)

" This is one of the most ridiculous definitions of "derivative work" ever conceived. It makes absolutely no sense whatsoever."

It's also completely irrelevant; I'm disappointed that johill brought it up.

It actually doesn't matter at all whether the module is a derived work. Let's consider it, for the sake of argument, to be an independent and separate work in itself. And then let's see what the GPL has to say...

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

That's the nVidia situation which giggls mentioned (given the above-stated assumption, for the sake of argument, that it's not a derived work).
But read on...

But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

And that's the Samsung situation. Looks like a clear GPL violation to me.

Even if the module is not a derived work.

SamyGO: replacing television firmware

Posted Nov 16, 2009 21:04 UTC (Mon) by jmm82 (guest, #59425) [Link] (2 responses)

"It's also completely irrelevant; I'm disappointed that johill brought it up."

As long as you are not *surprised* someone brought it up. It is a rare occasion that a product using Linux is discussed on LWN without a sub-thread about the GPL and derived work.

Have there been any concrete court decisions in this field lately? I am tired of hearing peoples unprovable interpretations of a derived work. I would love to know what a derived work really is, but have searched far and wide with no solid answers.

SamyGO: replacing television firmware

Posted Nov 16, 2009 21:47 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (1 responses)

You have missed the point completely.

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:05 UTC (Mon) by jmm82 (guest, #59425) [Link]

Agreed, as soon as I hear the words "derived work" my mind blanks out. I have heard so many different opinions on derived work my head immediately begins to swell up upon hearing those words.

In this case it is irrelevant, your point was taken.

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:05 UTC (Mon) by jake (editor, #205) [Link] (8 responses)

But, isn't "work based on the Program" just another way of saying "derived work"?

I don't think the GPL can affect code that is not derived. That's all that copyright law allows it to do.

Or am I missing something?

jake

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:38 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (7 responses)

You're right; the GPL can't directly affect those other works, which are "independent and separate works in themselves." All it can do is grant or deny you permission to copy, modify and distribute the original GPL'd work.

It can grant you permission with conditions attached. Copyright law does allow that. And unless you abide by those conditions, you don't have permission to distribute the original GPL'd work.

So I can release code under a licence which says "you can only use this if you send me a postcard," or "if you name you first-born son after me," or "if all software you ever write is released under the GPL," or "if I like your face."

It's my prerogative to grant or deny permission to use my own code as I see fit, under copyright law.

And I most certainly can release it under a licence which says that you may only redistribute it if you don't do so in combination with other software which is under a different licence. Copyright law most definitely does allow that, and that's what the GPL does.

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:48 UTC (Mon) by jake (editor, #205) [Link] (6 responses)

> And I most certainly can release it under a licence which says
> that you may only redistribute it if you don't do so in combination
> with other software which is under a different licence. Copyright
> law most definitely does allow that, and that's what the GPL does.

Interesting. If I am understanding you correctly, you are saying that anyone who distributes a Linux kernel with a binary driver (many, if not most, embedded Linux devices out there would qualify) is in violation of the GPL.

Not an interpretation I had heard (or, perhaps more likely, understood) before.

jake

SamyGO: replacing television firmware

Posted Nov 16, 2009 23:09 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (5 responses)

"Interesting. If I am understanding you correctly, you are saying that anyone who distributes a Linux kernel with a binary driver (many, if not most, embedded Linux devices out there would qualify) is in violation of the GPL."

Given the above direct quote from the §2 of the GPL, I find it hard to find an alternative interpretation. Although I understand that some people don't like it, so they'll clutch at straws to find one.

One of the tenuous counter-arguments which is often presented (other than the "copyright law doesn't allow that" fallacy) is the final paragraph of §2, which states that "mere aggregation ... on a volume of a storage or distribution medium" doesn't count.

Some people argue that that "exception" is so wide-ranging that it might as well be rephrased as "Oh, actually just disregard the previous two paragraphs, even where we explicitly spelled out that we meant this to apply even to works which are independent and separate works in themselves; we didn't really mean that."

Some people go so far as to claim that all forms of "aggregation" are permitted by the exception — so since linking to non-GPL'd work is merely a form of aggregation, that's allowed too. Under that interpretation, the GPL would actually become more like the LGPL.

Personally, I feel it's much more likely that that "exception" clause applies to stuff like magazine cover CDs, where mostly unrelated software is just aggregated together for distribution. Or where it happens to sit on the same hard drive or backup tape as if by coincidence.

I definitely don't believe that any sane interpretation of the "mere aggregation" exception can apply to a coherent product where both the GPL'd work and the non-GPL'd work are fundamental and necessary parts without which it could not operate.

But of course nobody is right or wrong until it's been heard in court.

OT - Rant against case law

Posted Nov 17, 2009 12:10 UTC (Tue) by Felix.Braun (guest, #3032) [Link] (4 responses)

But of course nobody is right or wrong until it's been heard in court.

Just for the record, the quoted statement would only be true if courts could never be wrong. That is, if they had an authoritative say on what the law should be.

As a (non common law) lawyer, I take exception at this view. Judges are just opinionated people who have been handed some robes (and in the UK maybe some wigs) by the politicians. They are just as likely to make mistakes as the next guy. They are not inherently more likely to be right than anybody else, even *gasp* non-lawyers. Of course, judges themselves know this, and they therefore appreciate a well reasoned argument, no matter who makes it. Generally speaking, even after having decided a case.

Of course, in practice the legal traditions work out to be remarkably similar. But I really do blame the case law system with it's principle of stare decisis for instilling such an attitude of unreflected acceptance in otherwise critically thinking legal laymen.

SCNR </completly off-topic rant>

OT - Rant against case law

Posted Nov 17, 2009 12:47 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] (3 responses)

I understand your objection; allow me to rephrase that final sentence for you, to properly express the implicit subtext...

But nobody is right or wrong; it's not black and white. It's just a document written in English and there can be many different interpretations of it; ranging from the sane interpretations to the utterly nonsensical ones such as the "counter-arguments" I mentioned above.

There are very few interpretations which actually matter, though. The first one which matters to you might be the opinion of your company lawyer, when you consider shipping a product which violates the GPL by including both a kernel and a binary-only module in the same coherent whole. Or, as the GPL phrases it, in a "derivative or collective work based on" Linux.

If he is doing his job properly, he will prevent you from doing that. On the other hand if he doesn't do his job properly, you may well end up bumping up against an opinion which takes precedence over his — the opinion expressed by the (final appeal) court when you are sued for copyright violation.

That opinion, ultimately, is the only one which really matters. It doesn't make it right, and there's plenty of examples of cases where the courts have got things "wrong" in the eyes of many people. But it is the only interpretation which really matters in the end, in practical terms.

Unless, of course, you think the revolution is going to be triggered by a copyright case... :)

OT - Rant against case law

Posted Nov 17, 2009 14:51 UTC (Tue) by Felix.Braun (guest, #3032) [Link]

Thank you for that. That makes me feel much better :-)

OT - Rant against case law

Posted Nov 18, 2009 4:53 UTC (Wed) by butlerm (subscriber, #13312) [Link] (1 responses)

I think the implication against joint (collective) distribution is entirely
reasonable. My problem is when people say something like "this filesystem
was first developed for Linux", therefore it (in any form) is a derived
work of the Linux kernel, and that derivative status infects it to the
degree that it remains a derivative work even when all the Linux related
code is stripped out.

That was SCO's theory regarding JFS. It was first developed for a
proprietary Unix licensed from source code SCO claimed it had the copyright
to, therefore (so they claimed) any version for any other operating system
was also a derivative work of Unix System V (and they were owed billions in
royalties).

I call that the "derivative work by contagion" theory, and it is one of the
reasons why people shouldn't blindly go around claiming things are
derivative works when there is no rational theory for why that should be
the case. Combination may produce a copyright protected collective work,
but the mere fact of combination certainly does not necessarily infect each
of the original components with derivative status when considered
separately, and more especially when the kernel specific binding code is
removed. That would be like saying if a photo is printed in a magazine,
not only is the photo a derivative work of the magazine, the magazine is a
derivative work of the photo.

OT - Rant against case law

Posted Nov 18, 2009 10:27 UTC (Wed) by anselm (subscriber, #2796) [Link]

The fun thing about IBM's JFS as available in the Linux kernel was that the JFS code IBM contributed to Linux didn't in fact have anything to do with the JFS code in AIX (which SCO claimed was a derived work of Unix).

The Linux JFS code is a port of the reimplementation from scratch of JFS that IBM did for OS/2, so it couldn't have been »infected« with SCO-owned code because it never actually came in contact with any.

RFS = FAT + journal? Robust - sigh...

Posted Nov 15, 2009 15:12 UTC (Sun) by pflugstad (subscriber, #224) [Link] (6 responses)

Samsung's RFS page kills me - they add a journal to FAT, tweak it for flash and call it robust FAT filesystem. Ye gads, FAT itself is about the most trivial file system you can get, and making it robust... there's only so much you can do and still be FAT compatible. And then they go to all the effort to keep it binary only, with the GPL shim layer.

I see companies do this all the time: some engineer adds 1 + 1 and suddenly the company treats it likes it's a prize possession, and then they jump through hoops to keep the fact that they added 1+1 a huge secret. When in reality the engineer probably did it as a quick one-off, with little thought and almost zero experience in what he was doing (state of the art filesystem design - yeah, right). As such, it's probably got a couple dozen stupid bugs and could do for some serious peer review.

Just release the code Samsung - if it's any good, the community will incorporate it and it'll get even better. And if it sucks, the community will probably fix it. And the amount of value you're getting from using Linux vastly outweighs any benefit some competitor of yours might get by seeing this silly journalling FAT filesytem.

Oh, and get this: if you google for "journaling FAT", the first result is a PATENT on such a thing. The idiots at the PTO strike again. And there are dozens of other journaling or robust FAT filesystem results.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 16:56 UTC (Mon) by drag (guest, #31333) [Link] (5 responses)

This is actually pretty normal.

Microsoft themselves have 'Transaction Safe' FAT version they offer for
embedded systems running Windows CE 5.x (and probably others). Since people
expect that it's 'ok' to simply pull the power from handheld devices and
such then it's obvious that FAT itself is not really that suitable.
Customers will have a strong tendency to corrupt things after a while. So
transaction safe FAT is designed to deal with that.

It's simply a FAT file system with two file allocation tables. I guess the
goal is to make file system changes a fully atomic event.

And the Linux FAT driver actually works with it, mostly. You can read from
it quite easily, and write. I don't think it's a good idea to use the file
system back in the embedded system after that.. but it's easily to pull the
information off of one.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 19:38 UTC (Mon) by pflugstad (subscriber, #224) [Link] (2 responses)

I know it's normal. That's my main point: what on earth does Samsung think they are gaining by trying to keep their super-duper RFS secret?

It was also to point out that companies need to start understanding that 99% of the stuff their engineers come up with is totally obvious and has been done before (and is even patented in this case), so that they don't end up wasting vast quantities of everyone's time and money on silly crap like the GPL shim layer. Not that the stuff is useless, but come on, a *television* company doing "state of the art" filesystem work. GET REAL...

Pete

PS: I guess it was the Samsung website for RFS that set me off... gawd what a load of marketing drivel...

RFS = FAT + journal? Robust - sigh...

Posted Nov 28, 2009 20:15 UTC (Sat) by efexis (guest, #26355) [Link] (1 responses)

Wow that's a lot of assumptions there, like that things are *ever* that simple. Okay, sometimes things are that simple, but most of the time, when something's screaming "this is so simple why can't they see it?" at you, that's usually a strong sign that it's not and there are other factors you're not considering. As much as there are GPL constraints pulling in one direction, there's a fair chance that there are several other licenses on what they can do with the code pulling them in other directions. For a start, we know it's a VFAT compatible filesystem, and from what we've seen recently with TomTom, Microsoft's ownership of that IP will stand up in court, which means chances are Samsung (or "Flash Software Group") currently have a licensing agreement with MS to allow them to use the code, and who knows whom else they've licensed code or other IP that covers what else they can do with it. Judging by the fact that there's other open source driver downloads on their website for other parts of the system or other products, I'm definitely inclined to believe that it's simply a case of contending licensing issues...

But really, it's a FAT based filesystem that open implementations can still read/write to should the need be there, who cares? Let 'em have their locked away filesystem add-ons, there's so much better out there and on the way.

As far as patenting goes, that covers implementation, if they do their transactional IO differently then it doesn't come under that patent, and if they don't do it different, then the patent holder is probably just someone else who Samsung have a licensing agreement with adding constraints. It's just business.

RFS = FAT + journal? Robust - sigh...

Posted Dec 2, 2009 7:34 UTC (Wed) by tdwebste (guest, #18154) [Link]

>For a start, we know it's a VFAT compatible filesystem,
>and from what we've seen recently with TomTom, Microsoft's
>ownership of that IP will stand up in court

We do NOT know if VFAT would stand up in court. All we know is TomTom and Microsoft were willing to settle out of court.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 22:06 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

It's simply a FAT file system with two file allocation tables.

Er, didn't the FAT filesystem *always* have two file allocation tables? (Or did FAT32 drop one of them? I had switched to Linux everywhere and stopped paying much attention to such sucky filesystems by then.)

RFS = FAT + journal? Robust - sigh...

Posted Nov 19, 2009 12:58 UTC (Thu) by arnd (subscriber, #8866) [Link]

The point where you get transaction safety with FATfs is when each of the two FAT copies resides on exactly one erase block of the underlying flash, and you do all updates as a copy-on-write operation, like:

1. write modified data blocks and directories in previously unused clusters of the file system, without updating the FAT
2. erase the first copy of the FAT
3. write the modified FAT with the new state to the first copy
4. erase the second copy of the FAT
5. write the modified FAT with the new state to the second copy

Upon mounting, you have to detect which copy to use, normally they are identical, and if they are not you should have an out-of-band checksum in the flash that tells you which copy is garbage (unless you have a fatal hardware problem, one of them is guaranteed to be intact) and you overwrite the broken copy with the good one.

It's an extremely simple operation that works exactly because the FAT design is so trivial that it keeps all block allocation data in one place.
If you file sizes are a large multiple of your cluster size (e.g. when storing audio and video data), it's also highly efficient on flash media.
Considering that FAT was designed for 160kb floppy disks without subdirectories, it works extremely well for todays applications.