[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: My Favorite soapbox : XML linkage (was Re: [DotGNU]Jabber-thon)

From: James Michael DuPont
Subject: Re: My Favorite soapbox : XML linkage (was Re: [DotGNU]Jabber-thon)
Date: Tue, 4 Jun 2002 23:27:23 -0700 (PDT)

Please excuse my rantings. But this issue is not
resolved yet.

> One of the most fundamental freedoms in Free
> Software is that we
> don't want to restrict how the software can be used.

Yes, untill we ask that certain modules are only used
by GPLd program.

>  The user
> of the webservice software is whoever operates the
> webservice
> server.  If they so choose, they can make an
> Acceptable Use
> Policy which imposes conditions on what software may
> be used to
> connects to their webservice server.
As far as I know, we dont have any standard way to do
this. Plus if the webservice has source code
available, then the user can create his own and start
it without that useage policy.

> But we can't require them to make such an acceptable
> use
> policy.  Otherwise we wouldn't be giving them Free
> Software.
I am just saying that we need to have something to
that affect available as an option.

> > Please dont be offended, but 
> > I have to say that it is a little strange that
> there
> > are so many commercial jabber implementation and
> very
> > few good GPLed. 
> Why do we need more than one good and
> well-maintained GPL'd
> implementation?
> You can always fork if you want one that is somewhat
> different.
> This in contrast to proprietary, where you're often
> forced to
> re-implement from scratch if you want to change
> something.

I am wrong about the dominance of non-free jabber
implementations. Sorry if i offended.

> > The whole linkage and network usage issue comes
> into
> > play. By using jabber interfaces, Soap and XML,
> there
> > is no protection of the GPL. 
> I disagree.
> Let's say we have a GPL'd software package A and
> company X
> chooses to create a proprietary add-on which makes
> use of
> the functionality provided by package A.  I think it
> doesn't
> really matter how the proprietary program
> communicates with
> package A, whether it is through SysV IPC or SOAP or
> Jabber or
> whatever.
> The main thing is that package A is still free
> software, and
> whoever receives it has all the important freedom
> rights to use
> it in any way, to modify it, to write their own
> add-ons etc.

But the ability to wrap any module in a webservice and
republish its interface over then net gives you no way
to enforce that. 
The user loses the freedom to modifiy the non-free
add-on. The will then have to reimplement the add-on
to make any changes to it. 

The GNU project looses an add-on, becuase the
developers wont publish under GPL, and we just get
lots  of leeches and vampire projects.

> The situation would be different if package A were
> only LGPL'd
> -- then company X could link it together with their
> proprietary
> add-on and distribute it in binary form only. 
> That'd be bad
> because the users wouldn't get the freedom rights.
They could also republish the API as a webservice or a
.IL component and then you have another problem.

Perl has many GPLed modules that are also used under
the PAL. The perl culture is, if you can create an
interface to it via perl, then you can ignore the GPL.
 It seems that noone really takes the Gpl seriouly
there. When you get to the .Net world, this will get
really bad.

> BTW the webservices paradigm brings a much more
> revolutionary 
> change to users of the Microsoft Windows system
> where huge
> monolithic applications are the norm which are
> difficult or
> impossible to use in ways that were not foreseen by
> their
> authors.  Users of Unix-like systems however have
> long been
> accustomed to having the freedom of combining
> various programs
> by means of pipes, shell scripts, etc.

Yes, but only recently have we had easy ways to
transport complex data. RPC and SQL are fine, but with
the new services like soap it will be easier and
easier to create webservices that republish GPLed

> There _is_ an important issue however with
> webservices:  When
> you use a webservice program on a remote machine,
> you really
> want to have a way to get source code and full
> freedom rights
> for that _remote_ webservice program.  There is a
> fortunately a
> solution to this problem, see the FAQ document on
> the DotGNU
> website.  (There is an alternative approach based on
> modifying
> the GPL, see
> which is however IMO not good enough... I believe I
> explained
> the shortcomings of that approach on this list some
> time back.)

The issue is on of using SOAP as a linker.

> > We still need to be rethink the entire licensing
> issue
> These things have been thought through pretty
> carefully right at
> the beginning of the DotGNU project.

We have had this discussion before. The problem is
that we still dont have a resolution. 

Most of the GNU programs are written in C. RMS holds
that we should not allow programs like compilers and
other gnu applications even via a Shared Lib.

We will never be able to safely create programs and
services that use the full power of GPLed software
because we have no way to protect that from abuse.

We will always have to limit what information is
provided because the GPL makes a distinction between
data and code, between packets and linking.

In a HTTP tunnel, there is not distinction between
data and code. It is just transport. 

As soon as you create a transport, you seem to
magically avoid linkage.
This is wrong.
> > for the creation of the GPL "viral" effect on the
> > greater level. 
> Please don't call the GPL "viral".  Proprietary
> software is the
> virus, the GPL is a form of vaccination for your
> code to protect
> it from getting infected with that virus.
Sorry, I wont do that again.
But on that note, the GPL is being infected by
proprietary software already. 
We need to think about handling this next wave of

Best Regards,

James Michael DuPont

Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]