Is there some merit in "Community Source"?

Posted 7 Jun 2000 at 15:51 UTC by cdegroot Share This

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?


SCSL's hard to get over, posted 7 Jun 2000 at 19:46 UTC by schoen » (Master)

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.

captain, I'm picking up an unusual concenration of bogons, posted 7 Jun 2000 at 21:33 UTC by graydon » (Master)

you're conflating 2 issues here to attempt to make it sound like SCSL is a good thing:

  1. The right to fork (a.k.a. the right to modify & redistribute)
  2. 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.

but apart from the factoids..., posted 7 Jun 2000 at 23:55 UTC by cdegroot » (Master)

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.

Non-specific criticisms, posted 8 Jun 2000 at 02:19 UTC by schoen » (Master)

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.

Kerberos, GPL, BSDL and MS, posted 8 Jun 2000 at 03:46 UTC by darius » (Journeyer)

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.

"The SCSL is a bad licence. Get over it.", posted 8 Jun 2000 at 04:29 UTC by cdegroot » (Master)

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.

GPL isn't the only one, posted 8 Jun 2000 at 07:12 UTC by bagder » (Master)

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 object files IIRC, posted 8 Jun 2000 at 10:46 UTC by listen » (Journeyer)

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.

GPL and breathing relief, posted 8 Jun 2000 at 15:31 UTC by dtype » (Master)

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.

expelling miscreants, posted 8 Jun 2000 at 17:35 UTC by Kalana » (Journeyer)

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"?

Is it possible to reimplement Jini?, posted 8 Jun 2000 at 18:28 UTC by Zaitcev » (Master)

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)

according to their faq [#16], you're free to clone it so long as you don't infringe on their intellectual property which you'll note on their copyright page includes a number of patents. Specifically, they've patented leasing, update monitor subscription, distributed GC, network node registration, event service, and basically everything else you would ever use to construct a clone.

ianal, perhaps some/all of these patents do not hold up. anyone know?

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.

Pointer to the license, comments, posted 9 Jun 2000 at 05:30 UTC by lilo » (Master)

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.

SCSL did not protect Sun, posted 9 Jun 2000 at 19:35 UTC by BrucePerens » (Master)

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

A couple of thoughts, posted 11 Jun 2000 at 01:19 UTC by pudge » (Master)

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, posted 13 Jun 2000 at 03:20 UTC by nelsonrn » (Master)

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.

Re: GPL forms a community, posted 13 Jun 2000 at 13:17 UTC by cdegroot » (Master)

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:

  1. 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).
  2. 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).
  3. 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?

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page