Hack Terms

[richmond62]

Representatives of LC have stated in various places (including to me) that:

To offer a 'continuation' version derived from LC 9.6.3, but modified in any way, ALL references to LiveCode
(and, presumably, by extension, Runtime Revolution) have to be removed.

i.e. Debrand/Rebrand.

Reading through the licence file for the Open Source version I cannot find any reference to that, so wonder if someone can point me to where that is specifically mention in a licensing document connected with Open Source versions of LiveCode.

https://github.com/livecode/livecode/bl ... op/LICENSE

[FourthWorld]

Two different intellectual property jurisdictions.

The code is covered by copyright, addressed by the copyright license, in this case the GPL.

Branding is a function of trademark, a very separate area of law.

Canonical has a policy very similar to LC's with Ubuntu, where the code is fully open but any derivative works not managed by the company must be branded distinctly.

There are at least three reasons for this:

1. Security: a bad actor could offer malware bearing the name of a trusted brand.

2. Trademark dilution: Even earnest projects may not reflect the intentions and priorities of the mark holder, weakening the value of their brand.

3. Legal requirement: In some jurisdictions (eg US), trademarks and patents are enforceable only if the IP owner demonstrates compliance with the FRAND principle, with terms that are Fair, Reasonable, And Non-Discriminatory. If a patent or trademark holder gives a free pass to some infringement while enforcing against others, courts may see this as discriminatory, potentially related to cartel behavior. Companies can avoid such interpretation if they assert ownership equally, which requires them to send cease-and-desist demands to any entity making unlicensed use of their property shortly after they become aware of it. And where licensing may be offered, any terms for licensing must be similarly non-discriminatory, with roughly equivalent terms made available to all who may be interested. So even if a mark holder wanted to do a favor to a friendly fork, doing so might risk their mark becoming invalidated.

Of course I'm not an attorney, and nothing I've written here been be construed as legal advice. I just have an interest in following case law on such matters, and what I've shared here is only my lay interpretation of applicable US law.

[richmond62]

Thank you for explaining that in a way that makes some sense.

[richmond62]

However, how far does 'Debranding' stretch?

1. LC 9.6.3 has obvious branding in the form of its name and the coloured banners.

2. It has less obvious 'branding' insofar as 'LiveCode' is mentioned throughout the Dictionary and in
many, many other contexts.

Personally; I can see the point of removing #1, but I wonder how necessary it is to go through the whole IDE with a 'fine toothed comb'
so remove ALL references (i.e. #2).

[FourthWorld]

2. It has less obvious 'branding' insofar as 'LiveCode' is mentioned throughout the Dictionary and in
many, many other contexts.

Personally; I can see the point of removing #1, but I wonder how necessary it is to go through the whole IDE with a 'fine toothed comb' so remove ALL references (i.e. #2).

That level of completeness would be how things are often done. A protected mark is a protected mark, no matter where it occurs in the work.

Canonical requires this for Ubuntu forks. When they published notice of this it caused a bit of a stir, but it's not so much them as the legal system, so most folks got over it quickly enough.

[tperry2x]

That level of completeness would be how things are often done. A protected mark is a protected mark, no matter where it occurs in the work.

I'd second this. If someone was new to OpenXTalk, and looks through the dictionary - finds references to Livecode everywhere, they would be forgiven for wondering what relevance this has to OpenXTalk.
I'd suggest that all references to Livecode should be replaced with OpenXTalk - even if it's with a simple find > replace (all) inside the dictionary files.

[richmond62]

A simple 'find & replace' in the dictionary inwith a compiled build is extremely straightforward.

My 'problem' [avoiding the psychiatric ones] is to do that with the source code & & & THEN build for the 3 supported programming platforms.

[FourthWorld]

Text is text. GREP is GREP. What works in text works in text, regardless where the text lives.

IIRC there's only one language token that uses "LiveCode" as a keyword ("exit to LiveCode"). That shouldn't take long to update. The rest should be comments.

[richmond62]

AND THEN: builds.

I have no space on my Mac Mini.