>> 1) Distributing binary + a patch without full sorces.

GPL does not forbid that. GPL only says that you have to make the
sources available in a form that they are normally build from.
But you don't have to distribute them together with the binary.
You don't even have to make them public, ither. The only thing you have
to do is to send somebody the source (for free) whoever wants to see them.

So if you have already the sources somewhere (for example at SF) and the
patch *is* the the form of source for this modified binary, then I see
nothing that would contradict the GPL if you put somewhere the "original
source + the patch".

As Dima already said, nowadays there are so many free services. So
having the patch living in a branch of the source code repository is not
a big issue.

I'm anyway against binaries without their respective sources.

>> Or just "courtesy binary" for some archtecture.

If you can build such a binary and the next day you are hit by a bus,
who is going to provide such "courtesy binary" if there are no sources
available?

>> GPL requres to keep sorces for download on the server...

Yes. But FriCAS can be easily build from the repository via "make". So
the only thing is to keep the sources in the repository and tell from
which version the binary was build and how.

>> 2) One may wish to embed encryption key for classical cryptography
>>  inside executable, distribute this executable to others so that 
>> they can send enctypted messages to him.  This is not very secure 
>> but give some protection and may be best thing available if public
>>  key cryptography is not an option.

> this sounds like a spyware application, ghm, ghm, ghm...

I also think that this is a non-issue for FriCAS.

>> However, GPL requires souces (with no obfuscation!), so extracting
>>  encryption key becomes trivial.

That reminds me of "security through obscurity".
http://en.wikipedia.org/wiki/Security_through_obscurity

>> 3) There are GPL incompatible free licences.  Creating and
>> distributing combined programs is reasonable, but forbidden if
>> licences are incompatible

More clearly, distributing combined binary would be forbidden. But I
don't see that as a problem of the GPL.
If I look at the list
https://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
and the respective list of compatible licenses above, I'd even claim
that being incompatible with GPL is rather a non-issue. In particular
for GPL3, they have taken measures to get more licenses compatible with
it. See for example Apache 2.0.

>> I do not know how careful you are.  I believe that normal folks 
>> given clear statement of licence do not scan file looking for 
>> another licence in the middle which gives different terms.

Before I redistribute I'm usually double careful. Of course, I also may
sometimes be wrong. But still I think that if people get something for
free, it's not unreasonable to ask them to at least follow the license
under which they get the stuff.

ad TeX style and GPL ...

> This is not true: this is akin to saying that photos taken by a Canon
> camera carry Canon copyright, or executables build by gcc are under
> GPL.

Dima,
in fact, it's not soooo easy with (La)TeX. It depends on how you see it.
One way is that TeX (the program) is a compiler that translates the
sources (i.e. .tex, .sty, and .bib, ... files -- which can count as the
program sources since TeX is a programming language). Then the .dvi or
.pdf file would be considered as the compiled form of the sources. With
this point of view, Waldek is right. But I don't really think that most
people thing that way. Unfortunately, there is no clear statement from
the FSF about this.

But also this is somehow a non-issue. If my published paper would be GPL
then I have to provide the .tex and .sty files. So what?

Ralf

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to