There’s been some debate recently on the license-discuss list hosted by the OSI on how to release code as open source while still requiring that it be compatible with a test suite that must be distributed as part of the code.
The initial discussion was kicked off by Bob Scheifler of Sun Microsystems. Bob’s original post was:
For my personal edification, and hoping this is an acceptable inquiry, I’d like to understand if and specifically how the following informal license sketch conflicts with the OSD. Any and all comments appreciated.
- The licensed work consists of source code, test suite in executable form, and test suite documentation.
- A derivative work in executable form that has passed the unmodified test suite can be distributed under a license of your choosing.
- Any other derivative work can only be distributed under this license.
Any such distribution must include the unmodified test suite and test suite documentation.
The idea would be to somehow require that derivative versions of the code would pass the test suite distributed with the code. As long as the derivative work passed the test suite you could distributed the code under any license you wanted — but if your derivative work did not pass the test suite, you’d be required to distrbute it with the test suite included under the above sketch license.
One use for this type of license would be to release code that implements some sort of API under an open source license, while ensuring that no one can change the API itself. For example, if Sun were to want to release Java under an open source license, this may be the type of license it would choose.
By requiring that any derivative works pass the test suite, Sun could ensure that no one could publish derivative versions of Java that were incompatible with their version. The open source community (and other companies) could freely publish implementations of the code that passed the test suite, but Sun (or at least the JCP) would remain in control of Java as a standard.
Hence the phrase, Open Source/Closed Standard.
So, is this a good idea? Can something be considered to be ‘open source’ if some organization stays in control of the standards that the software implements?
Personally, I believe this should be fine. It’s to everyone’s benefit to allow open source implementations of standard API’s while preventing fragmentation of those API’s.
For a good example, just look back a few years ago at the mess caused by Microsoft delivering an incompatible version of Java. Microsoft took advantage of their Java license and created a JVM (the MSJVM) that implemented what they called ‘improvements’ to Java (can you say ‘embrace and extend’?).
This caused a huge lawsuit between Sun and Microsoft. Sun claimed it was anti-competitive behavior and that it fragmented the Java standard (and they were right on both counts). It was to no one’s advantage (except Microsoft’s) to include a version of Java in every instance of Windows that was incompatible with all the other JVM’s that were available.
(Originally published here under a creative commons license)
extensions not prohibited
As I read this, I see extensions to the API are not prohibited. As long as your open source implementation supports the "base" requirements of the original API to pass the test suite. Add whatever functionality you like. Until they change the test suite. :)
---
Mr. Larch
see Monty Pyton's Flying Circus, Episode 3
Isnt Open Source about freedom and independance
This is "allowing companies to release Open Source", which is NOT Open. It's all about giving to the society, and not the other way around.
It's very much like a patent, only that those the use of the patent are "free" of charge. E.g. you make a patented standard, and then you give everybody only "this way" to "do this". Whilst, modifying it is not legal.
It's not about freedom, it's just allowing the large companies to also control all that OSI used to be about. Letting large companies come to the OSI on their own terms, and in the end making it hard to develop new OSI programs, since they very much may break not only patented software, but also their "OSI patented software".
We need a large NO to organizations that try to profit from OSI, instead of what it used to be all about: Giving back to society.
License is fine - controlling body is not
I think the license Sun is suggesting is fine. I see no problem in stating that one has to adhere to some standard to distribute some software under a special name fx. Java.
I do have a problem with the fact that a company controlling the standard. Instead it should be a standards group or a foundation. This group should include anyone with a vital interrest in the software.
Thus Sun, IBM, RedHat, SuSE and lots of others could participate in defining the standard for the software - Java.
extensions not prohibited
Fundamental freedoms are being denied to contributors. They're barred from meaningfuly addressing a whole number of issues from the technical agenda, to the probem domain. Thy're restricted to solving problems defined by the license, the way the license says they have to solve them.
The 'embrace and extend' option you points out is interesting, but I still don't think it offers enough flexibility because it's the freedom to contribute new code, not the freedom to adapt and evolve existing code according to your own agenda and needs. You have the freedom to give, but no real freedom to take. Surely the flow of rights and benefits should be two ways, not just one way, otherwise the freedoms are realy only on one side of the transaction too.
There is a simple solution - open source the code under a genuinely free license, but maintain the Java trademarks based on published APIs and test suites. Contributors would be free to adapt the code as they see fit, but if they stray too far from the standard they can't call it Java anymore.
This bypasses the problem that the OSS application servers faced because OSS projects based on this would start from a possition of compliance. From there they should be able to go wherever they wish and let the market decide.
Technical standards are great, but always bear in mind who benefits from a particular standard. Is it the vendors, is it the developers, or is it the users? People won't die because an open source JVM, which can't actualy be called a JVM and can't use other Java trademarks, doesn't conform to the stadard. We're not talking about seat belt design regulations.
Sun wants to keep controll of the Java standard and code not out of altruism, but because it serves their commercial interests. There are plenty of open standards that are popular and widely adhered to on a voluntary basis in the open source community, why should Java be any different? Only because Sun wants to maintain controll not only of the standard but also of the source code so that alternatives are either excluded or made a difficult as possible, so that Sun still holds all the cards because that is to their advantage, not yours.
Simon Hibbs
Isnt Open Source about freedom and independance
From the article, it doesn't follow that the "Open Source/Closed Standard" tandem wouldn't allow modifications. In fact, you can modify the implementation of the API, so long as you still conform to the tests/standard.
So, regardless of whether the standard is closed or open, you can still modify the code.
Don't get distracted from the fact that the standard being implemented is closed in the first place. Think of it as trying to implement, say, one of the freedesktop.org standards. The freedesktop.org standards are pretty much open IIRC. If freedesktop.org went out and said "hey, you have to conform to these tests to check that you're following the standard," you wouldn't be complaining. ;)
I see similar parallels in the WINE project. WINE was (and is) essentially about implementing the relatively closed Win32 API. Now, as we all now, the Win32 API is pretty much closed, and we wouldn't know the really nasty quirks behind the scenes in Microsoft's implementation of it. If (big if, mind you) MS decided to follow this 'open source/closed standard' deal and released the source code to their Win32 implementation, then we could code alternative implementations just as long as MS can guarantee that our implementations act in the same way as theirs.
extensions not prohibited
"There is a simple solution - open source the code under a genuinely free license, but maintain the Java trademarks based on published APIs and test suites. Contributors would be free to adapt the code as they see fit, but if they stray too far from the standard they can't call it Java anymore."
...which is essentially the gist of the theoretical 'license' the poster was asking on the OSI mailing list. :)
Isnt Open Source about freedom and independance
As far as I can see, requiring deriviatives to include/pass the testsuite is not *that* bad. How much use will a deriviative that doesn't pass the testsuite be?
It also depends on how flexible they are and who controls the testsuite. It would be better if they could say open the testsuite but require that it isn't changed and is digitally signed or if parts of the test suite were volountary.
Its better than some licenses that demand that modifications are returned, and would enable developers to acheive most of what they expect with open source without patents or other severe encumberances.
Also it is worth bearing in mind that this could be the only way to open source it without breaching IPR agreements they have made.
I see it as a novel approach to solving the problem of opening up proprietary software and systems.
extensions not prohibited
> ...which is essentially the gist of the theoretical 'license' the poster was asking on the OSI mailing list. :)
If it's just a trademark, one could rename it to, say, "Foobar", and you wouldn't have to comply with the spec.
Under the proposed license, you couldn't even rename it anymore, just because the tests would fail.
thats why Open Source was created.
People use Open Source Software everyday along with close source. OSS was created because people got tired of using closed source.
The whole concept was created and inspired by Richard Stallman.
Closed source does not allow for innovation, just
frustration on the part of the user.
the problem with this is...
The controlling comany still retains the "right" to deliberately change the API to break specific derivations should they feel the need.
Open Source
Open Standard
play fair.
the problem is.. there is no problem
I think this type of license would work, so long as the future releases of software/API from ALL contributors (including the copyright owner) must pass the old test suites.
This would prevent anyone (including the original licensor) from intentionally breaking a future release to freeze out a competitor. Everyone could rely on the old API, confident that new releases won't break there stuff. Microsoft among others is notorious for this.
This serves to enforce backwards compatibility within the licence itself (i.e. you can't legally develop new software unless it's backwards compatible). AFAIK there are no open or closed licenses that currently work this way.
Given this restriction, I like it.
Doesn't require passing
Read the text, it just requires that you include the test suite unmodified. You could easily say in the "readme" that what you release doesn't pass test XXXX and why.
Such a license seems quite reasonable.
Bad idea
The mandatory test suite can cause problems.
What if I wanted to take a general chunk of this code, can I use it in another project? Likely not.
I understand the idea of saying it should perform like this, but what if you manage to force a bug or security hole with this?
The second is open relicensing, why don't I release this work under the BSD license without the compatibility clause?
My third point is the author should think of what they want, and make a license that says that.
I don't think there is anything wrong with mandating compatibility, just that this could have consequences if someone tries to remove all the cruft that accumulates over the years.
It's broken
"A derivative work in executable form that has passed the unmodified test suite can be distributed under a license of your choosing."
Well, that's the fundamentally broken part: requiring passing of a test suite. That's obviously going to be extremely ambiguous at best, and a cause of constant legal 'Java wars' at worst. There would be a strong incentive for competitors to haul each other to the court in order to show that the suite didn't pass and prevent the competitor from distributing their executables.
Given how the ambiguous clauses in J2EE TCK licensing hurt Geronimo & JOnAS, I seriously doubt anyone in the runtime community would touch J2SE + TCK with a long stick if it came with an ambiguous license. Experience shows that if a license is ambiguous, it can and likely will be used against you. If Sun picks a bad license, opening up of their Java implementation will be just another PR stunt, instead of a good thing(TM).
I'd also like to note that Bob's attempt to try to find the most obnoxous license that still meets the open source definition, while allowing Sun to place rather arbitrary restrictions on redistribution, did not sit well with OSI. The open source definition is not a challenge for corporate lawyers to find the most ambiguous license that fits it, while circumventing the spirit of open source. I predict that any license that significantly limits the right to fork, will (and certainly should) be shot down.
Using spammer economics to do one's own research is not a good way to spend accumulated goodwill. If Sun wants to make their Java implementation open source, they can chose between a vast array of different OSI certified licenses, including their own creations, SPL and SISSL. If they don't, then that's fine, too. But this regular open source vs Java melodrama is getting old and boring, as you can see by the crisp replies from Moen, Taylor, Rosen & Behlendorf.
Instead of waiting for Sun to make up their mind where they want to go today, I prefer to keep working on a better Kaffe and GNU Classpath, together with other free software runtimes. I see no point in sticking bamboo in my ears, and waiting for Sun to drop some cargo. :)
cheers,
dalibor topic
Isnt Open Source about freedom and independance
"Also it is worth bearing in mind that this could be the only way to open source it without breaching IPR agreements they have made."
If that's a problem, they could simply drop their old code and implement it from scratch, ground up within GNU Classpath. It works for a lot of people, it could work for Sun, too.
cheers,
dalibor topic