GPL in ROM

aaaaa

aaaaa

Technically nothing would be ‘linked’ to the gpl code

But the licence does not speak of something technical. It just says you cannot use the code from another code. So no linking or no link with a system made to add a bridge to DLL.

But it’s not very pratical

Dlopen is very easy to use :)

but then still not being actually ‘linked’ to the GPL library.

From a technically point of view yes. From a legal (AKA license) point of view, your code is linked to the library, since it uses it.

This gpl thing is so confusing sometime lol

It’s easy. GPL is – as free software – a legal thing, not a code oriented vision. You make confusion with open source, that is a technical thing.

So no matter what you’ll do. GPL advocates will not care of technical tricks, as they don’t have to. They fixed the rule (you use it, you’re in GPL) and a few exceptions (a front end is separate from the tool, etc.). If you manage to set up a new system around existing exceptions, they will simply say that your approach is not part of the existing exceptions (since it’s not).

But the licence does not speak of something technical. It just says you cannot use the code from another code. So no linking or no link with a system made to add a bridge to DLL.

Can’t use the code from another code? That may be unenforceable under the unfair contact terms legislation.

You can use some free software from another free software, but, no, you cannot use GPL code from non GPL code (as an inclusion, statically [same source file] or dynamically [library, bridge to library, whatever]).

For me it’s clear, but it’s a bit difficult to explain in English :)

aaaaa

aaaaa

There is no way to fool the GPL as technical details can change at any time if needed (GPL is not about technique).

aaaaa

But the thing is that at this rate, if you open a gpl exe with the shell, then the shell should be gpl ?

There is not really any “linkage” with the shell and the executable. Consider, for example, SharedCLibrary which a program will call to set up a series of branch points directly into the program. There is a sort of direct link established between the program and the library. However when you execute a program, the command line usually loads it into memory, faffs around to set up memory and stuff (depending on the OS complexity) and then it just hands control to the program. There isn’t any sort of link established between them.

If it use a GPL code in a COM component from VB or javascript then it’s not a link because it’s just a software and not ‘code’ ? :)

Actually, the GPL FAQ “prohibits” supplying closed source libraries with GPL software in a Windows environment. I put “prohibits” in scare quotes because it can be reasonably well argued that those DLLs and OCXs and other such proprietary and non-free components are actually essential for the runtime (VB, for instance) to work at all. The GPL does allow for this, but I think by now we have established that a lot of GPL blurb is political rather than logical.

What’s the different between a software that use another software, and program that call a routine from another program ? it’s exactly semantically identical.

Not really. You can hand off to another piece of software and while it may work in tandem with your software, it is a separate entity. Calling a routine from your program intertwines the two in an inseparable way.

A shell will run the exported ‘main’ function from exe,

A shell will hand over to the executable, and not expect to be returned to until the program has finished running (or in the case of *nix, has been pushed to the background).

than IE should be GPL right now.

IE is old hat now, do keep up! :-)

I mean you consider the way functions like OLEImage works

…RISC OS forum. Mightn’t be too many around here who know (or care) about esoteric Windows stuff.

If they say that a program using GPL code in such a fashion should be gpl, then virtually all software of the planet should be GPL.

I think there are more than a few GPL supporters who would consider that to be a good idea.

It’s just about what is valid in certain case, and not in other case, it just doesn’t look like how a law should be working :) The way this law works and how is applied is just not fair.

It isn’t a law.

Copyright is the law.
GPL is the licence (granting you rights under the law of copyright).
If GNU come and kick your ass for ignoring the GPL, they don’t get you for GPL infringement, they get you for copyright infringement. The difference? You are free to ignore the GPL, but under the assumption that you are also going to ignore the GPL software.
It’s a bit like car parks. If you read the back of the ticket stub, you’ll see that the owner disclaims everything from fire to theft to elephants stamping on your car. You might not like the rules, and if not, you are free to go park somewhere else.

Even technically,

…you will need to seek your own legal advice on the specifics of these examples; however I will mention two points of interest:

1. Technically the GPL infringes upon itself. The Linux kernel is GPL v2, a lot of software that interacts with the kernel is GPL v3. GPL v3 specifically prohibits using GPL v3 with incompatible licences, and GPL v2 is an incompatible licence.
This is overlooked as GPL suing itself would be hysterically funny, but something of the demise of any relevance GPL has in the world.

2. Actual quotes from Linus:

I claim that a “binary linux kernel module” is a derived work of the kernel, and thus has to come with sources.
[…]
You just can’t make a binary module for Linux, and claim that that module isn’t derived from the kernel. Because it generally is – the binary module not only included header files, but more importantly it clearly is not a standalone work any more. So even if you made your own prototypes and tried hard to avoid kernel headers, it would still be connected and dependent on the kernel.
[…]
And I claim that binary-only kernel modules ARE derivative “by default”, by virtue of having no meaning without the kernel.

This is an incredibly scary proposition.

Let’s consider three points:

1. Evidently it is not possible to write a kernel module for Linux using a published API as opposed to actual kernel code. One would have thought that writing to the API ought to suffice, so long as the API matches reality. To give an example here, for years we have written programs for the Wimp by reading the PRMs. It’s really really late in RISC OS’s life that anything source-like has appeared. We used the API.

2. Linus has an interesting definition of “derived work”. One would have thought that a “derived work” would have had to contain, by necessity, substantial enough portions of actual kernel code that one could say it is derived from the kernel as opposed to original code.
Simply making something that interacts with something else is a tenuous and, frankly, stupid reason to slap a “derived from” label on a piece of code.
Yes, it is true that a kernel module for Linux is not a hell of a lot of good without the Linux kernel. AND? A Windows VB6 program ain’t gonna run on RISC OS, and one of our Absolute executables ain’t gonna run on Linux. “Being designed for” does not equal “is derived from”.

3. Saving the best for last: “even if you made your own prototypes and tried hard to avoid kernel headers”. Prototypes and headers are not component parts of a piece of software. They do not turn up in the executable. They are directions to aid the compiler. RMS himself said (circa 2003) that “Someone recently made the claim that including a header file always makes a derivative work. That’s not the FSF’s view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work.”.
Why? Perhaps because of a crucial difference in application. Firstly you are not copying the headers, you are using them. They do not turn up in the finished work, they simply influence how the compiler creates the finished work.
While copyright laws around the world differ slightly, and American law differs a lot from one day to the next, one thing that is fairly consistent is that you cannot copyright “fact”. The kernel header files define “fact” in the point of view of the API, magic values, calling mechanism blah-de-blah of the kernel. Perhaps their arrangement, comments, and other non-factual information within could be copyrightable “artistic expression”, but even so, you are using that, not copying it.

Having said all this, something to remember regarding the definition of “derivative work”:

• Linus = a kernel module written for Linux means it is a derivative work
• GPL zealot = one line of code copied makes a derivative work
• Corporate America = it must be the entire program copied to be considered a derivative work
• Lawyers = who cares, this will buy me a Porsche and my mistresses holidays in the yacht (ps: you’re paying for that too, the yacht, I mean).

Microsoft did steal the whole C/Shared library principle from unix

What? You mean like we did? Dude – it’s an obvious no-brainer. You simply do not need to have the entire runtime kicking around within every single program you have. That might fly in a single-tasking world, but in a multitasking (GUI or console) world, having a shared library makes a LOT of sense. What sort of weirdo in yesterday’s lower memory/spec world would think it a good idea to run eight programs each containing eight copies of the runtime?

and the unix has been -—- by that

Given that the idea of dynamically linking into shared libraries made its debut in Multics in 1964, the *nix people might want to check their facts on that one.

Which could also explain why Microsoft had to steal the ActiveX thing from another company to make the bulk of their system.

You what? [libel much?!?]
They developed ActiveX because OLE was getting clunky and the MFC had a pee-poor implementation of COM. So OLE and COM were merged, the result was rationalised, some of the rubbish was thrown out, and the whole thing rebranded “ActiveX” ‘cos it’s a trendy mid ‘90s style name (remember, we RISC OS people had “Xemplar”; ’cos back then stupid names with X in them were just all kinds of awesome).
It wasn’t stolen, it was evolved from earlier technologies.

[…] but technically my system can already load up .so and .dll, and it will use some high level language pretty early, that will not be C, something probably akin to AS3 or javascript, […]

…and the relevance to RISC OS is?

1. Technically the GPL infringes upon itself. The Linux kernel is GPL v2, a lot of software that interacts with the kernel is GPL v3. GPL v3 specifically prohibits using GPL v3 with incompatible licences, and GPL v2 is an incompatible licence.
This is overlooked as GPL suing itself would be hysterically funny, but something of the demise of any relevance GPL has in the world.

You have to consider that when people are that far up their own nether then visibility is likely to be reduced. Can’t be an offence if you can’t see it. :)

aaaaa