The license for AUI 7 is changing

Atlassian Ecosystem Design Ecosystem Design Announcements
, , ,
1

In AUI 8.0, the AUI repo was split in to multiple discrete packages, and the core AUI components are re-licensed under an Apache-2.0 license once more. Head to AUI 8.0 is released! for more details.

The remainder of this post applies to AUI 7.x.

Hi everybody, I’m @daz. I’m maintaining the AUI library at the moment.

I want to give you some advanced notice about changes to the AUI library license: From the next major version of AUI – as in, for AUI 7.x and onwards – AUI will be licensed under the Atlassian Developer Terms. This license replaces the Apache-2.0 license going forward.

In the spirit of Open Company, No Bullshit, I want to explain the reasoning behind this decision, and our plans for AUI going forward.

Why we’re making the change (and some history)

You may be aware that the AUI version present in Atlassian products is actually built from two separate repositories:

  • the aui repo contains the core component definitions, and
  • the aui-adg repo applies Atlassian’s Design Guidelines to the AUI components.

This repository split was originally made for licensing reasons: while “aui” has been licensed under Apache-2.0, the “aui-adg” variant has been licensed under Atlassian’s ADG license.

This repository split allowed the AUI component code to exist under a permissive open-source license, but also came with a number of downsides.

The most confusing part of AUI is how it is distributed and the license it is distributed under. Of the ways AUI currently ships – via the AUI CDN, a P2 plugin, the npmjs registry, and AUI’s own documentation – each ships a different variant, and the license is not always the open-source variant.

There are other problems with developing and maintaining the AUI library.

  • Testing the aui-adg variant requires a lot of manual setup (a strange dance of npm and bower linking).
  • Changes to component design (behavioural or aesthetic) often need to be made twice – once in aui, and again in the aui-adg variant.
  • Structural changes are extremely difficult, as they must be made in lock-step across the two repositories.

To address these downsides, we decided to merge the aui and aui-adg repositories together again. While this allows us to simplify AUI’s distribution, build, and development problems, it necessitated a change in licensing to cover the design assets now bundled in AUI itself.

What the license change means for you

The Atlassian Developer Terms allows third party developers to use Atlassian’s SDKs to develop for the Atlassian marketplace.

Applying this license to AUI means:

  • If you’re using AUI to build something for use within the Atlassian ecosystem, nothing changes for you. For example, if you are building a P2 plugin for a Server product, or building an Atlassian Connect app, you can continue to use AUI.
  • For other usages, you may be unable to use the new version of AUI.

The licensing change to AUI will come in to effect in AUI 7.x and onwards. If you are using AUI 6.x or earlier, its license will continue to apply.

In short: if you’re using AUI to build something that is NOT for use within the Atlassian ecosystem, you cannot use AUI 7.x, but you can continue to use AUI 6.x.

What to expect of AUI in the future

Where the AtlasKit library provides an implementation of Atlassian’s Design Guidelines for Cloud, AUI will instead fit the design of Atlassian Server products.

The AUI library will be iteratively updated to improve upon aspects of its design, behaviour, and performance in Atlassian Server products.

First and foremost, we want AUI to ease the burden of building your UI. We know that this license change will disappoint some people, but we’re making it in order to help us deliver on that mission. The change allows us to move a bit faster, simplify AUI’s distribution, build, and development problems, and generally focus on the point of having a library like AUI in the first place: building the UI.

If you have questions or feedback for the AUI team or about building UI for Atlassian products, I’m listening.

Cheers,
@daz

3 Likes
2

Hi @daz, thank you for an explanation it makes everything crystal clear.

I understand a necessity of this in some ways hard move, hope it will help your team to develop AUI faster and easier.

Just a small suggestion: it might be a good idea to put a link to this post somewhere in changelog for 7.x version or to readme.md so it can be easily spotted by everyone.

1 Like
3

Oh, changelog.md already has information about re-licensing.

4

Thanks Bohdan.

Adding a link to this post in the changelog is a reasonable suggestion; I’ll do that :slight_smile:

5

Hi @daz, thanks for the advance notice. That is much appreciated.

However, here’s a natural question. Why do you have non-permissive license on ADG? Why not, instead of making AUI less permissive, make ADG more permissive? What does Atlassian try to protect here? Why does Twitter have open-sourced and reusable UI component library and Atlassian doesn’t? Is Twitter more “open” than Atlassian?

In practical terms, for us it means that we might consider not using AUI at all because we work on an App that will integrate with Atlassian products as well as with other products, or work in standalone mode. A lot of existing integration apps might also find this AUI license limitation interesting and look closer at the small print.

So I don’t see how this benefits anybody, but I might be missing something. Hope you can share your perspective.

Thanks!
Igor

4 Likes
6

@daz,

You wrote:

Where the AtlasKit library provides an implementation of Atlassian’s Design Guidelines for Cloud, AUI will instead fit the design of Atlassian Server products.

Earlier, I read that Atlassian would be deciding this year whether or not ADG3 would (eventually) apply to Server products.

Do you know if this decision has been made yet, and if so, what was the resolution?

Thanks,
Scott

5 Likes
7

Hi @scott,

I don’t currently have any announcement to make regarding the design direction for Server products. With that said, I’m meeting with the design team over the next fortnight, so I will follow up with them and make sure they provide the community with an update.

Cheers,
Daz.

8

Hi @sereda, those are all fantastic questions. I want to answer them all, but some of them are above my station, so I’ll answer what I can now and see what can be answered later.

Thanks for flagging this. Obviously, the AUI team wants AUI to be a useful and usable choice for you when you’re building UI for our products. When choosing the license for AUI, a scenario wasn’t considered where the UI layer was built for multiple ecosystems. I’ll take this feedback to the Atlassian design and legal teams and see what can be done.

A tradeoff was made to allow a small team (think <= 2 people) to work on implementing design and behavioural changes in AUI. The tradeoff may be the wrong one to make - in my eyes there’s no point in improving AUI’s usefulness if the licence prevents or deters a portion of the ecosystem from using it. Again, on this point, I’ll take the feedback to the relevant teams and see what can be done.

Allow me to offer the technical rationale in the meantime.

Technical backstory of the decision

AUI started life as an HTML+CSS pattern library circa 2008. Over time, it evolved in to a more dynamic component library. The AUI component APIs are not always consistent, nor easy to consume, especially compared to more recent (web-)component libraries such as Polymer’s Iron Elements.

To make AUI easier to use, it would be best for AUI would to transition to web components. Since they are standards-based, web components have the largest portability potential and are the least opinionated or restrictive in terms of framework choices that can be made around them.

So, the plan is to iteratively add web component APIs for all AUI components, and make individual components consumable rather than a monolithic library.

Now, AUI’s current (6.x) architecture has two significant roadblocks to executing on that plan:

  • AUI’s code architecture separates by technology instead of purpose – i.e., there are folders for js/ and css/, but not for dropdown/ or button/.
  • This architecture choice underpins the “theming” approach for the AUI library – i.e., any files or folders in the “aui-adg” repository should shadow or override the ones from “aui”.

It is not possible for a small development team to move to a proper component-based model without affecting this architectural structure. Thus, the decision to merge the repositories.

Future plans

As I mentioned above, the plan is for AUI to have web components as API for all of its components, consumable individually.

Under this model, we can do something similar to Atlaskit’s current implementation: each component can ship as its own package, which is individually licensed.

Putting aside the “why” for now, what seems reasonable to me is that the web component APIs would be licensed under a permissive open-source license (i.e., Apache-2.0) whereas the “design” of them is pulled in from a separate package which is licensed under the ADG license. I would assume this arrangement would allow fair use of the components for building your UI, provided that in the non-Atlassian environments, the AUI components were modified to remove the ADG-licensed dependencies.

Where to from here

Let me know if the future plans I outlined above sound to you: reasonable, beneficial, pointless, confusing … whatever.

For right now, the AUI license is still changing. I will however reiterate that the only license for AUI 7+ will change; the component APIs in AUI 6.x will remain under Apache-2.0. Existing JavaScript-based and HTML pattern APIs would remain largely unchanged between 6.x and 7.x, so compatibility with Atlassian products on 7.x should be there if you chose to build your UI using 6.x.

I’ll take your feedback to the design and legal teams and we’ll see what can be done to ensure AUI remains a viable option for you.

Cheers,
@daz.

1 Like
9

I have the same concerns as @sereda

We already have a product eazyBI which is available both as a Jira Server and Jira Cloud add-on as well as a standalone eazyBI cloud or server product. As the majority of our current customers were Atlassian customers we migrated from Bootstrap to AUI back in the year 2013 (after the AlasCamp 2013 where ADG / AUI was preached as an open source framework).

Now the situation became already complicated with ADG 3 and React-based AtlasKit. As we have the same code base for the server and cloud then using it was not the option. So currently we still use AUI 6 for all editions of our product. Now if the license for AUI 7 will change then for some while we will stick with AUI 6. But then most probably we will need to migrate back to Bootstrap or something else in the future and just create themes to make the other frameworks look similar to ADG for the server or for the cloud. Probably this is where interested vendors could collaborate and create ADG themes, for example, for Bootstrap 4?

Kind regards,
Raimonds

1 Like
10

Hi @daz,

Thank you for the detailed explanation!

Regarding future plans, what you describe might be a good compromise, in theory. In practice, I’m a little skeptical about the possibility to cleanly separate the design/CSS from behavior/JS, especially with a lot of behavioral capabilities in CSS3. I’m far from saying that it’s impossible, but… you know how it goes. You guys would test the AUI components only with ADG styling, right? And if we have our own styling, we’re quite likely to hit some problems that would require changes on your side to get fixed. And that definitely will not be a priority for Atlassian team.

Speaking of testing, using ADG and different stylings in different environments would probably increase testing effort for us. (Maybe not much, since we’ll need to test separate environments anyway, but I can’t be sure.) So in order to optimize the work we might just stick with a good-looking but not-ADG styling for all environments.

I think I understand where the closed license comes from - Atlassian wants their product to have a distinctive look & feel, not replicated anywhere else. I can appreciate that. However, I gave my reasons of why it may make things harder for vendors. Maybe there’s another way to achieve that goal. By the way, @raimonds.simanovskis, for this reason, I don’t think that we are allowed to create ADG theme for Bootstrap - the style itself is a property of Atlassian.

So, summarizing for your legal and design teams:

  • Please consider flexing terms on ADG.
  • If that’s not possible, please consider allowing creating derivative works from ADG that would be allowed outside Atlassian products. That would let us to reuse some of the styling that also includes behavior. Maybe there could be some additional restrictions, i.e. making it look sufficiently different from Atlassian, althought that’s a vague term from legal standpoint.

Thanks!
Igor

2 Likes
12

Hi @scott

We are working on a refreshed look and feel for the Server and Data Center versions of Jira Software, Jira Service Desk, Confluence and Bitbucket (and for HipChat Data Center). This is based on ADG 3 and will include things like the new colour palette, typography and icons.

A number of details will differ from the changes you’ve seen in Cloud products. For example, we’re not currently working on large shifts to the navigation or to markup.

We want to give customers a smooth upgrade path, so we’re specifically taking this approach for our Server and Data Center customers to make sure that add-ons and custom plugins continue to work and that customers aren’t forced to retrain their users (e.g. for navigation).

As @daz mentioned, this will form part of the improvements we will make to AUI. We do not currently have plans to bring AtlasKit to our suite of Server and Data Center products.

At this point I can’t give you any specific timeline for these updates, but if you have any questions I’ll do my best to answer.

Cheers,
Judd
Design Manager, Server

1 Like
13

Thanks @jgarratt!
What are the odds of AUI7 being served through a CDN? Or will we be able to package it ourself?

The reason I’m asking is that this would make it a lot easier for us to maintain a single UI between Cloud and Server (reducing cost on documentation, development, support, sales friction, etc).

Thanks,

/Daniel

14

Hi @daniel,

This in the Upgrade guides under the Distribution changes heading:

From AUI 7 onwards, AUI is not published to its own CDN any more. For production services, it is recommended to bundle the AUI resources with your own.

1 Like
15

If I summarize some chosen parts:

  • Atlassian wants to close-source the design (and has implemented it by closing the source of ADG and AtlasKit)
  • Atlassian has now 2 incompatible recommended libraries between Cloud (AtlasKit) and Server (AUI 7).

To make sure you understand what you are doing:

  • Given that the UI will be incompatible between Cloud and Server, as well as the APIs (Plugins2 vs AC), it makes it so difficult to share code that it is not efficient, as a vendor, to build shared code in plugins/addons/apps. It was already inefficient to build a shared app (or add-on at the time) when just the back-end APIs were incompatible, so you’re just confirming it.
  • Given the code can’t be reused for external applications:
    • Vendors can’t sell the product separately, for example like LucidCharts or Draw\.io,
    • Vendors can’t sell the product on other platforms, like the Heroku appstore,
    • Developers can’t reuse their knowledge of the toolkit to build other apps, so developers won’t be keen to master this API and learn more, since they’ll throw away this knowledge once their assignation is over.

This increases the risk for vendors, since it locks us into the Atlassian ecosystem. It also reduces our potential revenue since we can’t publish the add-ons on several platforms. It also reduces margins since we can’t (or with difficulty) share code between Server and Cloud. It makes it harder to convince new developers to work on our projects. Finally, it incentives us to choose one side between either Cloud or Server.

Lock-in + reduced revenue + reduced margins + cloud/server divide + increased developer costs => It’s less attractive for newer vendors or it limits investments by vendors into this platform. Since you’re Atlassian and you’re well managed, I assume this is part of a bigger plan with huge upsides: Maybe market concentration at the vendor level is better for corporate customers, or maybe it’s better if add-ons are published by consulting firms who can sponsor the development costs with consulting opportunities. I just want to make sure you’ve realized it.

5 Likes
16

@playsql you can use AtlasKit for Server apps. We’ve done recently with Profields. OK, it doesn’t fit with the Jira Server UI but if you App uses full-screen layout, is not a problem.

17

If the library is not going to be open any more, then we won’t be using it. Easy enough. There’s plenty of libraries that don’t pose ridiculous restrictions, but now Atlassian customers suffer since the look and feel will no longer match.

1 Like
18

Hey @playsql, @sfbehnke, @david.garcia, @jeff, @daniel, @raimonds.simanovskis, @scott, and @sereda: thank you all for the feedback and discussion.

You have all raised excellent points, and the AUI team hear you.

A change of the license would not manifest itself in AUI 7.x, but the AUI team are investigating our options for how 8.0 could change the situation. I offered my thoughts on what this might look like in an earlier comment here.

I know how frustrating the situation is right now. I cannot offer an immediate fix for the concerns you have raised, nor a firm date for when we will address them. This licensing situation is still on my radar, and @jgarratt and I continue to spar on these concerns.

Thanks for your patience.
Daz

1 Like
19

“Open company”… sure.

We’ve developed a WordPress theme using AUI. Planned to update to latest AUI, some polishing and publish it via WordPress repo. Propably never will happen…

2 Likes
20

Same here. We’re using a lot of Atlassian Products in our company. Our users know how it looks like and how to use the (Atlassian)-Tools. Now we were thinking about the future options for our existing fat clients which have nothing to do with Atlassian. The idea is/was to migrate some of them to the web and as a lot of people already know the look and and feel of the Atlassian products we were considering using AUI for our internal software. The license change in 7.x destroyed all these plans. Sad but true. AUI is cool, but the fact not beeing allowed to use it is not so cool. Actually we’re using a mix of Bootstrap 4 and Ant Design for the first applications - maybe the situation will change in 8.x again?