I have been quite laconic in the release announcement about relicensing. Much more was said on the licensing page, but yet I got some feedback that it was not clear.

The summary of PostSharp licensing is: Runtime libraries are released under the non-viral LGPL license; compile-time components are released under GPL.

The first thing to realize is that chances are great that relicensing changes nothing to your life. Indeed, programs that are transformed by PostSharp are not contaminated by GPL, since they reference only runtime libraries of PostSharp. Basically, if your program does not need the library PostSharp.Core.dll to be present on your customer's computer, using PostSharp does not affect your program's licensing scheme at all. And I'm pretty sure it's the case of 99% of users.

So who is impacted by the GPL license? Well, people who develop programs that use PostSharp to modify other assemblies. In other words: if your program transform the programs of your customers, read on.

Anyway, what kind of programs modify other programs? There are two typical families of products that fall in that category: O-R mappers, obfuscators, optimizers, code generators are the first one; they are typically deployed only on development machines. Another family includes application servers offering aspect-oriented services (AFAIK there is none for .NET, but in the Java world it's quite common for an application server to have an integrated AOP engine). Of course a special member of that family is the still-unreleased Starcounter object database server; deploying .NET assemblies to this server will make classes "magically" persistent in a server environment.

What if your program uses core parts of PostSharp? Actually, you are not automatically infected by GPL. You have the following options:

  • If you don't distribute your work outside of your company, you are not infected. So if you make an in-house plug-in, you are okay.
  • You can release your work under any license approved by the Open Source Initiative. Well, attention: all your work, and not only the assembly directly referencing PostSharp.
  • You can acquire a commercial license, which is basically a GPL exemption for your products. Exemptions will be provided on an individual, per-product basis. Since the number of customer of these licenses is quite small, exemptions will be given as a part of a partnership program including support and NDA. The idea there is to have a few good customers with a strong relationship. The "masses" have the product for free (anyway with a level of support often quoted as better than commercial one).

An important point is that the licensing itself is in 'candidate' phase. If it makes you feel badly, do not hesitate to react. The point is that, given the size and the complexity of the product, it is not possible any more to develop and support it exclusively during free time, so I must raise some money. I would like the product to be supported by few key partners having a strong interest in PostSharp, and let it free for most (99%) people.

Happy PostSharping!


An interesting post on The Simple Part explains how to use PostSharp to implement an "Undo" feature in Jasema, a tool to create WPF Path Geometry in an easy user friendly way.

The trick is to apply a "journaling" aspect on some front-end methods. The aspect record the object state before and after execution.

Congratulations to 'Karlagius' for this original use of AOP!


Ruurd Boeke has recently released PostSharp4ET, a PostSharp plug-in allowing to use Microsoft Entity Framework without plumbing code -- PostSharp generates it for you at build-time. PostSharp4ET is released as a part of Entity Framework Contrib hosted on CodePlex.com.

With PostSharp4ET, enabling persistency on a class should be as easy as decorating it with a custom attribute:

public class Person
   public int PersonID { get; set; }
   public string Firstname { get; set; }
   public string Lastname { get; set; }

Under the hood, EF-specific interfaces are implemented automatically at build time.

Ruurd explains everything extensively on his blog. And even if you are not interested in Microsoft Entity Framework, Ruurd's blog is a great introduction to how to write more complex aspect libraries with PostSharp.

Thank you Ruurd for this excellent work!