Sad Tale of Greed and Aspiration.

"Max Kellermann" wrote in message
...
Surfer! wrote:
but for most of us being able to make changes is a pipe-dream and
touting it as a benefit of Open Source is missing the point.

Missing what point?

I described how non-developers can benefit from Open Source software.
You may or may not perceive and appreciate this advantage, but you're
not an elected spokesperson for the group "most of us".

So in your view "most of us" would be capable of amending the code and
achieving something that works?

I doubt it very much. There seem to be a lot of IT people in gliding, but I
still suspect that most of us are not capable of changing something like XC
Soar.



What most of us want is good software with a responsive development
team, regardless of what the licensing is.

Everybody has his/her own reasons for choosing a software platform.
Some people care about licensing, some don't.

If you really don't care about licensing, then why do you participate
in this thread, which is all about licensing?

It was the statement that being allowed to change the source is a benefit.
It's only a benefit is one is able to do so, for anyone who can't it's not a
benefit - they are just as tied into the development team as they would be
with a commercial product.

On Aug 30, 9:16*am, "Surfer!" wrote:
"Max Kellermann" wrote in message

...

Surfer! wrote:
but for most of us being able to make changes is a pipe-dream and
touting it as a benefit of Open Source is missing the point.

Missing what point?

I described how non-developers can benefit from Open Source software.
You may or may not perceive and appreciate this advantage, but you're
not an elected spokesperson for the group "most of us".

So in your view "most of us" would be capable of amending the code and
achieving something that works?

I doubt it very much. *There seem to be a lot of IT people in gliding, but I
still suspect that most of us are not capable of changing something like XC
Soar.



What most of us want is good software with a responsive development
team, regardless of what the licensing is.

Everybody has his/her own reasons for choosing a software platform.
Some people care about licensing, some don't.

If you really don't care about licensing, then why do you participate
in this thread, which is all about licensing?

It was the statement that being allowed to change the source is a benefit..
It's only a benefit is one is able to do so, for anyone who can't it's not a
benefit - they are just as tied into the development team as they would be
with a commercial product.

I think you are underestimating the power of the "free" software in
the sense of the GPL. You and others can benefit from the freedom of
any developer to modify, fix bugs etc in the GPL'ed code. Does it
guarantee that will happen? Of course not. But an individual developer
not releasing code to others guarantees others will never be able to
improve the code or fix problems.

But so what anyhow. Here is a straightforward case of somebody
modified GPL code and distributing binaries and so violating the GPL
license by not releasing code changes as required. If somebody does
not want to operate under those license restrictions, then don't use
other developers GPL protected code in you work. This stuff might seem
unusual to non-developers or those outside the software industry but
all this should be very straightforward to a software developer
working in open-source. The cure can be as easy as just dropping a
snapshot/tarball of the current code online, an operation fairly
trivial to add to an automated software build/makefile.


Darryl

Surfer! wrote:
I described how non-developers can benefit from Open Source software.
You may or may not perceive and appreciate this advantage, but you're
not an elected spokesperson for the group "most of us".

So in your view "most of us" would be capable of amending the code and
achieving something that works?

No, that is not what I described.

It was the statement that being allowed to change the source is a benefit.
It's only a benefit is one is able to do so, for anyone who can't it's not a
benefit

Trying to name a simple example: you want a new feature in either
XCSoar or LK8000. What are your chances to get it implemented?

- LK8000 (or any other non-free and proprietary software): submit a
feature request to Paolo Ventafridda. Either will he implement it,
or not. If not, you're completely out of luck. One single person
decides.

- XCSoar: submit a feature request to us (half a dozen of developers,
not just one person). If nobody in our team is willing or able to
implement it, go and find *any* person capable of writing code,
motivate him to implement your request. You could even collect
money to pay a coder to do it. If it turns out that the XCSoar
derivative created by that coder is better and the new feature
really is useful, more and more users will choose it instead of our
version, putting pressure on us to merge it. Either way, all users
get a superior product.

You may not be able to edit the source code, true so far. Your
advantages in using free software are indirect, and may be hard for
non-developers to understand. It works, it's a proven concept. Many
projects have been forked and superseded this way, which would not
have been possible without a free software license.

Max

On Mon, 30 Aug 2010 13:45:08 +0000, Max Kellermann wrote:


No, that won't work. That's a technical tweak which only obfuscates the
legal problem without solving it. The resulting product is still a
"derived work" of the GPL code in question.

You've lost me here.

I was thinking of the situation where you design a function that calls a
few of the library APIs and returns a result that depends on some
combination of the values returned by library calls. Often there is a
design choice of whether you extend the library or build the function
into the application. If the library in question is part of a proprietary
OS there's no choice: you *have* to build it into the application, but if
the library is GPLed then you have the choice of adding the function to
the library, just as you might for a privately developed library, or of
including it in the application.

I see this as adding another variable, this time constrained by the type
of licensing you're planning to use for the application, to the design
decision of where to put the function rather than a technical dodge to
get round GPL conditions.

A similar consideration arises if you want to, say, call parts of a C
library from a Java program: are you really telling me that the JNI
interface code used to implement the calls *must* be GPLed despite the
fact that it doesn't affect the library binary or source in any way?

I don't see anything in GPLv3 that even hints that such code must be
GPLed. What did I miss?


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On Aug 30, 10:50*am, Martin Gregorie
wrote:
On Mon, 30 Aug 2010 13:45:08 +0000, Max Kellermann wrote:

No, that won't work. *That's a technical tweak which only obfuscates the
legal problem without solving it. *The resulting product is still a
"derived work" of the GPL code in question.

You've lost me here.

I was thinking of the situation where you design a function that calls a
few of the library APIs and returns a result that depends on some
combination of the values returned by library calls. Often there is a
design choice of whether you extend the library or build the function
into the application. If the library in question is part of a proprietary
OS there's no choice: you *have* to build it into the application, but if
the library is GPLed then you have the choice of adding the function to
the library, just as you might for a privately developed library, or of
including it in the application.

I see this as adding another variable, this time constrained by the type
of licensing you're planning to use for the application, to the design
decision of where to put the function rather than a technical dodge to
get round GPL conditions.

A similar consideration arises if you want to, say, call parts of a C
library from a Java program: are you really telling me that the JNI
interface code used to implement the calls *must* be GPLed despite the
fact that it doesn't affect the library binary or source in any way? *

I don't see anything in GPLv3 that even hints that such code must be
GPLed. What did I miss?

--
martin@ * | Martin Gregorie
gregorie. | Essex, UK
org * * * |

As a frequent explorer or rat holes I can identify this is going down
one :-) This type of stuff is pretty well discussed on the GPL FAQ,
search for keywords "link" or "library" and "system library" and also
search for "LGPL" (Lesser General Public License).

The details of JNI and Java and GPL, or Java licensing in general and
various Sun open licenses and GPL compatibility could fill a book. (I
negotiated a complex commercial J2SE license with Sun and still mostly
have my sanity, well the medication helps a lot). You can probalby
find a lot of that by Googling around. None of that is relevant to
this situation.

Darryl

On Mon, 30 Aug 2010 11:11:29 -0700, Darryl Ramm wrote:

As a frequent explorer or rat holes I can identify this is going down
one :-) This type of stuff is pretty well discussed on the GPL FAQ,
search for keywords "link" or "library" and "system library" and also
search for "LGPL" (Lesser General Public License).

Thanks for those pointers. Thats clarified things somewhat.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Seems that about the only thing folks can agree on about the GPL is
that Paolo should release the source code.

So....Paolo, could you do that so everyone can feel
satisfied that the spirit of the licensing is being honored?

That way we can enjoy both products for each of their benefits and
benefit from the sharing.

Like many others I like both and use which ever one is the most stable
and functional in flight for my particular missions.


Ray

jb92563 wrote:
Hey Folks, Paolo is going to formally Post the Source for LK8000 so we
can all
relax..
He asked me to post the following message on his behalf.

I share Darryl's concerns, this sounds just like he's going to do only
half of what he is obliged to do according to the license.

The source code of *all* binaries he ever published must be offered to
anybody who downloaded the binaries (including me!). I will drop my
threat to bring this case to court only if there is full GPL
compliance.

That said, it is definitely a first step in the right direction, so
let's see what really happens. I will send a formal request for the
source code of all binaries I have downloaded (again).

What can I say about Max Kellerman's concerns about LK8000? Not
much. I am astonished by the amount of foolishness he just wrote.

Apparently, nothing has changed. Paolo Ventafridda can't stop
spilling personal insults against me, in a purely technical/legal
discussion.

Max

On Aug 31, 11:01*pm, Max Kellermann wrote:
jb92563 wrote:
Hey Folks, Paolo is going to formally Post the Source for LK8000 so we
can all
relax..
He asked me to post the following message on his behalf.

I share Darryl's concerns, this sounds just like he's going to do only
half of what he is obliged to do according to the license.

The source code of *all* binaries he ever published must be offered to
anybody who downloaded the binaries (including me!). *I will drop my
threat to bring this case to court only if there is full GPL
compliance.

That said, it is definitely a first step in the right direction, so
let's see what really happens. *I will send a formal request for the
source code of all binaries I have downloaded (again).

What can I say about Max Kellerman's concerns about LK8000? Not
much. *I am astonished by the amount of foolishness he just wrote.

Apparently, nothing has changed. *Paolo Ventafridda can't stop
spilling personal insults against me, in a purely technical/legal
discussion.

Max


Max,

I appreciate that you would ideally like to see full compliance
by getting the source for every prototype/release preceeding this one
but it seems you two are playing tit for tat now, due to your
differences of
opinion or what ever.

For the benefit of the community of users who like both products,
can't we use this
latest source code release as a starting point for compliance
going forward?

Is having the previous releases available to you really going to
have any positive impact on LK8000 or XCSoar?

At this point Paolo is about ready to throw in the towel on LK8000
and we end users will ultimately loose out.

You programmers are doing this work because you enjoy it and derive
the satisfaction
from what you have created, so I see all the posturing, scuffles etc
and
threats of litigation as enough to terminate one or both projects as
you
are likely not enjoying the current situation.

Lets use today as the point for a new beginning on both tracks and
leave the
past behind.

Please.

Ray

jb92563 wrote:
Is having the previous releases available to you really going to
have any positive impact on LK8000 or XCSoar?

Yes. When trying to comprehend a foreign code base, it is very useful
to have as many intermediate steps as possible. A smaller change is
easier to review and to understand. At the XCSoar project, we create
a new patch for every little change, along with documentation, look
he

http://git.snow-crash.org/?p=xcsoar.git;a=log

("commitdiff" shows the code changes of a patch)

This patch resolution is not achievable in retrospect, but having more
intermediate versions helps a lot.

At this point Paolo is about ready to throw in the towel on LK8000
and we end users will ultimately loose out.

Remember that I warned of exactly this outcome and the loss for all
users yesterday?

Do you understand now why users benefit from LK8000 becoming open
source again?

Lets use today as the point for a new beginning on both tracks and
leave the past behind.

It has been a while since I was last insulted by Paolo Ventafridda,
but apart from that, I don't see anything special in "today". Let's
talk again when we have the sources.

Max