Is there some merit in "Community Source"?
Posted 7 Jun 2000 at 15:51 UTC by cdegroot
At the Jini Community meeting here at JavaOne, last Monday, we were glad
that we lived with the ugly thing called SCSL, remembering the Kerberos
issue and noting that "we" wouldn't be vulnerable to such an
embrace-and-extend action. Shouldn't the Open Source community give the
notion of communities a closer look?
I think the main reason that "Community Source" has such a bad name is
that the pioneer, Sun, wrapped the idea in a very ugly license, the Sun
Community Source License (SCSL). Only people who have gone through law
school are in a position to understand this license, and even from that
corner there seems to be confusion. Luckily, at least for Jini there's a
version 2 in the works that promises to be clearer.
However, apart from the legal wording, I do think that there is some
merit to this idea. It reflects how physical communities work: people
are willing to help other community members, but if community members
disbehave, they can be expelled from the community. Open Source, taken
from this point of view, sort of forces you to work on behalf of anyone
who has access to your work, whatever they may do to it (including
embrace-and-extend by the boys from Redmond).
In a way, community sourcing is much harder because it needs a community
and it needs to empower that community to make decisions about the
common stuff - the community-shared source code. In the Jini community,
this is slowly getting shape in a very bottom-up way (the majority of
the people who are helping out with starting the community are not Sun
employees), and I think it is at the very least an interesting model. It
is also a very necessary model for two reasons: first, we need direct
competitors to cooperate; it would be nice if they open sourced
everything, but in real life they'll only want to give out enough to
make sure that everyone interoperates, while still protecting everyones
intellectual property. Second, Jini needs the sort of protection that
community source gives against e-and-e actions, because Jini is 100%
about interoperability.
Building a community is hard, and costs a lot of energy (something that
Dee Hock, inventor of the term Chaordic Organizations, will tell you
over and over again). It is much harder than going open source. But is
that a reason to dispel this alternative?
I read the SCSL a while back when it was submitted to the OSI (I
forgot under what circumstances, whether by Sun or by a third
party). It is incredibly far from an open source/free software
license. This will be obvious to anyone who reads through it
and compares. Bill Joy was asked about this repeatedly, and basically said, oh, it's not open source, it's community source, it's better than open source. He gave a long interview
defending this position, which made free software people somewhat skeptical. As I recall, Joy very much didn't believe in the "right to fork", where others very much did. Nobody found a way to resolve this.
I was told by someone who'd talked to Sun people in person that the SCSL was aimed "at a different audience" than open source licenses; the licensees were not conceived of as end users, but as businesses with some stake in the future of a particular codebase. So the SCSL is a way for Sun to open up and share development with some partners, but not necessarily with the general public (as the name "community" indicates). Sun was less concerned about the individual developers who might be motivated to contribute to something like Linux.
That license is hard to get past, because it has such an unpleasant and un-free feel to it (coupled with very specific OSD/DFSG violations). But I don't doubt that the "CSL model" might work for what Sun intends it to.
Sun also invented another interesting license model, the Sun Industry Standards License. That
one actually seems like it might be close to open-sourceness, but Sun is definitely not trying to fit cleanly into the existing
free software world.
I'd like to see a new draft of their Industry Standards License.
I don't know whether people will develop under it, of course, but it looked
interesting.
you're conflating 2 issues here to attempt to make it sound like SCSL is
a good thing:
- The right to fork (a.k.a. the right to modify & redistribute)
- The requirement that your modifications also be freely licensed
MIT and BSD grant the first but avoid the the second. GPL requires both.
SCSL gives you neither.
When Sun says "community", they mean "unpaid employees". The fact that
Microsoft did what they're legally entitled to do with MIT code (and
what people have done with X for some time) doesn't make Sun any less a
weasel in this affair.
Both comments give a bit of factoids, say that they're not open source
compatible, and then go over to the order of the day. In case my
original article wasn't clear: yes, I'm fully aware that the Community
model is not OSD compliant and in some places probably has been
deliberately engineered this way.
I'm curious: in what way does work for Jini under the SCSL makes you
unpaid Sun employees? Sun hasn't got a lot of more rights than all the
other community members, and Sun doesn't make money from Jini -
certainly not from the code, and the logo branding license fees are
probably just adequate to finance the first legal battle over it, and
they've probably spent a lot more on organizing meetings and paying
their development team than they'll ever recover directly from logo
license fees. The argument sounds suspiciously like "it's not open
source, therefore it's bad", which is a religious argument I'm not going
to discuss (I once tried to convert a Catholic priest to give up faith
and become an agnostic, we had lots of wine and fun, but no results).
From the Kerberos case, one might say that only the GPL is ok. I guess
RMS has been laughing his head off over this one. However, it is clear
that often other issues mingle in, and I don't think that religiously
sticking with the OSD and turning your back on other models before
assessing the merits and problems of the alternatives in a calm and
rational way is really productive. But maybe I've been overestimating
the ability of Advogato members to conduct rational discussions?
Erm..., posted 8 Jun 2000 at 01:42 UTC by listen »
(Journeyer)
cdegroot:
Just because people have a quick reaction to something doesn't mean that
reaction is wrong. The SCSL is a bad licence. Get over it.
Sun released Java under the SCSL because they wanted to jump on the open
source bandwagon, but did not want to actually free their code. You
might like Java technically, but you can't pretend that its licence is
better for its users than a truly free licence. Stop apologising for Sun
and trying to convince yourself that it is a good thing. If you want to
be part of a truly free Java project, work on Kaffe.
Telling people they are not capable of sensible discussion is one of the
best ways to show people how incapable of sensible discussion you are.
Rather than come up with a sensible argument for the SCSL, you accuse
Free Software advocates of being "religious". Is it now thought of as
inherently bad to stick to your moral principles? Does having a moral
system influenced by the philosophy and writings of others make you
"religious" and incapable of thought? I doubt it.
OK, I did spend a lot of time reading and talking about the SCSL when it first came out. I thought very hard about it and was very thoroughly convinced that it was problematic.
Unfortunately, I haven't thought about it recently, and I don't remember all of the details of why I was uncomfortable with the SCSL. So all I can say off-hand,
without returning to the license text, is that I did think about it and after thinking about it was dissatisfied.
Yes, this is pretty general, and I shouldn't expect it to influence anyone else's opinion of the license. In order to persuade anyone, I probably need to explain what the SCSL's disadvantages are.
Since I don't remember them now, I have to stick to generalities, which aren't persuasive. I regret that. But I did give the SCSL some time and reflection, when I first encountered it.
Of course, there are general arguments for why free software is better than
non-free software. Probably many people are here on Advogato partly because they believe in some of those arguments.
That doesn't mean that existing licenses are perfect and can't be improved on; there's a lot of room for improvement. But Sun has pretty clearly and openly tried to go in a very different direction with the SCSL.
Even if Kerberos was GPL'd MS could STILL embrace and extend it.
The GPL only applies to the code (ie a single implementation) not to the
algorithm. IMHO if the MIT Kerberos code was GPL'd it would have had a
negative impact on its uptake, as it would force companies to
reimplement it, and while that is far from difficult not all of them
have the resources that MS do :)
For MS to reimplement Kerberos from scratch (and lets face it even if
they DID use the MIT source they would have to change a LOT of code) I
don't think it would faze them at all. There is a free reimplementation
of Kerberos called Heimdal too.
The only protection for Kerberos would come from patent protection,
which stinks, but there you go.
Well, I never said it was a good license. Nor did I say I was against
open source or something (actually, I'm a bit against open source - when
you really ask me, I'm pro freeware). That's why I talked about the
concept of community source - the added protection it gives,
the possibility to expel miscreants - without necessarily citing the
SCSL as a prime example of the concept.
I just wanted to point out that the MPL (Mozilla Public License) also offers a true open source license, that allows you to use the source
in commercial projects but that requires you to give back modifications you do. It is kind of a mixture of BSD and GPL.
MPL lets you link in proprietary object files, I think. But it is not
that the GPL is unique in this respect (which it is not) that makes it a
preferable licence, it is the fact that there is a very large body of
code already under the GPL which can be utilised. If you put something
under the GPL, everyone can breath a sigh of relief, except those who
had designs on making it proprietary.
When you license something under the GPL, everyone can breath a sigh
of relief.... except those that might have code released under an
incompatible license, such as the QPL. Linking against GPL'd code from
other licensed code can also be troublesome.
I've worked with a couple of projects in which we could not use
someone else's code because we could not GPL the code with which we were
working. In this case, the GPL actually kept us from freedom to use the
code.
I do see the merits of the GPL, and have GPL'd code myself, but it
does have known problems. I don't really want to get into the whole
ethical debate about this, as the discussion is long and won't reveal
anything that hasn't been posted in IRC or on Slashdot a few thousand
times. Just wanted to give a testimony that people have run into
problems in real life with the GPL.
As for Sun's licensing... it will win or lose based on its own
merits, as it should. I certainly prefer the Community License to a
closed model, as it opens the APIs at a minimum, and allows quicker bug
fixes (both very important to the business customer, and touted success
points of the free software model). Of course I would prefer that they
take it one step further...
My two cents, posted 8 Jun 2000 at 16:18 UTC by raph »
(Master)
I haven't studied the SCSL in detail, so this is not a real criticism,
just my impressions. I'll state at the outset that I don't have a
fundamental philosophical problem with nonfree software, and am
intrigued by hybrids that attempt to combine the better features of both
the free and proprietary models. However, I'm not convinced the SCSL has
much to offer in this regard.
The SCSL is based on the Java license, although more open. The
experience of the Blackdown project should be a strong warning to anyone
contemplating working on a project with a SCSL-like license. Yes, this
was Sun's bad faith rather than particular wording in the license, but
in my opinion the license is just as useful in signalling the intentions
of the person or company releasing the code as it is a legal document.
The fork right really bothers me. What if Sun has yet another strategic
shift and abandons Jini development? Then the lack of fork rights could
really crimp outside development - at the very least, it would seem to
preclude another group taking over change control and release
responsibilities.
Sun could always decide to free the license in this case, but you have
to trust Sun to do this. The beauty of licenses such as the GPL is that
you don't have to trust the person or company that released the
code.
To me, the best advantage of proprietary software is that it provides a
funding source for the development of the software. In free software,
that's often a struggle, with very uneven availability of funds.
I've just spent a day playing with Adobe Illustrator 9 and have been
extremely impressed - a lot of work by smart people went into its
development and it shows. I haven't been able to find any funding for a
free software counterpart. That's the problem I'd like to see
addressed by a hybrid licensing strategy, and SCSL doesn't.
What I see the SCSL doing is giving Sun a strategic partners program
with low barrier to entry. SCSL licensees get many of the same benefits
as a strategic partner, including access to the source and ability to
fix bugs more quickly. The trust issues also resemble a strategic
partnership. This is not in itself a bad thing, I think, but it's
important not to confuse it with the benefits that derive from a true
free software license.
*sigh*, posted 8 Jun 2000 at 16:36 UTC by graydon »
(Master)
But maybe I've been overestimating the ability of
Advogato members to conduct rational discussions?
lets stick to some facts
here. ad hominem is unacceptable argument style.
2.1: you cannot sell SCSL code, nor make any sort of business around it,
nor distribute patches to anyone who does, unless sun signs an agreement
(attachment E) stating so.
2.2b: you make a patch to sun's code, you irrevocably assign
intellectual property rights including the right to sublicense
back to sun.
2.2c: you give sun's code to someone else, they too are obliged
to assign patches not to you, but to sun.
3.1b: you cannot post patches to the public, only people sun has
licensed to see them.
That's what I mean by "unpaid employee". Think jini is still harmless?
It is not just a wire protocol. Unlike nearly every other
communication infrastructure before it, Jini requires that
anyone who
interoperates with a jini service accept JVM bytecode for the
communication stubs. JVM bytecode must comply with sun's
definition of JVM. Thus if you use jini, you are
effectivley forced to use only the JVMs that sun likes. So,
fine, we could just fork jini if sun ever used this as a lever to kill a
competing JVM, right? no: they
released it
under SCSL, making forks impossible. it's a
classic "lock-in" license, only they get the added bonus of free
contributions from net users worldwide.
You seem to want to get away from discussing the SCSL, so perhaps you
wouldn't mind explaining what "expelling miscreants" entails and why
you think it's desirable.
There seem to be 2 parts to this:
1. Who is a miscreant?
Who or what determines what miscreant-ness is? Does some entity
(the "community"?) arbitrarily decide who is? Does breaking certain
rules make one a miscreant?
2. What does 'expelling' mean?
Does it mean the expellee can't use the code? can't look at the code?
can't continue doing whatever they did that caused them to be expelled?
as well as what would appear to be the main question,
0. How is community membership determined and what does it mean?
and, since I seem to be confused,
3. Why are GPL/BSD/other existing licenses not "Community Source"?
I spent may be 5 or 10 minutes thinking about this passage
(out of pure respect to Graydon, see):
[...] Jini requires that
anyone who interoperates with a jini service accept JVM
bytecode for the communication
stubs. JVM bytecode must comply with sun's definition of
JVM. Thus if you use jini, you are
effectivley forced to use only the JVMs that sun
likes.
So, fine, we could just fork jini if sun
ever used this as a lever to kill a competing JVM
[e.g. Kaffe --P3], right?
no: they released it under SCSL,
making forks impossible.
So, "they released it under SCSL", but is it true for the protocol
itself too?
Can somebody reimplement Jini in the way of GNU Classpath and Kaffe?
If yes, then we do not need to "fork" anything.
if only, posted 8 Jun 2000 at 20:04 UTC by graydon »
(Master)
Some answers, posted 8 Jun 2000 at 20:56 UTC by cdegroot »
(Master)
As to the right to fork: it is apparently there under the SCSL.
As to the patents: yup, they did so. I spoke to someone involved with
these patents and he told me he didn't like software patents, but went
ahead because he has never seen Sun abusing them. I think he's right,
and I think in order to do business as a large company in the United
States you need to have a patent portfolio. However, I'm 100% positive
that if you would do reimplement this stuff in a clean-room fashion, Sun
wouldn't come after you (one of the few nice things about patent
protection being that you can be selective about whom to apply it to).
Raph: Who or what determines what miscreant-ness is? Does some
entity (the
"community"?) arbitrarily decide who is? Does breaking
certain rules make one a
miscreant?
Well, the same way it is done in actual physical communities. That's
what I like about this community thing, it models reality much more
closely than open source on a number of issues. Expelling presumably
means revoking the license (this is one of the deliberate deviations
from open source).
Can
somebody reimplement Jini in the way of GNU Classpath and
Kaffe? If yes, then we
do not need to "fork" anything.
Yes, as far as I know this is possible. You'll probably not be able to
brand it as Jini (although if you pass all the tests and do a logo
branding deal with Sun, that would even be possible), but I don't think
there is anything in terms of legalities standing in anyone's way to
take either of the Jini related "official" books (the Jini and the
JavaSpaces specs by Addisson-Wesley) and implement the stuff from
scratch.
The Sun Community Source License can be found
here.
Similarly to Seth, I haven't looked at
this license in some time and I can't remember a lot of the
specific problems I saw with it. The most
obvious difference between this license and free software licenses is
that
you can't deploy the code without paying a
royalty. You can do all of the work on it you want, you can
use it to further your education, but to deploy or sell
it you'll have to pay someone else. Hence the comments about the
license making developers "unpaid employees of Sun."
I don't see any reason to use this license, personally; there are a lot
of other licenses that are much more attractive to me as an end-user.
From what I can see, the concept of "community source licensing" is a PR
rationalization. If there's a community that can eject people under
that license, that community is Sun Microsystems, Inc.
In the free software community, we eject people by not dealing with
them. It's simpler. You make your own decision
about the matter and you can change your mind anytime you want.
Microsoft ended up purchasing another VM so that it didn't have to deal
with Sun's restrictions.
The SCSL did not protect Sun. Standardization
in an open standards group plus GPL licensing would protect more
thoroughly than the SCSL.
Bruce
1. I am slightly offended at the incorrect notion that someone has to go through "law school" to
understand the SCSL (or any legal document, for that matter). The idea that law is strictly for
laywers is part of why our legal system (and our political one, too) is so screwed up. Maybe
the language can be difficult, but it is just language. Consider hard-to-read legal documents to
be no different than hard-to-read computer programs. They are the result of bad lawyers or
intentional obfuscation.
2. Community Source, and even the SCSL, are perfectly fine. There is nothing evil or insidious
about them. Fine, don't call it open source, but don't hate it just because it isn't open source
(unless you just happen to hate everything that isn't open source). You might hate it because it
kinda pretends to be open source but isn't.
But I think the best reason to hate it is because, as Bruce says, it doesn't really do anything
interesting. While I am no fan of copyleft, the GPL would likely do what Sun wants better than
the SCSL would (though the GPL is not exactly appropriate for Sun, either; but that can be dealt
with in other ways).
Anyway, the point is that the SCSL just doesn't seem to accomplish what it is apparently meant
to, and that makes it bad.
The GPL forms a community. If your code uses the GPL, you know that you
can incorporate any other code that uses the GPL. And because the GPL
is sticky modulo fair use, you also know that anyone who uses your
GPL'ed code is going to join the community.
You're right, but I think there are a couple of things in GPL that
something like Sun's community source licensing scheme tries to solve:
- The GPL not quite compatible with Java, IMHO. The license talk about
derived
works is hard to apply to Java, because of the dynamic nature of the
language. In fact, I think only the LGPL is sensible in a Java
environment (and there it may give too little protection).
- There's no way to enforce compliance. One of the things the SCSL
attempts to do is to protect people from bad implementations and
incompatible software. The only way to get a commercial redistribution
license, is to brand the stuff - make it pass acceptance tests,
etcetera. The connotation that this goes hand-in-hand with paying money
is wrong (I'm quite sure you can negotiate a royalty-free license with
them, as they did with Blackdown), and even then the connotation with
Sun earning money is wrong (there are large expenses like brand
protection, setting up meetings, etcetera).
- There's no way to punish bad behavior (where I define "bad behavior"
as being "not in line with the community's goals"). The GPL only
concerns itself with the code, but not everything around that. As long
as you share code, you are allowed to do most everything you like,
including stuff that would be called counterproductive by the community
of code users. Needless to say that Sun has tried to prevent a very real
threat by Microsoft here.
Again, I grant that the SCSL sucks and I do think that something GPL
like would be most appropriate as an alternative. However, I'd still
like to see whether an explicit community concept, with opt-in
membership (and voting capability) is laid down. I wonder how a mix of
license, community by-laws and some branding program would work?