I think it would be, as long as your code itself is open source. I'll wait for Coren to confirm, however.

Legal was pointed towards this bug, and their opinion on the matter is what we need so I am not going to express an opinion either way. :-)

As a legal matter, what I care about is that we, the Foundation, have permission to have the code on our servers without needing to review each individual license. So as long as only open source code (i.e., in this case, not the compiler) is on our servers, that is legally fine by me. (The compiler obviously can't live on labs.)

As a policy matter, part of why we have an open source requirement is to make sure the code can be reviewed, maintained, and improved by others. I don't think this meets that requirement, but I don't think we've ever actually written it down as a hard/fast requirement because it was always previously covered by the first point.

So I'm inclined to say "no" but I think the second point is up for discussion and my "no" shouldn't be taken as a hard/fast refusal from legal.

A point of data is that section 2 of http://opensource.org/osd-annotated reads:

"The program must include source code, and must allow distribution in source code as well as compiled form. [...] The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed."

It's arguable that a program whose source is ostensibly open but which cannot - in practice - be recompiled after modification fails that requirement?

It's an annoying gray area though. "You need to buy X to compile that program" seems to violate the spirit of Open Source when X is "a compiler", yet it's obvious that it's okay if X is "a computer".

Perhaps a good analogue is the whole kerrufle about TPM - is being able to recompile something still properly Open Source if it then can't be run because it needs a signature you cannot get?

On the third hand, the code being suitably licensed means that its function can easily be reimplemented in some other language (a derived work), or some interpreter/compiler can be written to parse the original language's syntax and semantics into some other form that can be compiled.

Would a program written in an old dialect of some other language no extant compiler still speaks (say, very old K&R C or cfront-epoch C++) lose its opensourceness because of it?

Food for thought.

This is the kind of thing where the open source definition's descent from the Debian Free Software Guidelines shows through. That language makes more sense if you're an operating system ;)

Luis, as it stands I'm inclined to allow the use of the language on Labs unless your interpretation of our TOU prevents it (or you feel strongly that we should ajust the TOU to make it).

I'd rather have a useful tool available with its source open even if it's more difficult than usual to rebuild it.

I think it's against the spirit of the TOU, if not necessarily the letter - the idea was that if the original maintainer vanishes, others can reasonably pick up and continue their work. That can't happen if there is no widely-available toolchain.

There are many other servers in the world; is there a reason why these have to reside on labs? Data access? Something else?

In T74253#852391, @LuisV_WMF wrote:

is there a reason why these have to reside on labs? Data access? Something else?

I think only the OP can answer that definitively. @Inkowik?

Yes, I would like to access the database replicas. I am also looking for a place where I can run my bot automatically, because on my local system I don't have the possibility to do so.

I hope you won't be offended if I'm skeptical that you have the skills/ability to write a compiler that is worth keeping proprietary but not get access to a server that can run a bot regularly.

There exists lots of proprietary compilers in the world that you can use
without having to write one yourself.

In T74253#948862, @LuisV_WMF wrote:

I hope you won't be offended if I'm skeptical that you have the skills/ability to write a compiler that is worth keeping proprietary but not get access to a server that can run a bot regularly.

Inkowik did not write PureBasic, but wrote a framework in PureBasic. Inkowik's code is open source; it's just that the compiler one needs to run it is not free software.

My apologies, I misunderstood.

Any resolution here?

Not looking at the legal side: Using yet another™ programming language with yet another™ framework feels very wrong to me. The bots/tools community is not that small, but small enough so that partitioning it further risks swallowing a lot of energy. Unless a very esoteric feature of a language is truly needed that cannot be easily emulated in another language (say some fancy list processing in Haskell), I would strongly recommend using PHP/Python/Perl/JavaScript/Java/etc. even if otherwise a developer doesn't use those languages regularly.

The bot/tools community is in fact so small that forcing developers to use languages they don't know or don't feel comfortable using is a waste of these developers' valuable contributions, because they can choose to either use that language or not to develop at all. You run the risk of others not understanding the language at hand if the code is abandoned by the developer, but you can learn it if needed or rewrite it in another language. I adopted tools in PHP, which I don't understand and don't want to understand, but there was no one else to do it … so what does that tell you? (rhetorical question, just for clarity)

/me agrees with @Giftpflanze

I didn't say anything about forcing developers to use a limited set of programming languages.

But for example if you develop a bot using Pywikibot, you can wallow in not having to think all the thoughts that led to the existing code and not having to stay up to date with all the changes in the various APIs, but can concentrate on the "business logic", i. e. what essential task a program is written to accomplish.

fwiw, the bot framework is here:
http://inkowik.github.io/pbwb/
https://github.com/inkowik/pbwb
2896 sloc

and the bot is here:
https://github.com/inkowik/inkobot

In T74253#757712, @coren wrote:

A point of data is that section 2 of http://opensource.org/osd-annotated reads:

"The program must include source code, and must allow distribution in source code as well as compiled form. [...] The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed."

It's arguable that a program whose source is ostensibly open but which cannot - in practice - be recompiled after modification fails that requirement?

No it cant. That is not even a component of the GPL. GPL is explicit that all components necessary to rebuild the source must be available, which means the Makefile, build scripts, etc. But it does not include compiler or operating system components (even optional OS components). They are termed "System Libraries". There are many open source projects that depend on MS VC++, Borland C (non-free edition), MIPSPro, SunPro, IBM's several compilers which I've long forgotten the names of for various platforms, etc, etc. And many of those unix-ish projects not only required a proprietary compiler, the proprietary compiler only ran on a box that only one vendor sold. (unless you were a uber geek)

However it could be considered to be part of the GFDL, which added that the source (the Transparent edition) must be in a standardised format, and I guess it is implicit that the standardised format shouldnt have patent problems, but I dont know whether they addressed that possibility directly.

Perhaps a good analogue is the whole kerrufle about TPM - is being able to recompile something still properly Open Source if it then can't be run because it needs a signature you cannot get?

Very different problems.

A compiler is : an expensive build component is necessary to transform the source into a _standalone_executable_, but once transformed it can be used at will on any machine it was built to support, given freely to other people who can also use it as they wish if they have a machine with the appropriate architecture, system libraries etc - but they do not need the compiler or a license to the compiler. hence "standalone".

Whereas TPM and anything involving keys is : the source and how you obtain a standalone executable is irrelevant; an authority must approve the built version before it will execute on any machine (neither your friends machine or your own), and to boot the authority can revoke that approval afterwards.

(Adding Stephen, who I think is supposted to be handling these for now)