[Skyy]

Originally Posted by Doc-Holiday Private work stays private no need for DRM you get someone who wants paid work... they pay for it... let them do as they please with it... Pretty simple... if you need something to remain private dont distribute it...

However, I believe his referral was to the idea of not wanting to release the source code in the case of it being a private work, since that releasing the source code dictates that it isn't in fact, private. The discussion of DRM was to protect the authors who release the code privately but don't want the person to resell.

[asherkin]

If you want to build your work on the back of sourcemod, at least have the courtesy to not be a doucheunit.

[Skyy]

I don't really think it's douchebaggery to write some sort of DRM with a MM:S plugin; not anymore than it is for someone to resell your work, at least. It's not like it hurts the consumer of your work, to have that DRM in place.

[alongub]

The only way to implement a reasonable DRM in SM is to redesign your plugin to be dependent on some non-SM software. For example, instead of using a local MySQL database, write a web service that sits in your central servers and behaves like that MySQL database. The web service would require some kind of authorization ("cd key") and you'll need the ability to collect as much data as you can from the plugin and monitor it to make sure that no one is spoofing his authorization.

Another example would be to write a massive part of your code in MM so it will be hard for other developers to decompile or re-implement that in SM. (see asherkin post below)

As others said before, these methods aren't perfect at all and a skilled developer could still hack your plugin. But that's what DRM's and similar systems are all about. You can't fully secure any application. If systems like the Playstation and iPad can get cracked — where the vendor even controls the hardware — what hope does your plugin have?

[Doc-Holiday]

Originally Posted by alongub The only way to implement a reasonable DRM in SM is to redesign your plugin to be dependent on some non-SM software. For example, instead of using a local MySQL database, write a web service that sits in your central servers and behaves like that MySQL database. The web service would require some kind of authorization ("cd key") and you'll need the ability to collect as much data as you can from the plugin and monitor it to make sure that no one is spoofing his authorization. Another example would be to write a massive part of your code in MM so it will be hard for other developers to decompile or re-implement that in SM. As others said before, these methods aren't perfect at all and a skilled developer could still hack your plugin. But that's what DRM's and similar systems are all about. You can't fully secure any application. If systems like the Playstation and iPad can get cracked — where the vendor even controls the hardware — what hope does your plugin have?

Even sold work the source has to be accessible. But any decent scripter can reverse engineer the plugin shit look at these guys with sm and the barros engine sdks

[alongub]

Originally Posted by Doc-Holiday Even sold work the source has to be accessible. But any decent scripter can reverse engineer the plugin

Exactly. That's the point. The plugin would be dependent on third party services that the developer has no easy access to. Then, you wouldn't care about releasing your source (and you really should).

[asherkin]

So, here's a fun one.

According to the intent of the GPL (which, yes, is legally sound), and a portion of Section 1:

For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

(emphasis mine)

It is my opinion that a closed-source MM:S plugin or VSP designed specificly for the purpose of interacting with a SourceMod Plugin, via any means, including but not limited to, transfer of data using a native interface via a SourceMod Extension or IPC via console commands would constitute a portion of the covered work (SourceMod Plugin) and thus required to be licensed under the GPL.

I'd also like to remind everyone of the anti-anti-circumvention clause in the GPL, meaning it's completely legal to bypass restrictions preventing you from using a plugin however you want. I will happily assist anyone to this end.

[Doc-Holiday]

Originally Posted by asherkin So, here's a fun one. According to the intent of the GPL (which, yes, is legally sound), and a portion of Section 1: (emphasis mine) It is my opinion that a closed-source MM:S plugin or VSP designed specificly for the purpose of interacting with a SourceMod Plugin, via any means, including but not limited to, transfer of data using a native interface via a SourceMod Extension or IPC via console commands would constitute a portion of the covered work (SourceMod Plugin) and thus required to be licensed under the GPL. I'd also like to remind everyone of the anti-anti-circumvention clause in the GPL, meaning it's completely legal to bypass restrictions preventing you from using a plugin however you want. I will happily assist anyone to this end.

I'm with ya there my private work stays with me though I normally release it onceI'm done with features I want. Usually takes years

[Skyy]

If the authors interest was true DRM, they wouldn't use sourcemod in the first place. Throwing in functions that have no business in the world is just a little fun the author gets to have with anyone trying to claim ownership or resell. For the lulz, right?

I agree, though, on the matter of the DRM. I've written it into one plugin - and only one, myself, after a community owner downloaded a plugin I wrote and edited my name out of it, sold it, and then gave my email to the person(s) it was sold to. However, if anyone was really that interested in protecting their work, they'd probably not use sourcemod at all. Still, the best form of DRM would be to simply not release your plugins at all.

With that being said, open source is designed, in my opinion, to exist as a fundamental way for programmers; scripters, consumers, developers, etc., to unite and collaborate. It's used by some as a educational learning tool, but like everything, it's exploited by some as well. But that's just something you have to swallow. I honestly do wish there should be some sort of clause to protect authors against other users taking and selling code they didn't write themselves, though, because that is fucked up, but again, that can be avoided by not releasing your code, but then that counters the purpose of open source. So, there are some positive and potentially negative aspects, but I like to think open source is mostly a positive idea; I myself learned programming through BB's; My formal education on the subject was post.

As with Doc, I do release my private works; or rather the private versions of my public works. I just don't release them until I'm done using them, and then some. :p

Summary: While I'm a long-time supporter of open source, I do wish there was better protection against the theft of open-source works released by authors.

[asherkin]

Skyy, you should read Section 7 of the GPL, you can specify an additional term that states your copyright notice must be maintained in all derivative works - unfortunately this does not protect the authors line in the plugin info struct, but that's a problem specific to SM rather than the license.

EDIT: Actually, in v3 it covers all author attribution.