Allow code in Drupal\Component to be used by non-GPL projects

You have two problems. A) finding the authors of some code (say, NestedArray.php) B) convincing said authors (say, at least me for Graph). Both of them are formidable challenges. I consider the MIT throwing away my work.

Thank you sun for starting this issue. I agree 100%.

I think it makes sense to start a new Drupal Components project that we pull into core as a dependency like we would any other. It would be great to have on github/drupal as well as it would encourage outside contribution to our code from symfony developers and the like. Symfony is seeing new contributors in their queue because of other projects using their components; I want this for Drupal as well.

Let's assume for now that we'd only be putting new code into this and deal with the issue of moving existing code there later (there's really very little atm). If we can decide that a drupal components project is a good idea and we want to do it, we can tackle that issue second.

If Key/Value goes in, that would be an ideal first component, but parts of Plugins (if not all) would also work as generic components as well.

Another huge advantage of this is we could start by using phpunit for tests. I find it very cumbersome to use simpletest's unit tests for this type of work, and using something simple and fast like phpunit would make working on components considerably more enjoyable.

Updated issue summary.

I agree with @msonnabaum that a new Drupal Components project would be the easiest way to achieve this, because of difficulty in finding people for re-licensing and so on.

However in general I am against putting non-GPL code in Drupal. If you write something for Drupal and need to contribute it to another project also, you can do that, because you are the author and can license it twice. I suspect this will be the best way to deal with most of these issues. If we have a piece of code with multiple collaborators and contributors that needs to find it's way upstream, shouldn't that work and collaboration just be done in the upstream project ?

If some people want to relicense their code in a separate project on github, be my guest. However forcing core contributors to scatter their work onto github and to force them to MIT license it needs a lot more consensus than a few Symfony-drunk D8 contributors. No matter what you do, only those will react to this issue because it's a D8 issue. The question is: how can we reach our future core contributors to ask them whether they care about MIT vs GPL? If we entertain the thought it's people who do contrib will eventually want to patch core, email them?

rgristroph: If there is an upstream, sure. Improvements to Symfony itself, or to Doctrine Common, should happen in those projects and that is already happening. The catch is for new code that is good enough that it could be a separate reusable project, but for various reasons isn't. Before Drupal 8, we had no mechanism for creating stand-alone code. Everything was one big pile. With Drupal 8 and the Components section, we've started to encourage stand-alone-libraries as an architectural feature, which technically can then be split off as stand-alone code.

The catch is the GPL. Many projects have for whatever reason gone MIT or BSD, and GPL code cannot be incorporated into those.

Now, I've nothing against the GPL at all. It's very good for what it does. But it does limit widespread adoption in a practical sense given where the PHP market has shifted, for better or worse.

Multiple people collaborating is what we want to encourage, so "you're the author, you can dual license" doesn't work. If there's no upstream, then we need to make one.

This thread is, essentially, about creating a Drupal "upstream" where such highly-reusable components can be developed collaboratively.

This thread is, essentially, about creating a Drupal "upstream" where such highly-reusable components can be developed collaboratively.

Yes, but I don't like us using Github for that just because it allows us to go for non-GPL licenses. We should host and develop Drupal components on d.o. and invite new developers to contribute to those projects on d.o. Wouldn't that be a good way for them to get involved with Drupal?

To make that feasible we probably need

• an option to choose the license per sandbox/project (could be restricted to Components)
• make it easy to post "pull-requests" as "patch" to the queue, maybe even directly from a Github repo!?

Stop it and stop it now. There's nothing technical to be discussed here before the social impacts are decided. Do we want to force our contributors to use a license without any protection of their work? This is the question. Technical problems we can solve but this question needs addressing.

I second @chx in this is not a technical issue at all.
I assume GPL license was chosen not for the sole purpose to stop Symfony or other non-GPL licensed project reuse drupal code?
Shouldn't the discussion focus on possible effects on the process of drupal development and community, rather than how to technically achieve distribution of drupal or drupal-related code under license different from GPL?

I lean towards being a pro-GPL rabble rouser myself, but my own contributions aren't in question here, and I can see from Crell's comment how not having the right workflow/infrastructure set up for outside code might hurt us. I think in this case we'd be smart to do whatever is best for the Drupal project overall. I agree with Chx the the social aspects need to be sorted, and these types of discussions tend to become flamewars and counter productive, so let's be practical and even-kneeled about it.

Er. That's not a "quick fix." That has tremendously humungous community implications. And I believe it's mikl.

For my part, I am deeply passionate about the GPL and the protection it affords contributors and end users alike, and would never willingly contribute code under a MIT/BSD license, so count me as a strong -1. For the purposes of this discussion, however, that point is relatively moot, since I don't believe anything I've contributed to Drupal core would qualify as a reusable component, and I'm unlikely to do so in the future given my current career path.

What's much more alarming to me though about this suggestion is the community impact / social aspects, as chx points out. You have two choices: Make the legal aspects of Drupal confusing, where you now need a lawyer to navigate which code you're allowed to use where and under what circumstances (currently one of Drupal's biggest strengths is you know everything you download off Drupal.org has the same license as Drupal itself, so there's none of this ambiguity), or, we go the Github route and effectively fork the Drupal core development team into (at least) two. This would then push development efforts and contributors of major portions of our codebase off the Drupal.org website (our centralized development community being another of our project's hugest strengths) entirely, creating both mental and physical barriers and "sub" communities of core developers. This split isn't just about forking technical crap like code and licenses, it's about forking people, it's about forking contribution methods, it's about forking our future as a project. I am rather alarmed to see this suggestion being treated so cavalierly here.

If this is going to go forward as a serious proposal, it at the very least needs sign-off from Dries, but we probably want to send an email around to basically everyone who ever contributed code to core and find out their thoughts. I suspect that there are a lot of us here because Drupal and all of its code is GPL.

What sun said.

This is a risk for core development, it may end up so fragmented that people wouldn't know where to look for code, documentation, sources, etc... We already are using Symfony components as base framework, and exploding core even more will cause serious maintainance problems. It may divide maintainers and allow some components to derivate so much that maintaining their integration in the core core would be a maintenance hell. Using github or such service in order to benefit from their technical advantages, such as easy review and PR is a good thing, but it would probably be if actual core remains one single repository.

We are slowly cutting a lot of fat thanks to Symfony, and that's a really good thing, but I'm deeply opposed to fragment the core until we didn't finished integrating with Symfony first. Making this decision right now feels too eager and rushed, especially in this moment where core is subjected to so deep and invasive changes.

Plus, we are using more and more external components, not developping new ones, not yet, so let's just not assume that Drupal will provide generic components to PHP comunity right now. I'm not sure it won't before a long time, every tiny piece of core code is deeply tied to the core today, and we just cannot say if we'll extract any useful standalone component from it in a near future.

Might be a pre-cursor so that the infrastructure is there: #1826054: [Meta] Expose Drupal Components outside of Drupal

From the point of view of drafting contracts with customers, having every Drupal module code be necessarily GPL enables us to force customers to accept that the code created while on their project has to be GPL too, and this is a big part of how we get them to renounce ownership of project code (basically, if it's GPL, they tend to consider it as a zero value asset, so they don't care as much).

Should it become possible at some point to see Drupal as a whole rebuilt from MIT code only, the virality clause would no longer exist, and all of a sudden, this lack of appreciation of the value of GPL code would disappear, making contracts harder to negotiate. Of course, just by licensing Components, this won't happen, but it's a first step only.

It's "every module code hosted at drupal.org must be GPL", not "every Drupal module code must be GPL".
Which, basically, makes the rest of comment not so relevant.

#19 wrong. Every Drupal module code is GPL:

http://drupal.org/licensing/faq/#q7

If I write a module or theme, do I have to license it under the GPL?

Yes.

Dual licensing Components Is an entirely different story.

#20:

If you distribute them, you must do so under the terms of the GPL version 2 or later. You are not required to distribute them at all, however. (See question 8 below.)

Updated issue summary.

Seems about time to discuss this again.

I think we know the benefits of the GPL at this point, and I agree with a lot of the comments here with regard to how careful we should be in relicensing our code. That said, I don't think I understand the cost/benefit analysis of MIT vs GPL enough to even make a decision about what I'd like to see in my own mind. Obviously I want people to adopt our Components, but I also want Drupal to stay strong doing what it does. Where's the conflict here? what are the upsides and downsides?

Eclipse

Usualy disclaimer: IANAL, and only express information from a non-US (actually, FR) legal framework, so check with yours.

From working on public tenders, what I have learnt is that having our projects be necessarily licensed under the GPL because of the "virality" clause applying to code invoked by Drupal (hence modules, and theme code, not markup/css) is the only thing which prevents the lawyers from purchasing departments from being able to mandate specific terms of licensing, which is a high level of business value provided by Drupal to its professional service providers: without it, only companies with deep enough pockets could afford lawyering on such contracts to avoid being "legally robbed" by customers whose terms could not be refused.

Of course, this also means that we found a number of cases over the years in which the GPL terms were not accepted, which meant projects were actually awarded to companies delivering non-GPL code, be it based on .net, J2EE or whatever.

One valuable trend I have noticed these last years is the number of cases where the public entity emitting the RFP specified ownership of graphical elements (style tiles, layouts, actual CSS, ...), information architecture, and contents, but carefully worded its requests to allow suppliers to deliver code differently, either by transferring copyright OR providing it under a free license. This is a very Good Thing(TM) IMHO, and it has only been possible because GPL code like Linux or Drupal was so valuable that it enabled actual project owners to override the push from their legal department for traditional terms. Weakening the GPL by settling on more permissive licenses like MIT is really just shooting ourselves in the foot.

Understand that the value here is in the virality applied to custom code depending on GPL code: the actual license of the components does not interfere, since once the GPL enters the picture, the entire invoked code becomes contaminated and it still protected that way. But the more we move code to decoupled components, the less value we provide on top of them (still lots to go before this becomes an actual issue, though), which means at some point it may become reasonable to build non-Drupal solutions on top of Drupal components, and forfeit the GPL by just ignoring the extra value provided by the GPL-ed code.

I had a short conversation with chx last night about all of this, and I have, in the past spoken with ircmaxell on this topic some as well. It seems to me that we should seriously consider what offering high quality GPL components might mean for php at large. Is it possible that, contrary to what we've supposed (that people won't use it) that people will embrace it anyway and we might end up with additional php components out there that are GPL'd as well because they depend on our code? Could we offer enough of a value proposition with our collected components that this is a viable outcome?

What I'd really like to understand is why the MIT supporters here think that is unlikely (because I don't yet understand that). I think this is the question that really needs addressing here.

Eclipse

Oh if we are to offer our code under GPL, absolutely. That'd be a very interesting move. However, the topic title doesn't say "populate Drupal Components from a separate repo" :) so I believe this issue should be won't fixed (and nuked from orbit, just to be sure) and the one I just quoted opened.

So, something like this: #2176459: Expose Drupal Components as their own libraries for easier reuse

Edit: Ability to search. I has it! #1826054: [Meta] Expose Drupal Components outside of Drupal

Feature request = 8.1.x, so moving. However, is there even anything that can/will be done there, or can this be closed out?

Base on the last three comments, this can be closed, for me woks as designed seems the best option. And it appears that the related work is happening in #1826054: [Meta] Expose Drupal Components outside of Drupal