Re: [DotGNU]Just Some Comments/Analysis

[Barry Fitzgerald]

Seth Johnson wrote:
> 
> I just want to put out a few comments, none of which I think
> people are likely to disagree with.  These are just general
> comments which I think are important to bear in mind:
> 
> A major reason why so many big players are jumping on the
> web services protocols bandwagon is because of what they
> hope to establish along with the application server and XML
> interoperability framework that they set up.  Notably, the
> marginalizing of the copyleft front ("Who needs code anyway,
> from an application server?"), and the instituting of
> content control.  With the protocol suite they've worked up,
> they will be able to build in content control while
> characterizing anything else as either non-interoperable or
> renegade, or both.
> 
> Much of the hype and cool-beans stuff associated with the
> web services protocols is just "the stuff that's possible
> now that we agree on how to describe data so we can
> interoperate."
> 
> But what they are adding to the interoperability issue, is
> the prospect of establishing the idea that there will be
> "services formats" that work with specific services -- which
> can then be treated as proprietary, much like the current
> idea that there are certain "document formats" that work
> with specific traditional applications.  Developers who
> disagree with this idea may find themselves having to
> contend with the potential of being characterized at minimum
> as non-standard -- or at worst as renegades.
> 
> This is the part of these standards that needs to be
> targetted.  The recently unveiled patents associated with
> the protocols only emphasize that this is the game that's
> up.
> 
> Just a few points to keep in mind, that in my opinion should
> clarify the nature of the fight.  Feel free to correct or
> improve on them.
> 


I agree completely, Seth.  I think that you've hit the nail on the head
and that's part of the reason why we decided very early on that taking a
stance in DotGNU required taking a very political stance, not just a
technical one.  Saying "Wow, this .Net stuff is cool!" is all well and
good, and some of the technology behind it (CLI/CLR explicitly) is very
useful external to the hailstorm strategy.  However, the hailstorm
strategy is the scary part.  

However, I see ways that we can use webservices in Free Software.  There
could be completely remote running services.  This is fine as long as
the code is available and as long as the program itself is under a
copyleft license.  Meaning the ability to get the code is implicit.  The
only concern is whether running a service remotely constitutes
distribution.  Therein lies the rub.  However, I think we can combat
that with crafted licenses and through shear doggedness in leveraging
the pragmatic aspects of Free Software where we can.  This first model,
I think, will not be very successful amongst the standard Free Software
community - which likes access and the ability to have a binary on their
system.

The other method of operating a webservice is in having a client
component update key components of itself via remote files.  This could
be virtually any application that has content or components that change
often enough to justify some form of pervasive update service.  It could
be a game (which would be a wonderful application for it) or some other
aspect.

However, you've gotten me thinking.  If webservices aren't distributed,
per-se, that is they are run remotely - then how is the GNU GPL
enforced?  The GNU GPL depends on distribution - so if somebody modifies
a DotGNU based webservice and makes it run remotely never distributing
it, how are they obligated to release the code?

Wasn't there recently a GPL modification that dealt with online content
that was recently endorsed by the FSF?  Perhaps we should adopt that
license for things like the auth webservice programs?

        -Barry


p.s. I view the current definition of webservices (the industry
definition) as too standard encumbered.  XML is nice, but it's just a
standard format.  There's no reason that a webservice couldn't be done
in RDF encapsulation or (ACK!) even a bash shell script encasement.  I
just want to make the point that many of the current webservice
definitions rely on solving problems experienced primarily by
proprietary vendors that don't want to share their formats.  This is
important to keep in mind lest we get caught in the trap of letting the
method and model get defined for us by our enemies.  I have often held
that, where applicable, we should and must wander off the beaten path
simply because they are not wearing the same shoes that we are, so our
path must ultimately be different in many ways, if that analogy makes
any sense to people.